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

[William G. T. Jr. <wg...@ru...>]

Rod, you can add a third org to the list of folks who are using Sprin=
g=20
JDBC without an ApplicationContext.  We are using it with in conjucti=
on=20
with the open source uPortal framwork for channel (aka portlet) devel=
opment.

later.
Bill


j=FCrgen h=F6ller [werk3AT] wrote:
> 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 fo=
llowing:
>=20
> =09DataSource ds =3D DataSourceUtils.getDataSourceFromJndi("jdbc/cb=
x");
> =09JdbcTemplate jt =3D new JdbcTemplate(ds);
> =09jt.<doSomething>;
>=20
> Would that be enough? I'm not keen on introducing an additional Jdb=
cTemplate constructor with a DataSource NAME. The retrieved DataSourc=
e will typically be kept somewhere anyway.
>=20
> I'm also gonna make JndiObjectFactoryBean extend AbstractJndiLocato=
r, for maximum code reuse. We'll also have AbstractJndiLocator's "inC=
ontainer" property then, to be able to control "java:comp/env" prefix=
ing (inContainer=3Dfalse means plain JNDI name, the default inContain=
er=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 companie=
s using
> Spring JDBC only. If they have to do the JNDI stuff themselves it r=
educes
> 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
>=20
>>J=FCrgen,
>>
>>I'd prefer to keep DataSourceUtils.getDataSourceFromJndi for applic=
ations
>=20
> that
>=20
>>only use the JDBC framework.  Maybe we could change the way it does=
 the
>=20
> lookup
>=20
>>to make it similar to the JndiObjectFactoryBean.  What do you all t=
hink?
>>
>>Thomas
>>
>>
>>>Regarding mock objects, I think that the JNDI mocks do have value =
for
>>>application developers: They can serve as JNDI replacement for
>=20
> applications
>=20
>>>test environments and standalone applications, running the same co=
de and
>>>config files as in the container environment.
>>>
>>>We are using this to be able to reuse the same Hibernate config fi=
le for
>=20
> both
>=20
>>>web app and test environments. In the standalone access, we simply=
 bind
>=20
> a
>=20
>>>DriverManagerDataSource to the same JNDI location, with Spring's J=
NDI
>=20
> mocks
>=20
>>>as infrastructure.
>>>
>>>Other development projects can use this strategy too, and EasyMock=
 won't
>=20
> help
>=20
>>>here. Thus, I'd like the JNDI mocks to stay, but all other mocks s=
hould
>=20
> not
>=20
>>>be in our src tree IMO, as they only serve within our test suites.
>>>
>>>Regarding FrameworkServlet's debug support, that were exactly the
>=20
> reasons why
>=20
>>>I've removed them. It cluttered up the code somewhat, and I don't
>=20
> consider it
>=20
>>>necessary.
>>>
>>>---
>>>
>>>I've just added one more refactoring: I've replaced both
>>>JndiDataSourceBean/JndiDataSourceEditor and
>>>JndiSessionFactoryBean/JndiSessionFactoryEditor with generic
>=20
> implementations,
>=20
>>>namely JndiObjectFactoryBean and JndiObjectEditor. Effectively, th=
e
>>>FactoryBeans have just returned Objects, so there's no need for
>=20
> specialized
>=20
>>>implementations. I've also removed DataSourceUtils.getDataSourceFr=
omJndi
>=20
> and
>=20
>>>SessionFactoryUtils.getSessionFactoryFromJndi, as they aren't
>=20
> recommended
>=20
>>>anymore. I don't like too many ways to achieve 1 thing.
>>>
>>>One more reason is that the former getDataSourceFromJndi always lo=
oked
>=20
> up the
>=20
>>>given name under "java:comp/env", if not contained in the name. Th=
is is
>=20
> too
>=20
>>>inflexible: A DataSource might be bound to any JNDI name, in fact.
>>>JndiObjectFactoryBean and JndiObjectEditor need the full JNDI name=
: This
>=20
> is
>=20
>>>clearer and not much effort.
>>>
>>>So Isabelle and Ken, please use
>=20
> com.interface21.jndi.JndiObjectFactoryBean
>=20
>>>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
>=20
> obviously
>=20
>>>not all). I think the volume and quality of stack traces is very
>=20
> important.
>=20
>>>It's about the only thing that really bugs me with Hibernate 2.0 R=
C1,
>=20
> for
>=20
>>>example. We may need to consider a consistent approach to logging
>=20
> (levels
>=20
>>>etc.) for 0.9 or 1.0.
>>>
>>>I imagine removing debug support in framework servlet removed a lo=
t of
>=20
> code.
>=20
>>>I actually eyed it myself with my scalpel in mind recently. It did=
 make
>=20
> the
>=20
>>>code much harder to understand and the fewer lines of code, the fe=
wer
>>>potential bugs. Also, I don't think it was documented anywhere, so=
 I
>=20
> doubt
>=20
>>>anyone will miss it too much. (I did use it myself occasionally bu=
t I'm
>=20
> sure
>=20
>>>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 spri=
ng
>>>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
>=20
> work.
>=20
>>>Anything I do add to Spring until we go to 0.8 will either be an u=
rgent
>=20
> bug
>=20
>>>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 resubmit=
s,
>=20
> I've
>=20
>>>also created an extensive test suite for ControllerServlet and som=
e web
>>>support classes. We're at overall >64% now!
>>>
>>>Additionally, I've refined some ApplicationContext stuff (moved
>>>OPTIONS_BEAN_NAME from ApplicationContext to AbstractApplicationCo=
ntext
>>>etc), and cleaned the exception handling in the beans package (e.g=
.
>=20
> rethrow
>=20
>>>BeansException directly when catching Exception instead of wrappin=
g it).
>>>
>>>Rethrown exceptions don't get logged anymore, as they are logged b=
y the
>>>highest level exception handler anyway (-> no double stack traces =
in the
>>>console). I've also commented out the println(this) on printing a
>=20
> rootCause
>=20
>>>stack trace: As a root stack trace will always get printed after t=
he
>>>exception's message, those lines have only added redundant informa=
tion,
>>>cluttering the console.
>>>
>>>I've removed FrameworkServlet's debug support, I don't see any rea=
l use
>=20
> case
>=20
>>>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 bindi=
ng
>=20
> them to
>=20
>>>the request.
>>>
>>>I'm also gonna move the web.mock classes back to the test sources,=
 as
>=20
> they
>=20
>>>are pretty rough, and not really meant for usage within applicatio=
n
>>>development - in constrast to the JNDI mocks, for example.
>>>
>>>I'll check my stuff in within the next 2 hours. Everybody, please =
test
>=20
> the
>=20
>>>current framework version in your apps! We should really try to re=
lease
>=20
> a
>=20
>>>0.8 as stable as possible.
>>>
>>>BTW, what's the current status in terms of code beautification (Ja=
lopy
>=20
> etc)?
>=20
>>>We have mixed headers in our files at the moment, and sometimes
>=20
> inconsistent
>=20
>>>formatting. Do we aim to clean this for 0.8?
>>>
>>>Juergen
>>>
>>>