|
From: <jue...@we...> - 2004-04-08 16:29:28
|
Final decision here? I still vote for "AbstractDynamicTargetSource"; at = least against "AbstractPrototypeTargetSource". Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Monday, April 05, 2004 9:51 AM To: spr...@li... Subject: Re: [Springframework-developer] Preparing for 1.0.1 Actually, I still prefer "AbstractDynamicTargetSource": Target beans = being defined as prototypes is a requirement for any meaningful dynamic = target source strategy (no matter if one-shot, ThreadLocal or pooled), = therefore I consider it fine that AbstractDynamicTargetSource implicitly = works with prototype target beans. But just PrototypeTargetSource = delivers actual one-instance-per-method-invocation semantics, rather = than pooling instances or the like. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: So 04.04.2004 16:25 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 That's what I meant with the different meaning of the term "prototype": = AbstractPrototypeTargetSource just assumes that the bean that it = references is a prototype, allowing to expose targets with ThreadLocal = or pooling semantics. On the other hand, PrototypeTargetSource actually = exposes a "prototype" target, i.e. a new target object on each method = invocation (analogous to the term "prototype" used in bean definitions). I agree that the term "prototype" isn't wrong in = AbstractPrototypeTargetSource, but it's used with somewhat different = meaning than in PrototypeTargetSource. To avoid confusion for people = that dig into Spring's javadoc or even implementation, we should use = different terms here, i.e. use the term "prototype" for a more specific = meaning (preferably the one analogous to bean definitions). I'm open for other suggestions, of course! Juergen ________________________________ Von: spr...@li... im Auftrag = von Rod Johnson Gesendet: So 04.04.2004 16:08 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 I guess AbstractDynamicTargetSource is an improvement. I agree the = naming pattern isn't great, but the abstract base class _does_ work with = prototype definitions, so having Prototype in its name does make sense. It's not a generic "Dynamic" TargetSource because it works with bean names and getBeans() assuming a prototype. Any other suggestions? If this is renamed, I'd rather that it was undebatably right. R ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Saturday, April 03, 2004 6:46 PM Subject: Re: [Springframework-developer] Preparing for 1.0.1 A minor naming issue that I've noticed: We have an AbstractPrototypeTargetSource, which serves as base class for PrototypeTargetSource, ThreadLocalTargetSource and AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming pattern anywhere else in the framework. (I've actually removed a similar naming pattern in the AbstractAutoProxyCreator area before 1.0 final.) Furthermore, "AbstractPrototypeTargetSource" is actually a bit = misleading, as we're using a broader meaning of the word prototype here than found = in bean definitions. "PrototypeTargetSource" matches the bean definition = term exactly, but the base class is more generic: So what about renaming it = to "AbstractDynamicTargetSource" or the like, indicating that it serves as = base class for all non-singleton TargetSources? Like the AopUtils move, this should be fine in terms of compatibility = level, as the base class is not part of the public API but rather an internal implementation detail. PrototypeTargetSource and co will still be fully backward compatible after that change, and I doubt that anyone has implemented custom TargetSources yet (and even if, it's trivial to = adapt). Juergen ________________________________ Von: spr...@li... im Auftrag = von Rod Johnson Gesendet: Fr 02.04.2004 16:53 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 I suggest that we sit on this code for at least a week until we release = it, so we can catch anything else. How about we target Monday week for = release? A 1.0.1 release should be driven by stability, not date, so we should = see if any more issues come out of the woodwork. ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Friday, April 02, 2004 10:57 AM Subject: [Springframework-developer] Preparing for 1.0.1 Hi everybody, From my point of view, the code is ready for release 1.0.1. There were a couple of bug fixes and minor enhancements since 1.0 final. The most important fix is proper Hibernate/JTA resource management when flush = fails. Enhancements include the introduction of the MessageCodesResolver = interface in the validation package, and a more efficient internal implementation = of AbstractMessageSource. See the changelog for details. Please give the current CVS snapshot a try. There shouldn't be any = issues, as changes are minor and just affect specific functionality. I'd like to target mid next week for the release, i.e. two weeks after 1.0 final. In = the meantime, the only thing I plan to address is the lack of remoting = coverage in the reference docs. If anyone feels the need to improve other parts = of the docs, please do so till mid next week! Juergen ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |