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

[<tri...@tr...>]

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
>