Re: [Springframework-developer] Preparing for 1.0.1

[Les A. H. <le...@ha...>]

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
>