Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-04-02 17:25:39
|
I've touched quite a lot of files in the aop package but mainly just = applied minor polishing. I did a JDepend analysis and removed some = cyclic dependencies beetwen aop subpackages, mainly affecting the use of = AopConfigException and the location of AopUtils. The latter has moved, = but it's considered an internal class, so this should be fine even for a = point release (Rod takes this point of view too). =20 Other changes include a more efficient AbstractMessageSource = implementation, and the introduction of the MessageCodesResolver = interface in the validation package. A further new feature that I'm = gonna commit tomorrow is to allow for Ant-style patterns as = "contextConfigLocation", for example "/WEB-INF/*-context.xml". This was = pretty easy to add with out existing PathMatcher, which is currently = used by the HandlerMapping implementations. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von tho...@tr... Gesendet: Fr 02.04.2004 18:28 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 I noticed a lot of changes in CVS yesterday - any area in particular = where we should look out for problems? My database product name caching fix is = in CVS now - so even if you don't preconfigure a JdbcTemlpate, you should now = only see one metadata lookup and the rest should be 'found in cache' entries in = the log (INFO). Thomas Quoting Colin Sampaleanu <col...@ex...>: > I've been using the CVS version without issues. I did some=3D20 > proofing/rewriting in the beans chapter earlier this week/last week, = and=3D20 > should probably be able to find time to do the rest by the time you = cut=3D20 > the release. > > j=3DFCrgen h=3DF6ller [werk3AT] wrote: > > >Hi everybody, > >=3D20 > >From my point of view, the code is ready for release 1.0.1. There = were a=3D > couple of bug fixes and minor enhancements since 1.0 final. The most = imp=3D > ortant fix is proper Hibernate/JTA resource management when flush = fails. =3D > Enhancements include the introduction of the MessageCodesResolver = interfa=3D > ce in the validation package, and a more efficient internal = implementatio=3D > n of AbstractMessageSource. See the changelog for details. > >=3D20 > >Please give the current CVS snapshot a try. There shouldn't be any = issue=3D > s, as changes are minor and just affect specific functionality. I'd = like =3D > to target mid next week for the release, i.e. two weeks after 1.0 = final. =3D > In the meantime, the only thing I plan to address is the lack of = remoting=3D > coverage in the reference docs. If anyone feels the need to improve = othe=3D > r parts of the docs, please do so till mid next week! > >=3D20 > >Juergen > > =3D20 > > > > > > ------------------------------------------------------- > 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=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-04-03 17:48:56
|
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.) =20 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? =20 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). =20 Juergen =20 ________________________________ 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 |
|
From: Colin S. <col...@ex...> - 2004-04-03 18:06:22
|
+1 jürgen höller [werk3AT] wrote: >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ürgen höller [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 > > |
|
From: Rod J. <rod...@in...> - 2004-04-04 14:08:07
|
I guess AbstractDynamicTargetSource is an improvement. I agree the naming pattern isn't great, but the abstract base class _does_ work with prototy= pe 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 ter= m exactly, but the base class is more generic: So what about renaming it to "AbstractDynamicTargetSource" or the like, indicating that it serves as b= ase class for all non-singleton TargetSources? Like the AopUtils move, this should be fine in terms of compatibility lev= el, 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 i= t, so we can catch anything else. How about we target Monday week for releas= e? 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 fail= s. Enhancements include the introduction of the MessageCodesResolver interfa= ce in the validation package, and a more efficient internal implementation o= f 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 covera= ge 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 |
|
From: <jue...@we...> - 2004-04-04 14:27:18
|
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). =20 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). =20 I'm open for other suggestions, of course! =20 Juergen =20 ________________________________ 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 |
|
From: <jue...@we...> - 2004-04-05 07:56:14
|
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 |
|
From: <tho...@tr...> - 2004-04-07 14:47:32
|
My changes for 1.0.1 are ready to go: Package org.springframework.jdbc.object * added method setSqlReadyForUse to StoredProcedure for indicating that the sql should be used as provided, no need to add parameter placeholders Package org.springframework.jdbc.support * changed SQLErrorCodesFactory, it now caches database product name in a Map based on hashCode from DataSource to avoid unnecessary meta data lookups * added an extractDatabaseMetaData method to JdbcUtils. This change also adds an interface named DatabaseMetaDataCallBackHandler that must be used for this method How do we want to proceed for 1.0.2 and 1.1. Should we just add new features and release what is stable for 1.0.2 or do we want to limit 1.0.2 to strictly bug fixes and hold on to any enhancements until 1.1? Thomas |
|
From: <rod...@in...> - 2004-04-07 17:00:17
|
>How do we want to proceed for 1.0.2 and 1.1. Should we just add new features and release what is stable for 1.0.2 or do we want to limit 1.0.2 to strictly bug fixes and hold on to any enhancements until 1.1? I think 1.0.2 (if we need it!) should be strictly bug fixes. No enhancements, except possibly a new method here or there if it's 100% backward compatible. |
|
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 |
|
From: Rod J. <rod...@in...> - 2004-04-08 18:21:41
|
AbstractDynamicTargetSource is OK by me, although I'm not in love with it. Technically of course a dynamic target source need not use the bean facto= ry at all. But AbstractPrototypeBasedTargetSource is a bit wordy... ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, April 08, 2004 5:27 PM Subject: Re: [Springframework-developer] Preparing for 1.0.1 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 bein= g 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 instanc= es or the like. Juergen ________________________________ 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 referenc= es 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 mean= ing than in PrototypeTargetSource. To avoid confusion for people that dig int= o Spring's javadoc or even implementation, we should use different terms he= re, 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 prototy= pe 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 ter= m exactly, but the base class is more generic: So what about renaming it to "AbstractDynamicTargetSource" or the like, indicating that it serves as b= ase class for all non-singleton TargetSources? Like the AopUtils move, this should be fine in terms of compatibility lev= el, 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 i= t, so we can catch anything else. How about we target Monday week for releas= e? 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 fail= s. Enhancements include the introduction of the MessageCodesResolver interfa= ce in the validation package, and a more efficient internal implementation o= f 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 covera= ge 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 ------------------------------------------------------- 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 |
|
From: <jue...@we...> - 2004-04-09 06:00:41
|
"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, = as it hits the nail: "prototype-based" is what it is. I've got a new = favourite :-) Juergen ________________________________ Von: spr...@li... im Auftrag = von Rod Johnson Gesendet: Do 08.04.2004 20:21 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 AbstractDynamicTargetSource is OK by me, although I'm not in love with = it. Technically of course a dynamic target source need not use the bean = factory at all. But AbstractPrototypeBasedTargetSource is a bit wordy... ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, April 08, 2004 5:27 PM Subject: Re: [Springframework-developer] Preparing for 1.0.1 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. Juergen ________________________________ 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 ------------------------------------------------------- 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 |
|
From: Rod J. <rod...@in...> - 2004-04-13 19:03:05
|
OK, lets go for that then. Verbose is not a problem, as users won't norma= lly use (or bother looking at) that class. ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Friday, April 09, 2004 6:57 AM Subject: Re: [Springframework-developer] Preparing for 1.0.1 "AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, a= s it hits the nail: "prototype-based" is what it is. I've got a new favouri= te :-) Juergen ________________________________ Von: spr...@li... im Auftrag von Rod Johnson Gesendet: Do 08.04.2004 20:21 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 AbstractDynamicTargetSource is OK by me, although I'm not in love with it. Technically of course a dynamic target source need not use the bean facto= ry at all. But AbstractPrototypeBasedTargetSource is a bit wordy... ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, April 08, 2004 5:27 PM Subject: Re: [Springframework-developer] Preparing for 1.0.1 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 bein= g 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 instanc= es or the like. Juergen ________________________________ 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 referenc= es 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 mean= ing than in PrototypeTargetSource. To avoid confusion for people that dig int= o Spring's javadoc or even implementation, we should use different terms he= re, 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 prototy= pe 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 ter= m exactly, but the base class is more generic: So what about renaming it to "AbstractDynamicTargetSource" or the like, indicating that it serves as b= ase class for all non-singleton TargetSources? Like the AopUtils move, this should be fine in terms of compatibility lev= el, 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 i= t, so we can catch anything else. How about we target Monday week for releas= e? 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 fail= s. Enhancements include the introduction of the MessageCodesResolver interfa= ce in the validation package, and a more efficient internal implementation o= f 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 covera= ge 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 ------------------------------------------------------- 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 |
|
From: <jue...@we...> - 2004-04-13 07:10:31
|
Everybody, =20 As we're about to release Spring 1.0.1 by the beginning of next week, we = need to re-test the current CVS contents thoroughly. The most important = area is Hibernate/JTA integration: Flushing failures should now be = handled properly; and ThreadLocal Sessions should work without = JtaTransactionManager too, as long as there's a Hibernate = TransactionManagerLookup configured.=20 =20 As a side note: Hibernate's TransactionManagerLookup can be configured = via Spring too, passing a javax.transaction.TransactionManager into = LocalSessionFactoryBean's "jtaTransactionManager" property. Normally, = this will be a JndiObjectFactoryBean reference, possibly shared with = JtaTransactionManager (i.e. passed into the latter's = "transactionManager" property too). =20 If anyone finds some further areas in the documentation that need = completion or polishing, please address them this week rather than next = one :-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von j=FCrgen h=F6ller [werk3AT] Gesendet: Fr 09.04.2004 07:57 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 "AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, = as it hits the nail: "prototype-based" is what it is. I've got a new = favourite :-) Juergen ________________________________ Von: spr...@li... im Auftrag = von Rod Johnson Gesendet: Do 08.04.2004 20:21 An: spr...@li... Betreff: Re: [Springframework-developer] Preparing for 1.0.1 AbstractDynamicTargetSource is OK by me, although I'm not in love with = it. Technically of course a dynamic target source need not use the bean = factory at all. But AbstractPrototypeBasedTargetSource is a bit wordy... ----- Original Message ----- From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Thursday, April 08, 2004 5:27 PM Subject: Re: [Springframework-developer] Preparing for 1.0.1 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. Juergen ________________________________ 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 ------------------------------------------------------- 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 |
|
From: Colin S. <col...@ex...> - 2004-04-13 13:45:54
|
I've been using the CVS version without issues; actually it's even in=20 production... I have on my todo list to create a test case for=20 testing the new Hibernate JTA stuff with CMT; I've been busy, but will=20 make sure this is done by the weekend... Regards, Colin j=FCrgen h=F6ller [werk3AT] wrote: >Everybody, >=20 >As we're about to release Spring 1.0.1 by the beginning of next week, we= need to re-test the current CVS contents thoroughly. The most important = area is Hibernate/JTA integration: Flushing failures should now be handle= d properly; and ThreadLocal Sessions should work without JtaTransactionMa= nager too, as long as there's a Hibernate TransactionManagerLookup config= ured.=20 >=20 >As a side note: Hibernate's TransactionManagerLookup can be configured v= ia Spring too, passing a javax.transaction.TransactionManager into LocalS= essionFactoryBean's "jtaTransactionManager" property. Normally, this will= be a JndiObjectFactoryBean reference, possibly shared with JtaTransactio= nManager (i.e. passed into the latter's "transactionManager" property too= ). >=20 >If anyone finds some further areas in the documentation that need comple= tion or polishing, please address them this week rather than next one :-) >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag vo= n j=FCrgen h=F6ller [werk3AT] >Gesendet: Fr 09.04.2004 07:57 >An: spr...@li... >Betreff: Re: [Springframework-developer] Preparing for 1.0.1 > > > >"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, = as it hits the nail: "prototype-based" is what it is. I've got a new favo= urite :-) > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag vo= n Rod Johnson >Gesendet: Do 08.04.2004 20:21 >An: spr...@li... >Betreff: Re: [Springframework-developer] Preparing for 1.0.1 > > > >AbstractDynamicTargetSource is OK by me, although I'm not in love with i= t. >Technically of course a dynamic target source need not use the bean fact= ory >at all. But AbstractPrototypeBasedTargetSource is a bit wordy... > >----- Original Message ----- >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> >To: <spr...@li...> >Sent: Thursday, April 08, 2004 5:27 PM >Subject: Re: [Springframework-developer] Preparing for 1.0.1 > > >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 bei= ng >defined as prototypes is a requirement for any meaningful dynamic target >source strategy (no matter if one-shot, ThreadLocal or pooled), therefor= e 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 instan= ces >or the like. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag vo= n >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 referen= ces >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 mea= ning >than in PrototypeTargetSource. To avoid confusion for people that dig in= to >Spring's javadoc or even implementation, we should use different terms h= ere, >i.e. use the term "prototype" for a more specific meaning (preferably th= e >one analogous to bean definitions). > >I'm open for other suggestions, of course! > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag vo= n >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 namin= g >pattern isn't great, but the abstract base class _does_ work with protot= ype >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 misleadin= g, >as we're using a broader meaning of the word prototype here than found i= n >bean definitions. "PrototypeTargetSource" matches the bean definition te= rm >exactly, but the base class is more generic: So what about renaming it t= o >"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 le= vel, >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 vo= n >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 relea= se? > >A 1.0.1 release should be driven by stability, not date, so we should se= e 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 fai= ls. >Enhancements include the introduction of the MessageCodesResolver interf= ace >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 issue= s, >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 cover= age >in the reference docs. If anyone feels the need to improve other parts o= f >the docs, please do so till mid next week! > >Juergen > =20 > |
|
From: Les A. H. <le...@ha...> - 2004-04-15 15:59:52
|
I'd like to jump in on this discussion since it is related to a question I'v=
e
been meaning to ask....
I tried asking a question about BMT vs. CMT declarations when coding Spring
EJB's on the user list, but apparently nobody wanted to touch that :) So, I
figured I'd ask here and realized this thread may have something to do with =
my
subject...
I have some EJB's that are POJO backed (i.e. the common case where all the E=
JB
method does is just directly call the pojo method with the same method
signature...nothing more). These POJO's are of course Spring configured and
use a TransactionProxyFactoryBean to allow me to declaritively control
transaction/isolation levels for the pojos.
Since I use the TransactionProxyFactoryBean to configure transactional behav=
ior
on the pojos, should I tell XDoclect when it generates by EJB deployment
descriptors that I'm using BMT instead of the default CMT?
Also, related to this thread, I noticed Colin's response about the Hibernate=
JTA
stuff with CMT. I am using Hibernate as well and I have a couple of EJB's t=
hat
haven't yet been POJO-ified and use XDoclet CMT declarations. Does the newl=
y
added functionality Colin references help me in any way? If so, how? Of
course, I intend to fully "POJO-ify" my other EJB's and use Springs declarit=
ive
transaction management, but this may not happen as soon as I like due to
potentially disrupting my development schedule.
I should note that I'm using Hibernate as a JCA configured JBoss MBean as
described on Hibernate's website. The mbean configuration uses the
net.sf.hibernate.transaction.JBossTransactionManagerLookup lookup strategy a=
nd
the userTransactionName ("java:/UserTransaction" for JBoss). How does this
affect how I use Spring? Currently I just get the Hibernate SessionFactory
using a JndiObjectFactoryBean since its already bound to JNDI via the JCA
configuration. I also declare the JtaTransactionManager as a Spring bean
definition as described in the Spring documentation. Do I even need to do t=
his
if I've already configured Hibernate as described above? I mean, if I alrea=
dy
supply a transaction lookup strategy and the user transaction name in the mb=
ean
configuration, why would I need to declare a Spring JtaTransactionManager be=
an?
Your comments and insight are always gratefully received,
Les
Quoting Colin Sampaleanu <col...@ex...>:
> I've been using the CVS version without issues; actually it's even in
> production... I have on my todo list to create a test case for
> testing the new Hibernate JTA stuff with CMT; I've been busy, but will
> make sure this is done by the weekend...
>
> Regards,
> Colin
>
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
> >Everybody,
> >
> >As we're about to release Spring 1.0.1 by the beginning of next week, we
> need to re-test the current CVS contents thoroughly. The most important ar=
ea
> is Hibernate/JTA integration: Flushing failures should now be handled
> properly; and ThreadLocal Sessions should work without JtaTransactionManag=
er
> too, as long as there's a Hibernate TransactionManagerLookup configured.
> >
> >As a side note: Hibernate's TransactionManagerLookup can be configured vi=
a
> Spring too, passing a javax.transaction.TransactionManager into
> LocalSessionFactoryBean's "jtaTransactionManager" property. Normally, this
> will be a JndiObjectFactoryBean reference, possibly shared with
> JtaTransactionManager (i.e. passed into the latter's "transactionManager"
> property too).
> >
> >If anyone finds some further areas in the documentation that need complet=
ion
> or polishing, please address them this week rather than next one :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> j=FCrgen h=F6ller [werk3AT]
> >Gesendet: Fr 09.04.2004 07:57
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >
> >"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, a=
s
> it hits the nail: "prototype-based" is what it is. I've got a new favourit=
e
> :-)
> >
> >Juergen
> >
> >
> >________________________________
> >
> >Von: spr...@li... im Auftrag von
> Rod Johnson
> >Gesendet: Do 08.04.2004 20:21
> >An: spr...@li...
> >Betreff: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >
> >AbstractDynamicTargetSource is OK by me, although I'm not in love with it=
.
> >Technically of course a dynamic target source need not use the bean facto=
ry
> >at all. But AbstractPrototypeBasedTargetSource is a bit wordy...
> >
> >----- Original Message -----
> >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
> >To: <spr...@li...>
> >Sent: Thursday, April 08, 2004 5:27 PM
> >Subject: Re: [Springframework-developer] Preparing for 1.0.1
> >
> >
> >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 bein=
g
> >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 instanc=
es
> >or the like.
> >
> >Juergen
> >
> >
> >________________________________
> >
> >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 referenc=
es
> >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 mean=
ing
> >than in PrototypeTargetSource. To avoid confusion for people that dig int=
o
> >Spring's javadoc or even implementation, we should use different terms he=
re,
> >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 prototy=
pe
> >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 ter=
m
> >exactly, but the base class is more generic: So what about renaming it to
> >"AbstractDynamicTargetSource" or the like, indicating that it serves as b=
ase
> >class for all non-singleton TargetSources?
> >
> >Like the AopUtils move, this should be fine in terms of compatibility lev=
el,
> >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 i=
t,
> >so we can catch anything else. How about we target Monday week for releas=
e?
> >
> >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 fail=
s.
> >Enhancements include the introduction of the MessageCodesResolver interfa=
ce
> >in the validation package, and a more efficient internal implementation o=
f
> >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 covera=
ge
> >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=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: <rod...@in...> - 2004-04-13 08:26:29
|
>As we're about to release Spring 1.0.1 by the beginning of next week, we need to re-test the current CVS contents thoroughly. Yes. I'd like to see a code freeze on the /src tree before the release--say tomorrow?--except for any bug fixes. Juergen, is this feasible? Stability is paramount with 1.0.1. We have some worthwhile new features, like sophisticated Struts integration, that we should definitely include, but we need to try to bed down 1.0 with this release so we can focus on 1.1. Regards, Rod |
|
From: <jue...@we...> - 2004-04-13 10:14:49
|
Rod, A code freeze should be feasible from my point of view. As I'm heading = to Prague for a 4-day break tomorrow, I certainly won't do any further = code changes - just the actual release on Sunday :-) Besides various stability and performance improvements, there are a = couple of noteworthy enhancements respectively new features for 1.0.1: - BeanWrapperImpl allows for registration of custom editors for = array/List/Map properties and specific elements of array/List/Map = properties - AbstractXmlApplicationContext (and thus its subclasses like = XmlWebApplicationContext) supports file patterns as config location, for = example "/WEB-INF/*-context.xml" - validation framework delegates to a MessageCodesResolver strategy for = building error codes for ObjectErrors and FieldErrors, with a more = sophisticated default implementation - transaction-scoped Hibernate Sessions are provided even for plain JTA = respectively EJB CMT transactions, without JtaTransactionManager being = involved (mainly intended for implementing EJBs) - sophisticated Struts integration, with support classes for accessing a = Spring context, a ContextLoaderPlugIn, and a way to wire Struts Actions = as Spring-managed beans I'm not sure if we'll already be able to concentrate on 1.1 next. = Neither JMS support nor JMX support nor declarative validation has = reached milestone shape yet. I guess it's pretty safe to assume that 1.1 RC1 is still several months = away. I'm almost certain that we'll find enough minor issues to warrant = a 1.0.2 release in the meantime. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of rod...@in... Sent: Tuesday, April 13, 2004 10:26 AM To: spr...@li... Subject: Re: [Springframework-developer] Preparing for 1.0.1 >As we're about to release Spring 1.0.1 by the beginning of=20 next week, we need to re-test the current CVS contents=20 thoroughly.=20 Yes. I'd like to see a code freeze on the /src tree before=20 the release--say tomorrow?--except for any bug fixes.=20 Juergen, is this feasible? Stability is paramount with 1.0.1. We have some worthwhile=20 new features, like sophisticated Struts integration, that we=20 should definitely include, but we need to try to bed down 1.0=20 with this release so we can focus on 1.1. Regards, Rod ------------------------------------------------------- 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=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Thomas R. <tho...@tr...> - 2004-04-13 12:45:47
|
I have added support for translating the SQL state code returned by PostgreSQL 7.4. I added a property 'useSqlStateForTranslation' to SqlErrorCodes and the test for this is SqlErrorCodeSQLExceptionTranslator. This is kind of a hack, but it will work until Postgres supplies error codes some day in the future (maybe). Thomas jürgen höller [werk3AT] wrote: >Rod, > >A code freeze should be feasible from my point of view. As I'm heading to Prague for a 4-day break tomorrow, I certainly won't do any further code changes - just the actual release on Sunday :-) > > >Besides various stability and performance improvements, there are a couple of noteworthy enhancements respectively new features for 1.0.1: > >- BeanWrapperImpl allows for registration of custom editors for array/List/Map properties and specific elements of array/List/Map properties > >- AbstractXmlApplicationContext (and thus its subclasses like XmlWebApplicationContext) supports file patterns as config location, for example "/WEB-INF/*-context.xml" > >- validation framework delegates to a MessageCodesResolver strategy for building error codes for ObjectErrors and FieldErrors, with a more sophisticated default implementation > >- transaction-scoped Hibernate Sessions are provided even for plain JTA respectively EJB CMT transactions, without JtaTransactionManager being involved (mainly intended for implementing EJBs) > >- sophisticated Struts integration, with support classes for accessing a Spring context, a ContextLoaderPlugIn, and a way to wire Struts Actions as Spring-managed beans > > >I'm not sure if we'll already be able to concentrate on 1.1 next. Neither JMS support nor JMX support nor declarative validation has reached milestone shape yet. > >I guess it's pretty safe to assume that 1.1 RC1 is still several months away. I'm almost certain that we'll find enough minor issues to warrant a 1.0.2 release in the meantime. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of rod...@in... >Sent: Tuesday, April 13, 2004 10:26 AM >To: spr...@li... >Subject: Re: [Springframework-developer] Preparing for 1.0.1 > > > > >>As we're about to release Spring 1.0.1 by the beginning of >> >> >next week, we need to re-test the current CVS contents >thoroughly. >Yes. I'd like to see a code freeze on the /src tree before >the release--say tomorrow?--except for any bug fixes. >Juergen, is this feasible? > >Stability is paramount with 1.0.1. We have some worthwhile >new features, like sophisticated Struts integration, that we >should definitely include, but we need to try to bed down 1.0 >with this release so we can focus on 1.1. > >Regards, >Rod > > >------------------------------------------------------- >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_id=3638&op=click >_______________________________________________ >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_id70&alloc_id638&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > |
|
From: Kopylenko, D. <dko...@ac...> - 2004-04-13 13:51:34
|
The CVS version is in production. No issues reported so far... Regards, Dmitriy. -----Original Message----- From: Colin Sampaleanu [mailto:col...@ex...]=20 Sent: Tuesday, April 13, 2004 9:46 AM To: spr...@li... Subject: Re: [Springframework-developer] Preparing for 1.0.1 I've been using the CVS version without issues; actually it's even in=20 production... I have on my todo list to create a test case for=20 testing the new Hibernate JTA stuff with CMT; I've been busy, but will=20 make sure this is done by the weekend... Regards, Colin j=FCrgen h=F6ller [werk3AT] wrote: >Everybody, >=20 >As we're about to release Spring 1.0.1 by the beginning of next week,=20 >we need to re-test the current CVS contents thoroughly. The most = important area is Hibernate/JTA integration: Flushing failures should now be = handled properly; and ThreadLocal Sessions should work without = JtaTransactionManager too, as long as there's a Hibernate TransactionManagerLookup = configured. >=20 >As a side note: Hibernate's TransactionManagerLookup can be configured = >via Spring too, passing a javax.transaction.TransactionManager into LocalSessionFactoryBean's "jtaTransactionManager" property. Normally, = this will be a JndiObjectFactoryBean reference, possibly shared with JtaTransactionManager (i.e. passed into the latter's = "transactionManager" property too). >=20 >If anyone finds some further areas in the documentation that need=20 >completion or polishing, please address them this week rather than = next one :-) >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag=20 >von j=FCrgen h=F6ller [werk3AT] >Gesendet: Fr 09.04.2004 07:57 >An: spr...@li... >Betreff: Re: [Springframework-developer] Preparing for 1.0.1 > > > >"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like = it,=20 >as it hits the nail: "prototype-based" is what it is. I've got a new=20 >favourite :-) > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag=20 >von Rod Johnson >Gesendet: Do 08.04.2004 20:21 >An: spr...@li... >Betreff: Re: [Springframework-developer] Preparing for 1.0.1 > > > >AbstractDynamicTargetSource is OK by me, although I'm not in love with = >it. Technically of course a dynamic target source need not use the = bean=20 >factory at all. But AbstractPrototypeBasedTargetSource is a bit=20 >wordy... > >----- Original Message ----- >From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> >To: <spr...@li...> >Sent: Thursday, April 08, 2004 5:27 PM >Subject: Re: [Springframework-developer] Preparing for 1.0.1 > > >Final decision here? I still vote for "AbstractDynamicTargetSource"; = at=20 >least against "AbstractPrototypeTargetSource". > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On = Behalf=20 >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=20 >being defined as prototypes is a requirement for any meaningful = dynamic=20 >target source strategy (no matter if one-shot, ThreadLocal or pooled), = >therefore I consider it fine that AbstractDynamicTargetSource=20 >implicitly works with prototype target beans. But just=20 >PrototypeTargetSource delivers actual=20 >one-instance-per-method-invocation semantics, rather than pooling=20 >instances or the like. > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag=20 >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":=20 >AbstractPrototypeTargetSource just assumes that the bean that it=20 >references is a prototype, allowing to expose targets with ThreadLocal = >or pooling semantics. On the other hand, PrototypeTargetSource = actually=20 >exposes a "prototype" target, i.e. a new target object on each method=20 >invocation (analogous to the term "prototype" used in bean=20 >definitions). > >I agree that the term "prototype" isn't wrong in=20 >AbstractPrototypeTargetSource, but it's used with somewhat different=20 >meaning than in PrototypeTargetSource. To avoid confusion for people=20 >that dig into Spring's javadoc or even implementation, we should use=20 >different terms here, i.e. use the term "prototype" for a more = specific=20 >meaning (preferably the one analogous to bean definitions). > >I'm open for other suggestions, of course! > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag=20 >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=20 >naming pattern isn't great, but the abstract base class _does_ work=20 >with prototype definitions, so having Prototype in its name does make=20 >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=20 >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=20 >AbstractPrototypeTargetSource, which serves as base class for=20 >PrototypeTargetSource, ThreadLocalTargetSource and=20 >AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming=20 >pattern anywhere else in the framework. (I've actually removed a=20 >similar naming pattern in the AbstractAutoProxyCreator area before 1.0 = >final.) > >Furthermore, "AbstractPrototypeTargetSource" is actually a bit=20 >misleading, as we're using a broader meaning of the word prototype = here=20 >than found in bean definitions. "PrototypeTargetSource" matches the=20 >bean definition term exactly, but the base class is more generic: So=20 >what about renaming it to "AbstractDynamicTargetSource" or the like,=20 >indicating that it serves as base class for all non-singleton=20 >TargetSources? > >Like the AopUtils move, this should be fine in terms of compatibility=20 >level, as the base class is not part of the public API but rather an=20 >internal implementation detail. PrototypeTargetSource and co will = still=20 >be fully backward compatible after that change, and I doubt that = anyone=20 >has implemented custom TargetSources yet (and even if, it's trivial to = >adapt). > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag=20 >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=20 >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=20 >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=20 >fails. Enhancements include the introduction of the=20 >MessageCodesResolver interface in the validation package, and a more=20 >efficient internal implementation of AbstractMessageSource. See the=20 >changelog for details. > >Please give the current CVS snapshot a try. There shouldn't be any=20 >issues, as changes are minor and just affect specific functionality.=20 >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=20 >lack of remoting coverage in the reference docs. If anyone feels the=20 >need to improve other parts of the docs, please do so till mid next=20 >week! > >Juergen > =20 > ------------------------------------------------------- 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=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
