RE: [Springframework-developer] Transaction support

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

"examples" dir in the "main" module sounds good to me.
+1 on this.

Dmitriy.

-----Original Message-----
From: William G. Thompson, Jr. [mailto:wg...@rc...]
Sent: Thursday, April 03, 2003 09:51 AM
To: spring-dev-list
Subject: Re: [Springframework-developer] Transaction support

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=FCrgen h=F6ller [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.
>=20
> Rod, where do you intend to put the adapted example app from the =
book?
>=20
> 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.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 3:11 PM
> To: j=FCrgen h=F6ller [werk3AT]; spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> How about "Spring/examples" tree on CVS HEAD with package structure
somewhat
> like this: com.interface21.sample.<sample_module_name>.<sub_packages> =
?
>=20
> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:57 AM
> To: spring-dev-list
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> Dmitriy, everybody,
>=20
> 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.
>=20
> 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?
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Kopylenko, Dmitry [mailto:dko...@ac...]
> Sent: Thursday, April 03, 2003 2:50 PM
> To: j=FCrgen h=F6ller [werk3AT]
> Cc: 'spring-dev-list'
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> Juergen, guys,
> are you planning any sample apps/detailed usage docs (on transaction
support
> for example) for 0.8 release?
>=20
> Rod,=20
> when do you think the aopalliance.org will be up and running?
>=20
> Thanks.
>=20
> Dmitriy.
>=20
> -----Original Message-----
> From: j=FCrgen h=F6ller [werk3AT] =
[mailto:jue...@we...]
> Sent: Thursday, April 03, 2003 07:39 AM
> To: spr...@li...
> Subject: RE: [Springframework-developer] Transaction support
>=20
>=20
> Rod,
>=20
> I guess removing the check in TransactionInterceptor and modifying =
the
test
> case accordingly will solve the issue.
>=20
> 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...
>=20
> 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.
>=20
> 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.
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Thursday, April 03, 2003 2:27 PM
> To: j=FCrgen h=F6ller [werk3AT];
> spr...@li...
> Subject: Re: [Springframework-developer] Transaction support
>=20
>=20
> Juergen,
>=20
> 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).
>=20
> I haven't looked at your code in great detail, but from what I've =
seen it
> looks good and I endorse the design.
>=20
> Regards,
> Rod
>=20
>=20
> Hi Rod,
>=20
> I've just seen your modifications to TransactionInterceptor. You've =
added
> explicit programmatic rollback handling, i.e.
>=20
> if (status !=3D null && !status.isRollbackOnly()) {
> // Normal course of transaction: commit
> doCommit();
> }
> else {
> // Handle programmatic rollback
> doRollback();
> }
>=20
> 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.
>=20
> 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).
>=20
> All things considered, I suggest to remove the explicit check above =
if you
> don't mind, as it is unnecessary.
>=20
> Generally, what do you think of the current state of the transaction
> support? Any limitations or inappropriate design decisions?
>=20
>=20

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:=20
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer