Re: [Springframework-developer] Revised BeanFactoryLocator and EJB support classes

[Rod J. <rod...@in...>]

I agree with these changes, but I think we should try to avoid API change=
s
in general from now to 1.0 final. With RC1 we are committing to a final A=
PI.
Also, I'd rather we don't have enough changes that we need an RC2.

Regards,
Rod

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, February 14, 2004 5:22 PM
Subject: [Springframework-developer] Revised BeanFactoryLocator and EJB
support classes


Colin, Rod, everyone,

I revised the BeanFactoryLocator and EJB support classes yesterday, mainl=
y
to align the naming of the implementation classes with Spring's general
naming patterns. For example, the ApplicationContext-specific classes are
now called "ContextJndiBeanFactoryLocator" and
"ContextSingletonBeanFactoryLocator". I've also factored out the
BeanFactoryReference implementations for newly created BeanFactories into
separate classes, making them invoke
"ConfigurableBeanFactory.destroySingletons" respectively
"ConfigurableApplicationContext.close" on release.

I've adapted the EJB support classes accordingly and, on the occasion, mo=
ved
the logger instance variable from AbstractEnterpriseBean to
AbstractStatelessSessionBean and AbstractMessageDriverBean. Someone
complained on the mailing list a while ago that removing and setting the
logger instance for SFSBs is a nuisance, and I agree - the subclass shoul=
d
hold its own *static* logger instance there. Of course, this doesn't appl=
y
to SLSBs and MDBs, thus the change.

I've also noted that AbstractEnterpriseBean's "ejbRemove" implementation =
did
*not* invoke BeanFactoryLocator.release; is there any rationale for this?
For the time being, I've made it invoke release, as I consider it importa=
nt
to destroy resource singletons like a local SessionFactory or
PersistenceManager on BeanFactory respectively ApplicationContext shutdow=
n.

I hope you don't mind the name changes. My goal is to keep class and meth=
od
naming as consistent as possible within the Spring codebase; something ma=
ny
other open source projects to not respect at all.

Juergen



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id438&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer