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

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

BTW, I've also made AbstractBeanFactory support circular references =
(including proper tests). A bean can now reference another bean that in =
turn references the original one, all via beanRefs. A bean can even =
reference itself now.

Juergen

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Friday, May 23, 2003 1:40 PM
To: tri...@tr...
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?

I've just committed the changes.

There's a DataSourceUtils.getDataSourceFromJndi(jndiName) method again, =
assuming running in a container (i.e. adding the prefix "java:comp/env/" =
if not already contained). An overloaded =
getDataSourceFromJndi(jndiName,inContainer) version allows for control =
of the prefixing.

JndiObjectFactoryBean is now a very simple subclass of =
AbstractJndiLocator, supporting the same properties: jndiTemplate, =
jndiName, inContainer. A DataSource definition can thus look as follows:

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">jdbc/myds</property>
	</bean>

The following definition is equivalent:

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">java:comp/env/jdbc/myds</property>
	</bean>

Or, when not running in a container (no implicit "java:comp/env/" =
prefix):

	<bean name=3D"dataSource" =
class=3D"com.interface21.jndi.JndiObjectFactoryBean">
		<property name=3D"jndiName">java:/myds</property>
		<property name=3D"inContainer">false</property>
	</bean>

Notice the "jndiName" property, instead of the former =
JndiDataSourceBean's "name".

Regards,
Juergen

-----Original Message-----
From: tri...@tr... [mailto:tri...@tr...]
Sent: Friday, May 23, 2003 1:27 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: spr...@li...
Subject: RE: [Springframework-developer] Code changes for 0.8?

J=FCrgen,

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

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

point, since we know what the problem is. =20

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 :-)
>=20
> I assume that the typical scenario for this is somewhat like the =
following:
>=20
> 	DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
> 	JdbcTemplate jt =3D new JdbcTemplate(ds);
> 	jt.<doSomething>;
>=20
> 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.
>=20
> 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=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue means
> prefix "java:comp/env" if not already contained).
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Friday, May 23, 2003 8:36 AM
> To: tri...@tr...; j=FCrgen h=F6ller [werk3AT]
> Cc: spr...@li...
> Subject: Re: [Springframework-developer] Code changes for 0.8?
>=20
>=20
> 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.
>=20
> Rod
>=20
> ----- Original Message -----
> From: <tri...@tr...>
> To: "j=FCrgen h=F6ller [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?
>=20
>=20
> > J=FCrgen,
> >
> > 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=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
> > >
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > >
> >
> >
> >
>=20
>=20
>=20

-------------------------------------------------------
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