Menu
▾
▴
RE: [Springframework-developer] Code changes for 0.8?
|
From: <jue...@we...> - 2003-05-23 09:02:22
|
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 =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cbx");
JdbcTemplate jt =3D 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=3Dfalse means plain JNDI name, the default =
inContainer=3Dtrue 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=FCrgen h=F6ller [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=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?
> 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
> >
>
>
>
|
