RE: [Springframework-developer] Code changes for 0.8?

[<jue...@we...>]

Regarding mock objects, I think that the JNDI mocks do have value for =
application developers: They can serve as JNDI replacement for =
applications test environments and standalone applications, running the =
same code and config files as in the container environment.

We are using this to be able to reuse the same Hibernate config file for =
both web app and test environments. In the standalone access, we simply =
bind a DriverManagerDataSource to the same JNDI location, with Spring's =
JNDI mocks as infrastructure.

Other development projects can use this strategy too, and EasyMock won't =
help here. Thus, I'd like the JNDI mocks to stay, but all other mocks =
should not be in our src tree IMO, as they only serve within our test =
suites.

Regarding FrameworkServlet's debug support, that were exactly the =
reasons why I've removed them. It cluttered up the code somewhat, and I =
don't consider it necessary.

---

I've just added one more refactoring: I've replaced both =
JndiDataSourceBean/JndiDataSourceEditor and =
JndiSessionFactoryBean/JndiSessionFactoryEditor with generic =
implementations, namely JndiObjectFactoryBean and JndiObjectEditor. =
Effectively, the FactoryBeans have just returned Objects, so there's no =
need for specialized implementations. I've also removed =
DataSourceUtils.getDataSourceFromJndi and =
SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't =
recommended anymore. I don't like too many ways to achieve 1 thing.

One more reason is that the former getDataSourceFromJndi always looked =
up the given name under "java:comp/env", if not contained in the name. =
This is too inflexible: A DataSource might be bound to any JNDI name, in =
fact. JndiObjectFactoryBean and JndiObjectEditor need the full JNDI =
name: This is clearer and not much effort.

So Isabelle and Ken, please use =
com.interface21.jndi.JndiObjectFactoryBean for DataSource definitions =
instead of com.interface21.jdbc.datasource.JndiDataSourceBean! Sorry for =
the late change, but I think it's worth it.

Gonna check all this stuff in the next hour...

Regards,
Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, May 22, 2003 6:24 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: Re: [Springframework-developer] Code changes for 0.8?


Excellent. Great news on the test coverage! You've been doing good work
here.

I'm glad you've cleaned up the stack traces... There were quite a few
repeated stack traces a long time ago, and I got many of them (but =
obviously
not all). I think the volume and quality of stack traces is very =
important.
It's about the only thing that really bugs me with Hibernate 2.0 RC1, =
for
example. We may need to consider a consistent approach to logging =
(levels
etc.) for 0.9 or 1.0.

I imagine removing debug support in framework servlet removed a lot of =
code.
I actually eyed it myself with my scalpel in mind recently. It did make =
the
code much harder to understand and the fewer lines of code, the fewer
potential bugs. Also, I don't think it was documented anywhere, so I =
doubt
anyone will miss it too much. (I did use it myself occasionally but I'm =
sure
I can live without it.)

I'm not sure that *any* mock objects should be in the main source tree.
Maybe we need a third tree for the mocks and things like
EjbContainerDetective that are handy but not part of the core spring
runtime. I don't tend to use our mock objects much anymore, since I
discovered the wonder that is EasyMock.

Code formatting I think is a 0.9 thing. Certainly after we have a tagged
stable release. We don't want to delay 0.8 for this.

I'm away this weekend (bank holiday in the UK), so won't be doing any =
work.
Anything I do add to Spring until we go to 0.8 will either be an urgent =
bug
fix or simply additional tests.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, May 22, 2003 4:29 PM
Subject: RE: [Springframework-developer] Code changes for 0.8?


Besides having reworked the form controller's handling of resubmits, =
I've
also created an extensive test suite for ControllerServlet and some web
support classes. We're at overall >64% now!

Additionally, I've refined some ApplicationContext stuff (moved
OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationContext
etc), and cleaned the exception handling in the beans package (e.g. =
rethrow
BeansException directly when catching Exception instead of wrapping it).

Rethrown exceptions don't get logged anymore, as they are logged by the
highest level exception handler anyway (-> no double stack traces in the
console). I've also commented out the println(this) on printing a =
rootCause
stack trace: As a root stack trace will always get printed after the
exception's message, those lines have only added redundant information,
cluttering the console.

I've removed FrameworkServlet's debug support, I don't see any real use =
case
for it. During development, Log4J's debug log is all you need, IMO - you
exactly see what handlers/mappings/etc get used, no need for binding =
them to
the request.

I'm also gonna move the web.mock classes back to the test sources, as =
they
are pretty rough, and not really meant for usage within application
development - in constrast to the JNDI mocks, for example.

I'll check my stuff in within the next 2 hours. Everybody, please test =
the
current framework version in your apps! We should really try to release =
a
0.8 as stable as possible.

BTW, what's the current status in terms of code beautification (Jalopy =
etc)?
We have mixed headers in our files at the moment, and sometimes =
inconsistent
formatting. Do we aim to clean this for 0.8?

Juergen