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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Jürgen,

Yes, that is the scenario.  Obtain the DataSource based on the JNDI name and 
pass it in to the constructor for the JdbcTemplate or a class that extends 
Mapping SqlQuery.

While we are on the subject of JDBC.  Do we really have to require an explicit 
compile for the RdbmsOperation and its subclasses.  Currently we throw  
InvalidDataAccessApiUsageException when we try to use an operation that has 
not been comiled.  We could just as easily execute the compile() at that 
point, since we know what the problem is.  

Thomas

> Good point indeed, using Spring JDBC without an ApplicationContext. I'll
> reintroduce a simple version of it, using a plain JndiTemplate. Sometimes I'm
> a little over-eager in terms of simplification, sorry :-)
> 
> I assume that the typical scenario for this is somewhat like the following:
> 
> 	DataSource ds = DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> 	JdbcTemplate jt = new JdbcTemplate(ds);
> 	jt.<doSomething>;
> 
> Would that be enough? I'm not keen on introducing an additional JdbcTemplate
> constructor with a DataSource NAME. The retrieved DataSource will typically
> be kept somewhere anyway.
> 
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocator, for
> maximum code reuse. We'll also have AbstractJndiLocator's "inContainer"
> property then, to be able to control "java:comp/env" prefixing
> (inContainer=false means plain JNDI name, the default inContainer=true means
> prefix "java:comp/env" if not already contained).
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; jürgen höller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
> 
> 
> 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
> > >
> >
> >
> >
> 
> 
> 