Re: [Springframework-developer] Transaction support

[William G. T. Jr. <wg...@rc...>]

Speaking of project docs... Apache Forrest is starting to look good for 
xml based project docs.  http://xml.apache.org/forrest/index.html

+1 for the seperate source dirs.

later.
Bill

jürgen höller [werk3AT] wrote:
> Maybe it would be easier to handle if we simply added an additional source directory "examples" besides "src" and "test", containing the packages you propose? I don't see a need for a separate CVS module for "core examples", although there are arguments for it.
> 
> Rod, where do you intend to put the adapted example app from the book?
> 
> Another issue is where to put misc docs, but I consider the "docs" directory used by the javadoc Ant task (it uses "docs/api", more specifically) an appropriate location. We will probably need to restructure the (non-API) docs when they become more organized anyway.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 3:11 PM
> To: jürgen höller [werk3AT]; spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> How about "Spring/examples" tree on CVS HEAD with package structure somewhat
> like this: com.interface21.sample.<sample_module_name>.<sub_packages> ?
> 
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:57 AM
> To: spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> Dmitriy, everybody,
> 
> Well, sample apps and usage docs would help a lot, of course. I'm willing to
> put effort into these as soon as we decide to settle on the current design
> of the transaction support.
> 
> I'm not sure where to put these resources, though. Tx support documentation
> could go into the package JavaDocs of the transaction package, this would be
> a natural fit. But where should we put example classes? Hibernate puts them
> in its net.sf.hibernate.eg package, but I'm not sure if it is a particulary
> good idea to put examples in the main source tree. What do you think?
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 2:50 PM
> To: jürgen höller [werk3AT]
> Cc: 'spring-dev-list'
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> Juergen, guys,
> are you planning any sample apps/detailed usage docs (on transaction support
> for example) for 0.8 release?
> 
> Rod, 
> when do you think the aopalliance.org will be up and running?
> 
> Thanks.
> 
> Dmitriy.
> 
> -----Original Message-----
> From: jürgen höller [werk3AT] [mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:39 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Transaction support
> 
> 
> Rod,
> 
> I guess removing the check in TransactionInterceptor and modifying the test
> case accordingly will solve the issue.
> 
> Now that we seem to approach a certain degree of stability in terms of
> transaction support too, we should actively consider releasing 0.8. We're
> not really following "release early, release often" up to now...
> 
> A combined developer download will be enough for the moment, I assume, we
> don't really need a binary-only download before 1.0. Have you looked at how
> SourceForge's release support works already? It shouldn't be hard to figure
> out.
> 
> Even for 0.8, we should try to raise some attention just after the release,
> for example at TheServerSide. We could gain important feedback, long enough
> before 1.0 to be able to still tweak the design if necessary.
> 
> Juergen
> 
> 
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Thursday, April 03, 2003 2:27 PM
> To: jürgen höller [werk3AT];
> spr...@li...
> Subject: Re: [Springframework-developer] Transaction support
> 
> 
> Juergen,
> 
> I needed to put that check in to get the tests to pass. However, the
> clarification about how PlatformTransactionManager implementations should
> behave would also resolve the problem (meaning I could modify the test case,
> not the class).
> 
> I haven't looked at your code in great detail, but from what I've seen it
> looks good and I endorse the design.
> 
> Regards,
> Rod
> 
> 
> Hi Rod,
> 
> I've just seen your modifications to TransactionInterceptor. You've added
> explicit programmatic rollback handling, i.e.
> 
> if (status != null && !status.isRollbackOnly()) {
> // Normal course of transaction: commit
> doCommit();
> }
> else {
> // Handle programmatic rollback
> doRollback();
> }
> 
> where doCommit and doRollback call PlatformTransactionManager's commit and
> rollback, respectively. Technically, this isn't necessary, as the
> PlatformTransactionManager implementation is supposed to handle this. That
> way, every transaction manager client can benefit from it implicitly.
> Unfortunately, PlatformTransactionManager's documentation currently doesn't
> state that, so I will add appropriate JavaDoc.
> 
> By deriving from AbstractPlatformTransactionManager instead of implementing
> PlatformTransactionManager directly, a transaction manager implementation
> can benefit from the former's programmatic rollback and propagation behavior
> handling. A subclass just needs to implement doCommit, doRollback, etc
> without having to care about such case handling that will normally be the
> same (see JtaTransactionManager).
> 
> All things considered, I suggest to remove the explicit check above if you
> don't mind, as it is unnecessary.
> 
> Generally, what do you think of the current state of the transaction
> support? Any limitations or inappropriate design decisions?
> 
>