RE: [Springframework-developer] Update

[<jue...@we...>]

Rod,

It seems that the old AOP classes in com.interface21.aop are still in =
CVS. This package should be empty according to your new implementation, =
shouldn't it? Let's remove the old stuff to avoid confusion.

Juergen


> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]=20
> Sent: Sunday, March 23, 2003 1:50 AM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Update
>=20
>=20
> To prove I really am practising test first development these=20
> days, the test coverage on the aop.framework package is 95%.=20
> I am very keen that the overall test coverage should increase=20
> over time: it seems to be falling marginally.
>=20
> I'm still working on the aop.interceptor.transaction package,=20
> which was based on old code, so it will have comprehensive=20
> tests in a few days.
>=20
> Regards,
> Rod
>=20
> ----- Original Message -----
> From: "Rod Johnson" <rod...@in...>
> To: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>;=20
> <spr...@li...>
> Sent: Sunday, March 23, 2003 12:40 AM
> Subject: Re: [Springframework-developer] Update
>=20
>=20
> > All,
> >
> > I've now checked in my new AOP framework=20
> > (com.interface21.aop.framework), and the accompanying tests. The=20
> > org.aopalliance packages (binaries
> included
> > in /lib directory) are the APIs currently agreed by myself,=20
> Jon Tirsen=20
> > (Nanning Aspects) and Bob Lee (jAdvise) for interoperability. The=20
> > metadata attribute implementation is pluggable, but I'm planning to=20
> > use Attrib4j
> > (Sourceforge) and have been in touch with Mark Pollack, the=20
> author, who's
> > keen to help it meet our requirements.
> >
> > NB: The old AOP packages are gone: everyone please make sure they=20
> > don't
> have
> > the old sources hanging around.
> >
> > I've also checked in a com.interface21.aop.interceptor.transaction=20
> > package containing a generic CMT interceptor. The=20
> > PlatformTransactionManager is in this package: let me know if there=20
> > are any problems in the design of this interface.
> >
> >
> > Juergen,
> >
> > We're on the same track with the JTA callback approach you've=20
> > suggested,
> so
> > we should pool our efforts.
> >
> > My thoughts:
> >
> > - I don't like statics. For example, it's impossible to use a test
> subclass
> > overriding methods to check usage. So I'd prefer that it was a true
> object,
> > even if there's no state at this point. After all, the cost of tx
> management
> > is far greater than the cost of creating and destroying a small=20
> > object. Also, I think some state may come in (see below).=20
> For example,=20
> > your "allow no JTA" could be a bean property.
> > - My proposed callback interface (which I hadn't implemented yet)=20
> > returned
> a
> > boolean, indicating whether the tx should be committed or rollback.=20
> > I'm
> not
> > sure whether this is better than void, as it makes the interface=20
> > slightly harder to implement.
> > - I agree with your approach to exceptions and rollback.
> > - Do you intend to allow a setRollbackOnly mechanism or the=20
> like? My=20
> > AOP transaction interceptor has a TxControl class that allows this.=20
> > Maybe this class could be refactored into the common package. This=20
> > could be an alternative to the boolean return for enforcing=20
> rollback.=20
> > I'm not sure
> which
> > approach would be the best.
> > - I don't much like sharing the dao exceptions. I've checked in the=20
> > com.interface21.transaction package which contains my unchecked tx
> exception
> > hierarchy, which my tx interceptor uses. I'd prefer to=20
> standardize on
> this.
> >
> > I think the biggest questions are:
> >
> > - Do we want to try to refactor so that the new jta package=20
> shares the=20
> > TransactionControl and PlatformTransactionServices=20
> implementation from=20
> > my AOP transaction interceptor package? This would mean that the=20
> > callback wasn't JTA-specific, but could work with any=20
> > PlatformTransactionManager implementation. The common functionality=20
> > would be in the com.interface21.transaction package and multiple
> PlatformTransactionManager
> > implementations could be in packages such as=20
> > com.interface21.transaction.jta/wls/jboss etc.
> > - Is my PlatformTransactionManager interface adequate for=20
> this goal or=20
> > for how I'm trying to use it in the AOP stuff.
> >
> > Ideally it would be good if we pooled our efforts on a really good
> low-level
> > tx infrastructure, leaving the AOP interceptor as just a thin layer=20
> > over that.
> >
> > I think there's probably a bit more discussion to have before you=20
> > check in your callback mechanism.
> >
> > Regards,
> > Rod