|
From: <jue...@we...> - 2004-02-14 18:21:46
|
Agreed, the RC1 API should be considered as final as possible. However, = the BeanFactoryLocator was a brand-new RC1 feature, added pretty much = last minute there, so I guess it's arguable to refine this for 1.0 final = - particularly if it just affects advanced users that diverge from the = default EJB support configuration. =20 From my point of view, I'm as happy as can be with the current state of = the framework. What I would like to see included in 1.0 final = nevertheless is (backward-compatible) support for more exception = categories in the SQLException translator, as suggested by Thomas, and = possibly a convenient option to set a transaction rollback-only no = matter if driven by declarative or programmatic demarcation, as = suggested by Colin and Alef. =20 BTW, I'll send a mail regarding the Spring roadmap shortly. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Rod Johnson Gesendet: Sa 14.02.2004 18:42 An: spr...@li... Betreff: Re: [Springframework-developer] Revised BeanFactoryLocator and = EJB support classes I agree with these changes, but I think we should try to avoid API = changes in general from now to 1.0 final. With RC1 we are committing to a final = API. 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, = mainly 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, = moved 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 = should hold its own *static* logger instance there. Of course, this doesn't = apply 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 = important to destroy resource singletons like a local SessionFactory or PersistenceManager on BeanFactory respectively ApplicationContext = shutdown. I hope you don't mind the name changes. My goal is to keep class and = method naming as consistent as possible within the Spring codebase; something = many 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 ------------------------------------------------------- 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 |