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

[Rod J. <rod...@in...>]

I agree with Thomas. Good point. At the moment I know of 2 companies using
Spring JDBC only. If they have to do the JNDI stuff themselves it reduces
the benefit.

Rod

----- Original Message -----
From: <tri...@tr...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Cc: "Rod Johnson" <rod...@in...>;
<spr...@li...>
Sent: Friday, May 23, 2003 2:06 AM
Subject: RE: [Springframework-developer] Code changes for 0.8?


> Jürgen,
>
> I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applications
that
> only use the JDBC framework.  Maybe we could change the way it does the
lookup
> to make it similar to the JndiObjectFactoryBean.  What do you all think?
>
> Thomas
>
> > 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ürgen höller [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ürgen höller [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
> >
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ObjectStore.
> > If flattening out C++ or Java code to make your application fit in a
> > relational database is painful, don't do it! Check out ObjectStore.
> > Now part of Progress Software. http://www.objectstore.net/sourceforge
> > _______________________________________________
> > Springframework-developer mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
>
>
>