Re: [Springframework-developer] Preparing for 1.0.1

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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
>