> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jeff > Haynie > Sent: Wednesday, March 26, 2003 11:07 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration > > > Bill, > > This is fabulous stuff. Good job. >
JBoss Remoting is much more fabulous. We need to get the word out on it... > Is there a way we might be able to use the AOP xml to dynamically do > your example below (as well as the clustered and remoting) for POJOs > during construction time? In other words, could you not have an > interceptor on a constructor pointcut that would do this for you and > dynamically make the class Versionable, Clusterable, Remotable, etc. so > that the actual instance you receive back has these capabilities > transparently w/o having to programatically do this? > > The advantages of this would be that you could dynamically modify the > POJO from the XML file without having to do it programmatically (of > course, you could if you wanted to). That way, we can truly separate > the business logic (as an example, no flames here) from the > cross-cutting of concerns such as transactibility, security, remoteness, > etc. > > Looking at the jboss-aop.xml in the testsuite - it looks like you're > doing this with the Tx Interceptor on the VersionedPOJO - why not just > create the VersionedPOJO in the same way and insert the Versioned > Interceptor the same way? Is this possible? > I totally agree. And yes, a constructor pointcut is the way to go. The only downside of constructor pointcuts is that reflection bypasses the interception! Same thing with field interception. The problem is that unlike methods, you have to modify the bytecode of the calling logic. I will write some testcases that put the whole stack together with constructor pointcuts. I'm also working on the concept of an abstract Container. But you got me thinking that constructor pointcuts may be enough... Bill > Jeff > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill > Burke > Sent: Wednesday, March 26, 2003 7:09 PM > To: Jboss-Dev > Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration > > > I have implemented a new AOP service for Serializable POJOs, Versioned > Objects. You can transactionally version an object. If you modify the > object within a transaction, this modification is not seen by other > transactions. If the tx commits, the changes seen, if a rollback > happens the changes are rolled back. On commit, if another tx has > modified the object, the tx will rollback (OptimisticLocking). > > The way it works is as follows: > > POJO pojo = new POJO(); > pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); > > calling Versioned.makeVersioned creates a proxy that sits in front of > the real object. > > transactionManager.begin(); > > pojo.callMethod(); > > when callMethod is invoked since there is a transaction, an interceptor > creates a copy of the REAL pojo and does all further invocations on this > copy. > > pojo.someField = 5; > > If you have field interception turned on, public field will also be > accessed via the copy/version > > tm.commit(); > > On commit, a tx Synchronization checks to see if the version you have > created is the latest and greatest. If not an > org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in > beforeCompletion. I'm not sure how this exception is wrapped. > > Some other semantics: > > 1. All method invocations force a version to be created. You can avoid > this by declared class-metadata as follows: > > <class-metadata name="234234" group="VERSIONED" > class="org.jboss.test.aop.bean.VersionedPOJO"> > <method name="get.*"> > <read-only>true</read-only> > </method> > </class-metadata> > > A readonly method will not cause the creation of a version and the > current object will be used. > > > An example and unit test is under > testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java > > The example object VersionedPOJO.java, has 1 interceptor pointcut > declared on the class to do Tx stuff. See > testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. > > What would be nice is to also write a TransactionalLock interceptor for > versioned POJO's that have high OptimisticLock failures. > > Bill > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
