RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-04-12 Thread marc fleury
 1) POJO pojo = new POJO();
pojo = (POJO)Versioned.makeVersioned(pojo);

That is really pretty tho :)  You need to define the pojo as aspectable
(advisable).

 or
 
 2) Define a constructor-pointcut on the POJO class (I will 
 implement this
 today.)

nice, 

marcf

 Agreed.  A remote proxy must figure out at marshall time how 
 it can comunicate back to the server.

but, but but...

so we are in the AOP remote and we are about to return an object to the
remote caller.  Can the response do 

return AOPRemote.makeRemote(object); ?

So that even the proxy is constructed as needed (meaning when you return?)

marcf

 
 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
 
attachment: winmail.dat

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-04-12 Thread marc fleury
 If you use versioning on a POJO that is a the top of
 an object graph, will the children objects also be
 versions when they are modified???
 
 I assume No.  But I think it would make sense for your 

correct.

 Versioning interceptor to wrap up children objets with the 
 versioning proxy also when they are accessed. 
 That way if you do a:

not needed on reference work, just recursively instrument all get/set of the
objects in the graph. As a reference of the top node, if we declare the top
one to be advised, we can in fact dynamically instrument the references for
the same acidity, when they are assigned to the class and that recursively.


 
 pojo = (POJO)Versioned.makeVersioned(pojo);
 pojo.getAccount().getBalance().add(10.00);
 
 The modification of the Balance object will be
 versioned too.  Does that make sense to you??  Do you
 do this now??
 

we can as described in my previous mail. getBalance() is a method that does
a setBalance(getBalance+10.00); and we detect that one change and that one
change only.

marcf

 Regards,
 Hiram
 
 --- Bill Burke [EMAIL PROTECTED] wrote:
  
  
   -Original Message-
   From:
  [EMAIL PROTECTED]
  
 
 [mailto:[EMAIL PROTECTED]
  Behalf Of
   Karthik
   Sent: Thursday, March 27, 2003 1:25 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration
  
  
   Hi bill,
  The versioning of POJO is very good. I have
  some issues here. If I
   version a object, then I have to maintain all the
  state in the same POJO
  
  How is this not the general case?  All application
  code accesses the POJO
  through the proxy.  I am going to write a constructor-pointcut that 
  will always return a proxy instead of the real POJO on
  construction.
  
   which is not the general case and will bloat the
  code. The states are
   maintained in the helper classes. Also defining
  each POJO as versioned is
   meaningless. If new proxies are created for each
  transaction with the deep
   copy of all the state or maintain a pool and
  synchronize the state after
   update,  it will become real performance
  bottleneck.How do you tackle this
   problem?
  
  There is only one proxy, but you are correct.  For
  each transaction, a full
  snapshot is taken of the real object.  All access to
  the object is done
  through one proxy.
  
  The performance hit is the full deep copy not the synchronization.
  Synchronization is only:
  
  realObject = snapshot;
  
  Remember, we're optimistically locking here.
  (Although I'd like to
  optionally provide a transactional lock in the near
  future).
  
  The alternative solution is much much more complex.
  The biggest problem
  being, how do you determine when a POJO's state has
  changed?  For instance:
  
  Pojo.someHashMapField.get().setValue(blah).  You see
  my point?
  
  A full deep copy greatly simplifies the code.
  Simplicity == robustness.
  Plus I'm not even sure versioned fields would be
  better performing.  Field
  interception is quite expensive and versioned fields
  would need field
  interception.
  
  The code is under:
  varia/src/main/org/jboss/aop/plugins/Version*.java
  testcase is under
 
 testsuite/src/main/org/jboss/test/aop/bean/Version*.java
  (take a look at the AOP DD under 
  testsuite/src/resource/aop/META-INF/jboss-aop.xml
  too).
  
  Bill
  
  
  
  Correct me if I am missing something.
  
  Where or when can get the code from the CVS?
  
   Thanks
  
   Karthi
  
-Original Message-
From:
  [EMAIL PROTECTED]
   
 
 [mailto:[EMAIL PROTECTED]
Behalf Of Bill
Burke
Sent: Thursday, March 27, 2003 10:43 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration
   
   
   
   
 -Original Message-
 From:
  [EMAIL PROTECTED]

 
 [mailto:[EMAIL PROTECTED]
Behalf Of Jeff
 Haynie
 Sent: Wednesday, March 26, 2003 11:51 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration



 JBoss Remoting is much more fabulous.  We
  need to get the
word out on
 it...

 I need to write some darn docs.. Too busy
  trying to get a
new release
 out on our side. Not enough hours in a day.


  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.

 Could you dynamically do an insertBefore into
  the
CtConstructor of the
 advised class which would do the interception,
  even on reflection?

   
I'm not sure...The problem with Versioning and
  Remoting is
that a proxy
object is required.  You have to return a
  different object
than the one
actually constructed.  You getting me?  I'm

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-04-12 Thread marc fleury
Digging throught that thread and the bela discussion of cache.

 There is only one proxy, but you are correct.  For each
 transaction, a full snapshot is taken of the real object.  
 All access to the object is done through one proxy.

The point being made was that there is another way to do this that I find a
little more intuitive (and it seems to solve the Person.getAddress()
instrumentation problem of bela, done). 

Essentially instrument the get/set methods (eventually field in V2 if we can
do it right) and then you are instrumenting the actual instance.   The
reference you are holding to an object, even if dynamically instrumented
(such as an object inserted in cache) is held, get/set do not require that
you get a new reference. 

Sacha pointed out to me in Paris that using a proxy may be a simpler way for
you to deal with the Remoteness aspect, which does always require this
proxy, I doesn't' help on the server though. 

 The performance hit is the full deep copy not the
 synchronization. Synchronization is only:
 
 realObject = snapshot;
 
 Remember, we're optimistically locking here.  (Although I'd
 like to optionally provide a transactional lock in the near future).

Ok.  Serialization is needed because you are just doing deep copy of the
object (simple I agree).  But in fact we do have the knowledge of state
changes for most basic types/all application types as we make a requirement.
That means that tracking the individual field changes as in CMP2.0 is a
given.  All individual sets should trigger versioning of the individual
fields.  As we realized in the cache discussion with Bela and you this
essentially does away with the serializable requirement.

 The alternative solution is much much more complex.  The
 biggest problem being, how do you determine when a POJO's 
 state has changed?  For instance:
 
 Pojo.someHashMapField.get().setValue(blah).  You see my point?

For most types it is trivial but for Maps.  Adrian has a very simple
solution to this, pitched it in Paris.  In fact he didn't even men.  Simply
overwrite the class in the class pool so that when a CL asks for HashMap()
you really return a JBossHashMap which has the CRUD operations overloaded
(something like that I wasn't really fully there that night, mostly drunk). 

Simple. 

For most POJOS it is trivial.

Meaning that 

pojo.setSomeField(value); 

is an instrumented method with either

/*
* jboss-tag:acid=true
* 
* when david gets around to writing XDoclet in AOP :)
*
*/
public class stuffWeWantACID

which generates the XML description of it
aspects
class name=ACID.Pojo
interceptor name=doTheAcidVersioning pointcut=get*,set* 
/class

We can then trivially acidify the state of that object as originally
imagined and prototyped by Julien at NIST.  Pure bytecode instrumentation of
the actual reference. 

As far as references in the POJO, we also talked about the fact that we
solve the problem by simply recursing through the ACID reference so that a
tree of state, when reaching leaves is trivially serializable and thus
achieving fined grained acidity of the tree state. 

 better performing.  Field interception is quite expensive and
 versioned fields would need field interception.

get/set requirement would trivially solve the problem in first iteration,
field in second.  As we know it is the same class of problem we see in ACID,
Cache and persistence. Simply that we need to instrument get/set on the
code.


marcf

attachment: winmail.dat

Why the forums suck (Was: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration)

2003-04-04 Thread Stefan Arentz
On Thursday, Mar 27, 2003, at 18:25 Europe/Amsterdam, Bill Burke wrote:

We've been trying hard to keep the development forums as the base of 
design
discussions.  There's a lot of good information there.
The information there is good, but it is a pain to access the forums. 
Here are some of the reasons:

The jboss site is bloated with content. If i'm there to read forums I 
don't want to see flashing banners all the time. It slows down page 
loading a lot and takes up a lot of space on the screen.

The development forums are marked with 'no user questions here please' 
but nobody seems to care much. Questions about *any* subject are posted 
in random forums.

Searching in the forums is a pain. It would be so much nicer to be able 
to search by subject, and not see every single article in a thread but 
just the unqiue thread names.

It is *slow* to read. Nothing beats a good news or email reader. I 
read/browse through a backlog of 100 messages on this list in 15 
minutes. On the forums it will take hours to even find the last 
messages.

What would really help is a forum2email gateway to relay new messages 
to an email address.

I know that begging for features is not allowed here :) so if it an 
option to add that as a module to the new nukes stuff then I can help 
out with that.

 S.



---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: Why the forums suck (Was: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration)

2003-04-04 Thread marc fleury
\
 What would really help is a forum2email gateway to relay new messages 
 to an email address.
 
 I know that begging for features is not allowed here :) so if it an 
 option to add that as a module to the new nukes stuff then I can help 
 out with that.


OK :)

marcf
 
   S.
 
 
 
 ---
 This SF.net email is sponsored by: ValueWeb: 
 Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
 No other company gives more support or power for your 
 dedicated server 
 http://click.atdmt.com/AFF/go/sdnxxaff00300020 aff/direct/01/
 
 
 ___
 Jboss-development mailing list [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-31 Thread Bill Burke
Again, you have the problem of primitive types.  These would require field
interception which is slow.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Bela
 Ban
 Sent: Monday, March 31, 2003 7:11 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration


 Hiram Chirino wrote:

  That might be a problem if you have a big object
  graph. You get a big penalty even if you only modify
  a small peice of the object graph.
 
  You could do a shallow copy by getting a snapshot of
  the fields of the object. Then wrap up the children
  objects with Versioned.makeVersioned(child) when
  they are accessed. The cool thing is that you would
  not have any serialization at all. I know that there
  has to be some down-sides to this approach, help me
  figure them out.


 This essentially requires recursively wrapping all child objects
 reachable from a parent with version interceptors.
 I think this is what I would require for my cache, which is
 tree-structured.

 Versions would be created only when needed, as we go.

 --
 Bela Ban
 www.javagroups.com
 (408) 316-4459




 ---
 This SF.net email is sponsored by: ValueWeb:
 Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
 No other company gives more support or power for your dedicated server
 http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development



---
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-28 Thread Stefan Groschupf
 Dave Smith:
 May God Bless America and Java.
That is a very humanistic thing that you wish here, but you make a small
typo.
As a friend of Java you know that Java is in Indonesia and Indonesia is the
country with the most Muslims all over the word.
So you should better write God Bless America and Ala take care of Java.
Or better, based on OO more abstract : A higher power should take care on
each human.

May the bit's bust the internet to bring more education to this world.
Stefan





---
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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Sacha Labourey
IMPRESSIVE BILL! Congratulations! Not only does this is impressive, but it
is ridiculously EASY to use.

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Bill Burke
 Sent: jeudi, 27. mars 2003 01:09
 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-onlytrue/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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Karthik
 Sent: Thursday, March 27, 2003 1:25 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration


 Hi bill,
The versioning of POJO is very good. I have some issues here. If I
 version a object, then I have to maintain all the state in the same POJO

How is this not the general case?  All application code accesses the POJO
through the proxy.  I am going to write a constructor-pointcut that will
always return a proxy instead of the real POJO on construction.

 which is not the general case and will bloat the code. The states are
 maintained in the helper classes. Also defining each POJO as versioned is
 meaningless. If new proxies are created for each transaction with the deep
 copy of all the state or maintain a pool and synchronize the state after
 update,  it will become real performance bottleneck.How do you tackle this
 problem?

There is only one proxy, but you are correct.  For each transaction, a full
snapshot is taken of the real object.  All access to the object is done
through one proxy.

The performance hit is the full deep copy not the synchronization.
Synchronization is only:

realObject = snapshot;

Remember, we're optimistically locking here.  (Although I'd like to
optionally provide a transactional lock in the near future).

The alternative solution is much much more complex.  The biggest problem
being, how do you determine when a POJO's state has changed?  For instance:

Pojo.someHashMapField.get().setValue(blah).  You see my point?

A full deep copy greatly simplifies the code.  Simplicity == robustness.
Plus I'm not even sure versioned fields would be better performing.  Field
interception is quite expensive and versioned fields would need field
interception.

The code is under:  varia/src/main/org/jboss/aop/plugins/Version*.java
testcase is under testsuite/src/main/org/jboss/test/aop/bean/Version*.java
(take a look at the AOP DD under
testsuite/src/resource/aop/META-INF/jboss-aop.xml too).

Bill



Correct me if I am missing something.

Where or when can get the code from the CVS?

 Thanks

 Karthi

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]
  Behalf Of Bill
  Burke
  Sent: Thursday, March 27, 2003 10:43 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
 
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]
  Behalf Of Jeff
   Haynie
   Sent: Wednesday, March 26, 2003 11:51 PM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
  
  
  
   JBoss Remoting is much more fabulous.  We need to get the
  word out on
   it...
  
   I need to write some darn docs.. Too busy trying to get a
  new release
   out on our side. Not enough hours in a day.
  
  
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.
  
   Could you dynamically do an insertBefore into the
  CtConstructor of the
   advised class which would do the interception, even on reflection?
  
 
  I'm not sure...The problem with Versioning and Remoting is
  that a proxy
  object is required.  You have to return a different object
  than the one
  actually constructed.  You getting me?  I'm not sure if this
  can be done
  within bytecode manipulation.  I'll have to ask the Javassist guys.
 
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...
  
   I was just going to email you about the Container - just
  looking through
   the code. Is this just the ability to create an AOP namespace or
   something?
  
 
  I guess you could think of it in that way and use it in that
  way, but the
  original intent was to handle things like dynamic loading through the
  persistence mechanism much in the same way an Entity Bean
  Container handles
  invocations on objects that are not in memory yet.  You get
  what I'm saying?
 
  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

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Karthik
 Sent: Thursday, March 27, 2003 1:35 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration


 Versioning --
 Versioning can be done by Byte code manipulation. Instead of
 maintaining
 the state as a proxy, you can maintain the state in a list in the
 manipulated class.

That's just silly.  If the state is maintained globally within the class,
you would have to protect this state within a synchronized block and you
would have high high global contention and low performance.  Besides, the
proxy I generate should replace the real object and all access to the object
is done through the proxy instance.

Either:

1) POJO pojo = new POJO();
   pojo = (POJO)Versioned.makeVersioned(pojo);

or

2) Define a constructor-pointcut on the POJO class (I will implement this
today.)


 Remoting --
  has to be done through proxy, but abstract the user by the Inteceptor
 sending the proxy based on the communication layer.


Agreed.  A remote proxy must figure out at marshall time how it can
comunicate back to the server.

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


Re[2]: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread julien viet
when I thought about this, I was trying avoir the current construct :

B oldB = a.getB();
C oldC = a.getC();
try
{
   a.setB(b);
   a.setC(c);
}
catch(Throwable t)
{
   a.setB(oldB);
   a.setC(oldc);
}

and I was trying to find a way to make atomic Deployment within
deployers. Deploy all or nothing.

Bill, with AOP fwk would that be possible to know how many bytes
an object takes effectively ?

((ObjectStat) pojo).getBytesInMem();

Instrument the pojo to iterates over its fields and computes
its memory footprint.

julien

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Karthik
 Sent: Thursday, March 27, 2003 1:25 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration


 Hi bill,
The versioning of POJO is very good. I have some issues here. If I
 version a object, then I have to maintain all the state in the same POJO

BB How is this not the general case?  All application code accesses the POJO
BB through the proxy.  I am going to write a constructor-pointcut that will
BB always return a proxy instead of the real POJO on construction.

 which is not the general case and will bloat the code. The states are
 maintained in the helper classes. Also defining each POJO as versioned is
 meaningless. If new proxies are created for each transaction with the deep
 copy of all the state or maintain a pool and synchronize the state after
 update,  it will become real performance bottleneck.How do you tackle this
 problem?

BB There is only one proxy, but you are correct.  For each transaction, a full
BB snapshot is taken of the real object.  All access to the object is done
BB through one proxy.

BB The performance hit is the full deep copy not the synchronization.
BB Synchronization is only:

BB realObject = snapshot;

BB Remember, we're optimistically locking here.  (Although I'd like to
BB optionally provide a transactional lock in the near future).

BB The alternative solution is much much more complex.  The biggest problem
BB being, how do you determine when a POJO's state has changed?  For instance:

BB Pojo.someHashMapField.get().setValue(blah).  You see my point?

BB A full deep copy greatly simplifies the code.  Simplicity == robustness.
BB Plus I'm not even sure versioned fields would be better performing.  Field
BB interception is quite expensive and versioned fields would need field
BB interception.

BB The code is under:  varia/src/main/org/jboss/aop/plugins/Version*.java
BB testcase is under testsuite/src/main/org/jboss/test/aop/bean/Version*.java
BB (take a look at the AOP DD under
BB testsuite/src/resource/aop/META-INF/jboss-aop.xml too).

BB Bill



Correct me if I am missing something.

Where or when can get the code from the CVS?

 Thanks

 Karthi

  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]
  Behalf Of Bill
  Burke
  Sent: Thursday, March 27, 2003 10:43 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
 
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]
  Behalf Of Jeff
   Haynie
   Sent: Wednesday, March 26, 2003 11:51 PM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
  
  
  
   JBoss Remoting is much more fabulous.  We need to get the
  word out on
   it...
  
   I need to write some darn docs.. Too busy trying to get a
  new release
   out on our side. Not enough hours in a day.
  
  
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.
  
   Could you dynamically do an insertBefore into the
  CtConstructor of the
   advised class which would do the interception, even on reflection?
  
 
  I'm not sure...The problem with Versioning and Remoting is
  that a proxy
  object is required.  You have to return a different object
  than the one
  actually constructed.  You getting me?  I'm not sure if this
  can be done
  within bytecode manipulation.  I'll have to ask the Javassist guys.
 
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...
  
   I was just going to email you about the Container - just
  looking through
   the code. Is this just the ability to create an AOP namespace or
   something?
  
 
  I guess you could think of it in that way and use it in that
  way, but the
  original intent was to handle things like dynamic loading through the
  persistence mechanism much in the same way an Entity Bean
  Container handles
  invocations on objects that are not in memory yet.  You get
  what I'm saying

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Hiram Chirino

Bill,

If you use versioning on a POJO that is a the top of
an object graph, will the children objects also be
versions when they are modified???

I assume No.  But I think it would make sense for your
Versioning interceptor to wrap up children objets with
the versioning proxy also when they are accessed. 
That way if you do a:

pojo = (POJO)Versioned.makeVersioned(pojo);
pojo.getAccount().getBalance().add(10.00);

The modification of the Balance object will be
versioned too.  Does that make sense to you??  Do you
do this now??

Regards,
Hiram

--- Bill Burke [EMAIL PROTECTED] wrote:
 
 
  -Original Message-
  From:
 [EMAIL PROTECTED]
 

[mailto:[EMAIL PROTECTED]
 Behalf Of
  Karthik
  Sent: Thursday, March 27, 2003 1:25 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
 
 
  Hi bill,
 The versioning of POJO is very good. I have
 some issues here. If I
  version a object, then I have to maintain all the
 state in the same POJO
 
 How is this not the general case?  All application
 code accesses the POJO
 through the proxy.  I am going to write a
 constructor-pointcut that will
 always return a proxy instead of the real POJO on
 construction.
 
  which is not the general case and will bloat the
 code. The states are
  maintained in the helper classes. Also defining
 each POJO as versioned is
  meaningless. If new proxies are created for each
 transaction with the deep
  copy of all the state or maintain a pool and
 synchronize the state after
  update,  it will become real performance
 bottleneck.How do you tackle this
  problem?
 
 There is only one proxy, but you are correct.  For
 each transaction, a full
 snapshot is taken of the real object.  All access to
 the object is done
 through one proxy.
 
 The performance hit is the full deep copy not the
 synchronization.
 Synchronization is only:
 
 realObject = snapshot;
 
 Remember, we're optimistically locking here. 
 (Although I'd like to
 optionally provide a transactional lock in the near
 future).
 
 The alternative solution is much much more complex. 
 The biggest problem
 being, how do you determine when a POJO's state has
 changed?  For instance:
 
 Pojo.someHashMapField.get().setValue(blah).  You see
 my point?
 
 A full deep copy greatly simplifies the code. 
 Simplicity == robustness.
 Plus I'm not even sure versioned fields would be
 better performing.  Field
 interception is quite expensive and versioned fields
 would need field
 interception.
 
 The code is under: 
 varia/src/main/org/jboss/aop/plugins/Version*.java
 testcase is under

testsuite/src/main/org/jboss/test/aop/bean/Version*.java
 (take a look at the AOP DD under
 testsuite/src/resource/aop/META-INF/jboss-aop.xml
 too).
 
 Bill
 
 
 
 Correct me if I am missing something.
 
 Where or when can get the code from the CVS?
 
  Thanks
 
  Karthi
 
   -Original Message-
   From:
 [EMAIL PROTECTED]
  

[mailto:[EMAIL PROTECTED]
   Behalf Of Bill
   Burke
   Sent: Thursday, March 27, 2003 10:43 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
  
  
  
  
-Original Message-
From:
 [EMAIL PROTECTED]
   

[mailto:[EMAIL PROTECTED]
   Behalf Of Jeff
Haynie
Sent: Wednesday, March 26, 2003 11:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
   
   
   
JBoss Remoting is much more fabulous.  We
 need to get the
   word out on
it...
   
I need to write some darn docs.. Too busy
 trying to get a
   new release
out on our side. Not enough hours in a day.
   
   
 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.
   
Could you dynamically do an insertBefore into
 the
   CtConstructor of the
advised class which would do the interception,
 even on reflection?
   
  
   I'm not sure...The problem with Versioning and
 Remoting is
   that a proxy
   object is required.  You have to return a
 different object
   than the one
   actually constructed.  You getting me?  I'm not
 sure if this
   can be done
   within bytecode manipulation.  I'll have to ask
 the Javassist guys.
  
 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...
   
I was just going to email you about the
 Container - just
   looking through
the code. Is this just the ability to create
 an AOP namespace or
something?
   
  
   I guess you could think of it in that way and
 use it in that
   way, but the
   original intent was to handle things like

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Jeff Haynie

I'm not sure...The problem with Versioning and Remoting is that a proxy
object is required.  You have to return a different object than the one
actually constructed.  
You getting me?  I'm not sure if this can be done within bytecode
manipulation.  I'll have to ask the Javassist guys.

Why?  Basically in rmeoting, you would just dispatch each method
invocation across the wire and the local object would just serve as a
phantom object and not actually contain any state, etc.  Why does it has
to be a real proxy...? Maybe I'm not following.


That way, I could new an object, which is actually a local
representation of a remoted object on another machine.  I could also add
a clustered intercetor which might then load balance invocations across
to different real remote objects.  I think this is possible.  Right?  

Another thing to think about ... After looking at the javassist docs
last night is something like using casting to dynamically add
interceptors.  This might be bad, haven't thought through all the
implications ... But, imagine:

Foo foo = new Foo (); // local object

((Transactable)foo).beginTx();
Foo.bar();
((Transactable)foo).commitTx();

What if the mere casting of an object would allow you to dynamically
attach an interceptor to the object before the invocation?  This might
be fairly powerful too. Looking at the javassist docs, it looks like you
can get called on a Cast and InstanceOf call to an object. Maybe I'm
being too whacky here ... Not sure.  Something to ponder.

Jeff




---
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


RE: Re[2]: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread marc fleury
hey hey, let's take it online new site is up with NUKES and it rocks, 

you can see who is on and stuff

marcf

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of julien viet
 Sent: Thursday, March 27, 2003 10:11 AM
 To: Bill Burke
 Subject: Re[2]: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
 when I thought about this, I was trying avoir the current construct :
 
 B oldB = a.getB();
 C oldC = a.getC();
 try
 {
a.setB(b);
a.setC(c);
 }
 catch(Throwable t)
 {
a.setB(oldB);
a.setC(oldc);
 }
 
 and I was trying to find a way to make atomic Deployment 
 within deployers. Deploy all or nothing.
 
 Bill, with AOP fwk would that be possible to know how many 
 bytes an object takes effectively ?
 
 ((ObjectStat) pojo).getBytesInMem();
 
 Instrument the pojo to iterates over its fields and computes 
 its memory footprint.
 
 julien
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] Behalf Of 
  Karthik
  Sent: Thursday, March 27, 2003 1:25 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
  Hi bill,
 The versioning of POJO is very good. I have some issues 
 here. If I 
  version a object, then I have to maintain all the state in 
 the same 
  POJO
 
 BB How is this not the general case?  All application code 
 accesses the 
 BB POJO through the proxy.  I am going to write a 
 constructor-pointcut 
 BB that will always return a proxy instead of the real POJO on 
 BB construction.
 
  which is not the general case and will bloat the code. The 
 states are 
  maintained in the helper classes. Also defining each POJO as 
  versioned is meaningless. If new proxies are created for each 
  transaction with the deep copy of all the state or maintain a pool 
  and synchronize the state after update,  it will become real 
  performance bottleneck.How do you tackle this problem?
 
 BB There is only one proxy, but you are correct.  For each 
 transaction, 
 BB a full snapshot is taken of the real object.  All access to the 
 BB object is done through one proxy.
 
 BB The performance hit is the full deep copy not the 
 synchronization. 
 BB Synchronization is only:
 
 BB realObject = snapshot;
 
 BB Remember, we're optimistically locking here.  (Although 
 I'd like to 
 BB optionally provide a transactional lock in the near future).
 
 BB The alternative solution is much much more complex.  The biggest 
 BB problem being, how do you determine when a POJO's state 
 has changed?  
 BB For instance:
 
 BB Pojo.someHashMapField.get().setValue(blah).  You see my point?
 
 BB A full deep copy greatly simplifies the code.  Simplicity == 
 BB robustness. Plus I'm not even sure versioned fields would 
 be better 
 BB performing.  Field interception is quite expensive and versioned 
 BB fields would need field interception.
 
 BB The code is under:  
 BB varia/src/main/org/jboss/aop/plugins/Version*.java
 BB testcase is under 
 testsuite/src/main/org/jboss/test/aop/bean/Version*.java
 BB (take a look at the AOP DD under
 BB testsuite/src/resource/aop/META-INF/jboss-aop.xml too).
 
 BB Bill
 
 
 
 Correct me if I am missing something.
 
 Where or when can get the code from the CVS?
 
  Thanks
 
  Karthi
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]
   Behalf Of Bill
   Burke
   Sent: Thursday, March 27, 2003 10:43 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
  
  
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
   Behalf Of Jeff
Haynie
Sent: Wednesday, March 26, 2003 11:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects 
 1st iteration
   
   
   
JBoss Remoting is much more fabulous.  We need to get the
   word out on
it...
   
I need to write some darn docs.. Too busy trying to get a
   new release
out on our side. Not enough hours in a day.
   
   
 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.
   
Could you dynamically do an insertBefore into the
   CtConstructor of the
advised class which would do the interception, even on 
reflection?
   
  
   I'm not sure...The problem with Versioning and Remoting 
 is that a 
   proxy object is required.  You have to return a different object
   than the one
   actually constructed.  You getting me?  I'm not sure if this
   can be done
   within bytecode manipulation.  I'll have to ask the 
 Javassist guys.
  
 I will write some testcases that put the whole stack 
 together 
 with
constructor pointcuts.

 I'm also working on the concept

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Bill Burke
Yes, its a deep copy which is why I require Serializable.

new MarshalledObject(obj).get();  

Maybe there is a better way to make copies?

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Hiram
 Chirino
 Sent: Thursday, March 27, 2003 10:15 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
 
 Bill,
 
 If you use versioning on a POJO that is a the top of
 an object graph, will the children objects also be
 versions when they are modified???
 
 I assume No.  But I think it would make sense for your
 Versioning interceptor to wrap up children objets with
 the versioning proxy also when they are accessed. 
 That way if you do a:
 
 pojo = (POJO)Versioned.makeVersioned(pojo);
 pojo.getAccount().getBalance().add(10.00);
 
 The modification of the Balance object will be
 versioned too.  Does that make sense to you??  Do you
 do this now??
 
 Regards,
 Hiram
 
 --- Bill Burke [EMAIL PROTECTED] wrote:
  
  
   -Original Message-
   From:
  [EMAIL PROTECTED]
  
 
 [mailto:[EMAIL PROTECTED]
  Behalf Of
   Karthik
   Sent: Thursday, March 27, 2003 1:25 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration
  
  
   Hi bill,
  The versioning of POJO is very good. I have
  some issues here. If I
   version a object, then I have to maintain all the
  state in the same POJO
  
  How is this not the general case?  All application
  code accesses the POJO
  through the proxy.  I am going to write a
  constructor-pointcut that will
  always return a proxy instead of the real POJO on
  construction.
  
   which is not the general case and will bloat the
  code. The states are
   maintained in the helper classes. Also defining
  each POJO as versioned is
   meaningless. If new proxies are created for each
  transaction with the deep
   copy of all the state or maintain a pool and
  synchronize the state after
   update,  it will become real performance
  bottleneck.How do you tackle this
   problem?
  
  There is only one proxy, but you are correct.  For
  each transaction, a full
  snapshot is taken of the real object.  All access to
  the object is done
  through one proxy.
  
  The performance hit is the full deep copy not the
  synchronization.
  Synchronization is only:
  
  realObject = snapshot;
  
  Remember, we're optimistically locking here. 
  (Although I'd like to
  optionally provide a transactional lock in the near
  future).
  
  The alternative solution is much much more complex. 
  The biggest problem
  being, how do you determine when a POJO's state has
  changed?  For instance:
  
  Pojo.someHashMapField.get().setValue(blah).  You see
  my point?
  
  A full deep copy greatly simplifies the code. 
  Simplicity == robustness.
  Plus I'm not even sure versioned fields would be
  better performing.  Field
  interception is quite expensive and versioned fields
  would need field
  interception.
  
  The code is under: 
  varia/src/main/org/jboss/aop/plugins/Version*.java
  testcase is under
 
 testsuite/src/main/org/jboss/test/aop/bean/Version*.java
  (take a look at the AOP DD under
  testsuite/src/resource/aop/META-INF/jboss-aop.xml
  too).
  
  Bill
  
  
  
  Correct me if I am missing something.
  
  Where or when can get the code from the CVS?
  
   Thanks
  
   Karthi
  
-Original Message-
From:
  [EMAIL PROTECTED]
   
 
 [mailto:[EMAIL PROTECTED]
Behalf Of Bill
Burke
Sent: Thursday, March 27, 2003 10:43 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration
   
   
   
   
 -Original Message-
 From:
  [EMAIL PROTECTED]

 
 [mailto:[EMAIL PROTECTED]
Behalf Of Jeff
 Haynie
 Sent: Wednesday, March 26, 2003 11:51 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID
  objects 1st iteration



 JBoss Remoting is much more fabulous.  We
  need to get the
word out on
 it...

 I need to write some darn docs.. Too busy
  trying to get a
new release
 out on our side. Not enough hours in a day.


  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.

 Could you dynamically do an insertBefore into
  the
CtConstructor of the
 advised class which would do the interception,
  even on reflection?

   
I'm not sure...The problem with Versioning and
  Remoting is
that a proxy
object is required.  You have to return a
  different object
than the one
actually constructed.  You getting me?  I'm not
  sure if this
can be done
within bytecode manipulation.  I'll have to ask

Re: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Stefan Arentz
On Thursday, Mar 27, 2003, at 03:28 Europe/Amsterdam, marc fleury wrote:

So in the quest to impove J2EE have you killed it?
bla bla bla bla

marc fleury wrote:

do you motherfuckers realize how BIG this is?
obviously some of you don't get it, give it time, it will become very
obvious
It would be nice if discussions about JBoss 4.0 architecture would move 
from your internal mailing list to the public -dev mailing list. Maybe 
then we can get it and also give useful input. JBoss 4.0 is like a 
black box now. Show us what you are doing. Kudos for Bill of course for 
sharing, but more info would be nice.

Peace.

 Stefan



---
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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Karthik

 How is this not the general case?  All application code
 accesses the POJO
 through the proxy.  I am going to write a
 constructor-pointcut that will
 always return a proxy instead of the real POJO on construction.
 Here I mean to say if only deep copy is not made.


 The performance hit is the full deep copy not the synchronization.
 Synchronization is only:

 realObject = snapshot;
My thought of pooling is absolute bull shit .
One Tx ( worst case one invocation)  -- One deep copy even for
transactional locking (which may be sequential access) is also bottleneck.
But currently, its has to be done like that only.
Even though field versioning is too complex or unclear, we should have
look over that.

Karthik



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
 Behalf Of Bill
 Burke
 Sent: Thursday, March 27, 2003 8:20 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration




  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] Behalf Of
  Karthik
  Sent: Thursday, March 27, 2003 1:25 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
  Hi bill,
 The versioning of POJO is very good. I have some issues
 here. If I
  version a object, then I have to maintain all the state in
 the same POJO

 How is this not the general case?  All application code
 accesses the POJO
 through the proxy.  I am going to write a
 constructor-pointcut that will
 always return a proxy instead of the real POJO on construction.

  which is not the general case and will bloat the code. The
 states are
  maintained in the helper classes. Also defining each POJO
 as versioned is
  meaningless. If new proxies are created for each
 transaction with the deep
  copy of all the state or maintain a pool and synchronize
 the state after
  update,  it will become real performance bottleneck.How do
 you tackle this
  problem?

 There is only one proxy, but you are correct.  For each
 transaction, a full
 snapshot is taken of the real object.  All access to the
 object is done
 through one proxy.

 The performance hit is the full deep copy not the synchronization.
 Synchronization is only:

 realObject = snapshot;

 Remember, we're optimistically locking here.  (Although I'd like to
 optionally provide a transactional lock in the near future).

 The alternative solution is much much more complex.  The
 biggest problem
 being, how do you determine when a POJO's state has changed?
 For instance:

 Pojo.someHashMapField.get().setValue(blah).  You see my point?

 A full deep copy greatly simplifies the code.  Simplicity ==
 robustness.
 Plus I'm not even sure versioned fields would be better
 performing.  Field
 interception is quite expensive and versioned fields would need field
 interception.

 The code is under:  varia/src/main/org/jboss/aop/plugins/Version*.java
 testcase is under
 testsuite/src/main/org/jboss/test/aop/bean/Version*.java
 (take a look at the AOP DD under
 testsuite/src/resource/aop/META-INF/jboss-aop.xml too).

 Bill



 Correct me if I am missing something.
 
 Where or when can get the code from the CVS?
 
  Thanks
 
  Karthi
 
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED]
   Behalf Of Bill
   Burke
   Sent: Thursday, March 27, 2003 10:43 AM
   To: [EMAIL PROTECTED]
   Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
  
  
  
  
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
   Behalf Of Jeff
Haynie
Sent: Wednesday, March 26, 2003 11:51 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st
 iteration
   
   
   
JBoss Remoting is much more fabulous.  We need to get the
   word out on
it...
   
I need to write some darn docs.. Too busy trying to get a
   new release
out on our side. Not enough hours in a day.
   
   
 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.
   
Could you dynamically do an insertBefore into the
   CtConstructor of the
advised class which would do the interception, even on
 reflection?
   
  
   I'm not sure...The problem with Versioning and Remoting is
   that a proxy
   object is required.  You have to return a different object
   than the one
   actually constructed.  You getting me?  I'm not sure if this
   can be done
   within bytecode manipulation.  I'll have to ask the
 Javassist guys.
  
 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

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Bill Burke
We've been trying hard to keep the development forums as the base of design
discussions.  There's a lot of good information there.

Bill

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Stefan Arentz
 Sent: Thursday, March 27, 2003 11:28 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration



 On Thursday, Mar 27, 2003, at 03:28 Europe/Amsterdam, marc fleury wrote:

  So in the quest to impove J2EE have you killed it?
 
  bla bla bla bla
 
  marc fleury wrote:
 
  do you motherfuckers realize how BIG this is?
 
  obviously some of you don't get it, give it time, it will become very
  obvious

 It would be nice if discussions about JBoss 4.0 architecture would move
 from your internal mailing list to the public -dev mailing list. Maybe
 then we can get it and also give useful input. JBoss 4.0 is like a
 black box now. Show us what you are doing. Kudos for Bill of course for
 sharing, but more info would be nice.

 Peace.

   Stefan



 ---
 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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Karthik

After looking at the javassist docs
 last night is something like using casting to dynamically add
 interceptors.  This might be bad, haven't thought through all the
 implications ... But, imagine:

Where is it. I cant find any documents regarding casting and I feel that is
impossible because the class is loaded.
  This prevents our basic discussion of preventing user from knowing the
point cuts.
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
 Behalf Of Jeff
 Haynie
 Sent: Thursday, March 27, 2003 8:41 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration



 I'm not sure...The problem with Versioning and Remoting is
 that a proxy
 object is required.  You have to return a different object
 than the one
 actually constructed.
 You getting me?  I'm not sure if this can be done within bytecode
 manipulation.  I'll have to ask the Javassist guys.

 Why?  Basically in rmeoting, you would just dispatch each method
 invocation across the wire and the local object would just serve as a
 phantom object and not actually contain any state, etc.  Why
 does it has
 to be a real proxy...? Maybe I'm not following.


 That way, I could new an object, which is actually a local
 representation of a remoted object on another machine.  I
 could also add
 a clustered intercetor which might then load balance
 invocations across
 to different real remote objects.  I think this is possible.  Right?

 Another thing to think about ... After looking at the javassist docs
 last night is something like using casting to dynamically add
 interceptors.  This might be bad, haven't thought through all the
 implications ... But, imagine:

 Foo foo = new Foo (); // local object

 ((Transactable)foo).beginTx();
 Foo.bar();
 ((Transactable)foo).commitTx();

 What if the mere casting of an object would allow you to dynamically
 attach an interceptor to the object before the invocation?  This might
 be fairly powerful too. Looking at the javassist docs, it
 looks like you
 can get called on a Cast and InstanceOf call to an object. Maybe I'm
 being too whacky here ... Not sure.  Something to ponder.

 Jeff




 ---
 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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Hiram Chirino

That might be a problem if you have a big object
graph.  You get a big penalty even if you only modify
a small peice of the object graph.

You could do a shallow copy by getting a snapshot of
the fields of the object.  Then wrap up the children
objects with Versioned.makeVersioned(child) when
they are accessed.  The cool thing is that you would
not have any serialization at all.  I know that there
has to be some down-sides to this approach, help me
figure them out.

Regards,
Hiram


--- Bill Burke [EMAIL PROTECTED] wrote:
 Yes, its a deep copy which is why I require
 Serializable.
 
 new MarshalledObject(obj).get();  
 
 Maybe there is a better way to make copies?
 
  -Original Message-
  From:
 [EMAIL PROTECTED]
 

[mailto:[EMAIL PROTECTED]
 Behalf Of Hiram
  Chirino
  Sent: Thursday, March 27, 2003 10:15 AM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID
 objects 1st iteration
  
  
  
  Bill,
  
  If you use versioning on a POJO that is a the top
 of
  an object graph, will the children objects also be
  versions when they are modified???
  
  I assume No.  But I think it would make sense for
 your
  Versioning interceptor to wrap up children objets
 with
  the versioning proxy also when they are accessed. 
  That way if you do a:
  
  pojo = (POJO)Versioned.makeVersioned(pojo);
  pojo.getAccount().getBalance().add(10.00);
  
  The modification of the Balance object will be
  versioned too.  Does that make sense to you??  Do
 you
  do this now??
  
  Regards,
  Hiram
  
  --- Bill Burke [EMAIL PROTECTED] wrote:
   
   
-Original Message-
From:
   [EMAIL PROTECTED]
   
  
 

[mailto:[EMAIL PROTECTED]
   Behalf Of
Karthik
Sent: Thursday, March 27, 2003 1:25 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] AOP versioned ACID
   objects 1st iteration
   
   
Hi bill,
   The versioning of POJO is very good. I have
   some issues here. If I
version a object, then I have to maintain all
 the
   state in the same POJO
   
   How is this not the general case?  All
 application
   code accesses the POJO
   through the proxy.  I am going to write a
   constructor-pointcut that will
   always return a proxy instead of the real POJO
 on
   construction.
   
which is not the general case and will bloat
 the
   code. The states are
maintained in the helper classes. Also
 defining
   each POJO as versioned is
meaningless. If new proxies are created for
 each
   transaction with the deep
copy of all the state or maintain a pool and
   synchronize the state after
update,  it will become real performance
   bottleneck.How do you tackle this
problem?
   
   There is only one proxy, but you are correct. 
 For
   each transaction, a full
   snapshot is taken of the real object.  All
 access to
   the object is done
   through one proxy.
   
   The performance hit is the full deep copy not
 the
   synchronization.
   Synchronization is only:
   
   realObject = snapshot;
   
   Remember, we're optimistically locking here. 
   (Although I'd like to
   optionally provide a transactional lock in the
 near
   future).
   
   The alternative solution is much much more
 complex. 
   The biggest problem
   being, how do you determine when a POJO's state
 has
   changed?  For instance:
   
   Pojo.someHashMapField.get().setValue(blah).  You
 see
   my point?
   
   A full deep copy greatly simplifies the code. 
   Simplicity == robustness.
   Plus I'm not even sure versioned fields would be
   better performing.  Field
   interception is quite expensive and versioned
 fields
   would need field
   interception.
   
   The code is under: 
  
 varia/src/main/org/jboss/aop/plugins/Version*.java
   testcase is under
  
 

testsuite/src/main/org/jboss/test/aop/bean/Version*.java
   (take a look at the AOP DD under
  
 testsuite/src/resource/aop/META-INF/jboss-aop.xml
   too).
   
   Bill
   
   
   
   Correct me if I am missing something.
   
   Where or when can get the code from the
 CVS?
   
Thanks
   
Karthi
   
 -Original Message-
 From:
   [EMAIL PROTECTED]

  
 

[mailto:[EMAIL PROTECTED]
 Behalf Of Bill
 Burke
 Sent: Thursday, March 27, 2003 10:43 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID
   objects 1st iteration




  -Original Message-
  From:
   [EMAIL PROTECTED]
 
  
 

[mailto:[EMAIL PROTECTED]
 Behalf Of Jeff
  Haynie
  Sent: Wednesday, March 26, 2003 11:51 PM
  To:
 [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned
 ACID
   objects 1st iteration
 
 
 
  JBoss Remoting is much more fabulous.  We
   need to get the
 word out on
  it...
 
 
=== message truncated ===


__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Dain Sundstrom
On Thursday, March 27, 2003, at 09:57 AM, Bill Burke wrote:

Yes, its a deep copy which is why I require Serializable.

new MarshalledObject(obj).get();

Maybe there is a better way to make copies?
Yes.  I wrote an object copier service for just this type for 
situation.  In CMP the spec requires us to return copies of CMP-fields 
and up until now we just ignored that requirement.  The object copier 
is currently broken, but I expect to have it fixed sometime this 
weekend.  I'll send you some sample code later.

-dain



---
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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Hiram
 Chirino
 Sent: Thursday, March 27, 2003 2:31 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration



 That might be a problem if you have a big object
 graph.  You get a big penalty even if you only modify
 a small peice of the object graph.

 You could do a shallow copy by getting a snapshot of
 the fields of the object.  Then wrap up the children
 objects with Versioned.makeVersioned(child) when
 they are accessed.  The cool thing is that you would
 not have any serialization at all.  I know that there
 has to be some down-sides to this approach, help me
 figure them out.


Interesting idea, but I don't know if it would be more performant.  The
problem is primitive types.  You can't make these versionable by themselves
and field interception is expensive.  Another thing, I'm not sure this
approach would work with non-static inner classes.

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


[JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Bill Burke
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-onlytrue/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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread marc fleury
I just want to give credit to Julien Viet as well who pitched that idea
when he was in ATL, 

kudos Bill, you are in orbit, the pings in your head, the code in CVS,
let them fight, let's move 

marcf

 -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-onlytrue/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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread marc fleury
second revolution, 

I just can't say how excited I am.

We are doing magic, critical mass.

Julien goes I got a silly idea..

bill makes it real, there is war..

we are doing RAW stuff, and rarely

was I that excited about it all...

you ain't seen nothing yet wankers

PLgC

marcf






 -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-onlytrue/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


Re: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Dave Smith
Too bad that the whole world is more intretsed whether or not JBOSS will 
become J2EE certified.  

I was reading an article about Unintended Consequences that made me 
think of the current J2EE cerification vs. JBOSS 4.0 with AOP.

In 1349 the black  plague was spreading around Europe. In castles and 
universities and town halls across Europe, great minds pondered the 
cause of the plague.
And they came pretty close. The collective academic wisdom was that the 
source of the Black Plague was fleas.

So the word went out from town to town across Europe - to stop the 
plague - kill the fleas - by killing all the dogs. And immediately the 
slaughter of all dogs began.

But like lots of well-intentioned academic ideas it was somewhat wide of 
the mark...and had unexpected consequences. The cause was  
fleas all right, but not dog fleas...it was rat fleas. And in the 1300's 
what was the most effective way to hold down the rat population? You 
guessed it - dogs.
So by suggesting that townsfolk kill their dogs, the wise authorities 
had unwittingly allowed the rat population to flourish and thus a new 
vicious rash of Black Plague began.
Before it was over, three  years later, nearly 1 out of 3 people in the 
world had died of the plague. (John Mauldin)

So in the quest to impove J2EE have you killed it?

marc fleury wrote:

do you motherfuckers realize how BIG this is?

no?

there is close to NOTHING in 20,000 pages of J2EE about this. 

marcf

 

-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-onlytrue/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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread marc fleury
 So in the quest to impove J2EE have you killed it?

bla bla bla bla

 marc fleury wrote:
 
 do you motherfuckers realize how BIG this is?

obviously some of you don't get it, give it time, it will become very
obvious

enough wasted time in the U.N. Time for some good ol' action 

marcf



---
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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread marc fleury
The story about the flees was pretty good though, but kind of irrelevant
:)

marcf

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of marc fleury
 Sent: Wednesday, March 26, 2003 9:29 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
  So in the quest to impove J2EE have you killed it?
 
 bla bla bla bla
 
  marc fleury wrote:
  
  do you motherfuckers realize how BIG this is?
 
 obviously some of you don't get it, give it time, it will 
 become very obvious
 
 enough wasted time in the U.N. Time for some good ol' action 
 
 marcf
 
 
 
 ---
 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


Re: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Dave Smith
:rotfl  .. a Frenchman wanting action

This is hot shit. Plain and simple. Take the J2EE spec and piss all over 
it. When you wrote it your mind was small and feeble, we have seen the 
light.
The question is how long before the world realizes it or does J2EE 
implode and we all are paying homage to Bill and .NET

May God Bless America and Java.

marc fleury wrote:

So in the quest to impove J2EE have you killed it?
   

bla bla bla bla

 

marc fleury wrote:

   

do you motherfuckers realize how BIG this is?
 

obviously some of you don't get it, give it time, it will become very
obvious
enough wasted time in the U.N. Time for some good ol' action 

marcf



---
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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Ben Sabrin
Dave,

Think about this.  If we wait for the spec to implement the kind of stuff
dot net is doing, J2EE is dead anyhow.  At 10K per CPU J2EE is dead as well.
We are moving to a commodity based infrastructure, dot net can play so can 
open source and IBM.  Not sure too many others can join the ride.  

Realize that we are saving Java not destroying it.  More people download
JBoss than the reference implementation.


Ben Sabrin
Director of Sales and Business Development
JBoss Group, LLC
404-467-8555 x202 - office
404-664-9466 - cell
404-948-1496 - fax
[EMAIL PROTECTED]

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:jboss-
 [EMAIL PROTECTED] On Behalf Of Dave Smith
 Sent: Wednesday, March 26, 2003 10:20 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 :rotfl  .. a Frenchman wanting action
 
 This is hot shit. Plain and simple. Take the J2EE spec and piss all over
 it. When you wrote it your mind was small and feeble, we have seen the
 light.
 The question is how long before the world realizes it or does J2EE
 implode and we all are paying homage to Bill and .NET
 
 May God Bless America and Java.
 
 
 marc fleury wrote:
 
 So in the quest to impove J2EE have you killed it?
 
 
 
 bla bla bla bla
 
 
 
 marc fleury wrote:
 
 
 
 do you motherfuckers realize how BIG this is?
 
 
 
 obviously some of you don't get it, give it time, it will become very
 obvious
 
 enough wasted time in the U.N. Time for some good ol' action
 
 marcf
 
 
 
 ---
 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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Dave
 Smith
 Sent: Wednesday, March 26, 2003 9:17 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration


 Too bad that the whole world is more intretsed whether or not JBOSS will
 become J2EE certified.

 I was reading an article about Unintended Consequences that made me
 think of the current J2EE cerification vs. JBOSS 4.0 with AOP.

 In 1349 the black  plague was spreading around Europe. In castles and
 universities and town halls across Europe, great minds pondered the
 cause of the plague.
 And they came pretty close. The collective academic wisdom was that the
 source of the Black Plague was fleas.

 So the word went out from town to town across Europe - to stop the
 plague - kill the fleas - by killing all the dogs. And immediately the
 slaughter of all dogs began.

 But like lots of well-intentioned academic ideas it was somewhat wide of
 the mark...and had unexpected consequences. The cause was
 fleas all right, but not dog fleas...it was rat fleas. And in the 1300's
  what was the most effective way to hold down the rat population? You
 guessed it - dogs.
 So by suggesting that townsfolk kill their dogs, the wise authorities
 had unwittingly allowed the rat population to flourish and thus a new
 vicious rash of Black Plague began.
 Before it was over, three  years later, nearly 1 out of 3 people in the
 world had died of the plague. (John Mauldin)

 So in the quest to impove J2EE have you killed it?


Pope Paul V ordered Bellarmine to have the Sacred Congregation of the Index
decide on the Copernican theory. The cardinals of the Inquisition met on 24
February 1616 and took evidence from theological experts. They condemned the
teachings of Copernicus, and Bellarmine conveyed their decision to Galileo
who had not been personally involved in the trial. Galileo was forbidden to
hold Copernican views.

Dave, I've participated in the evolution of distributed systems of the past
10 years, DCE, CORBA, and now J2EE implementations.  System level aspects
are just the next iteration of the same theme.  The difference being that
the AOP paradigm finally let's you separate your business logic code from
your distributed infrastructure.  You will see.  Everybody will jump on the
AOP bandwagon eventually.  I'm just glad JBoss is a leader this time rather
than being just a J2EE chump follower.

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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Jeff Haynie
Bill,

This is fabulous stuff. Good job.

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? 

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-onlytrue/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


Re: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Andrew C. Oliver
Pope Paul V ordered Bellarmine to have the Sacred Congregation of the Index
decide on the Copernican theory. The cardinals of the Inquisition met on 24
February 1616 and took evidence from theological experts. They condemned the
teachings of Copernicus, and Bellarmine conveyed their decision to Galileo
who had not been personally involved in the trial. Galileo was forbidden to
hold Copernican views.
Dude, that is so funny!  I was about to write that exact thing (though 
less elegantly) and then make some references to the Spanish 
Inquisition, but then I thought...what's the point...

-Andy


Dave, I've participated in the evolution of distributed systems of the past
10 years, DCE, CORBA, and now J2EE implementations.  System level aspects
are just the next iteration of the same theme.  The difference being that
the AOP paradigm finally let's you separate your business logic code from
your distributed infrastructure.  You will see.  Everybody will jump on the
AOP bandwagon eventually.  I'm just glad JBoss is a leader this time rather
than being just a J2EE chump follower.
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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Andrew C. Oliver
 Sent: Wednesday, March 26, 2003 11:14 PM
 To: [EMAIL PROTECTED]
 Subject: Re: [JBoss-dev] AOP versioned ACID objects 1st iteration


  Pope Paul V ordered Bellarmine to have the Sacred Congregation
 of the Index
  decide on the Copernican theory. The cardinals of the
 Inquisition met on 24
  February 1616 and took evidence from theological experts. They
 condemned the
  teachings of Copernicus, and Bellarmine conveyed their decision
 to Galileo
  who had not been personally involved in the trial. Galileo was
 forbidden to
  hold Copernican views.
 

 Dude, that is so funny!  I was about to write that exact thing (though
 less elegantly) and then make some references to the Spanish
 Inquisition, but then I thought...what's the point...


Only reason it was written elegantly is that I plagarized it from the web
:-0  (BTW, I liked your blog you posted out the other day...)

I'd like to add that through each iteration (DCE, CORBA, J2EE, Web Services)
I think the industry has learned something.  There's a lot JBoss AOP can
take from these specifications.

Bill



 -Andy


  Dave, I've participated in the evolution of distributed systems
 of the past
  10 years, DCE, CORBA, and now J2EE implementations.  System
 level aspects
  are just the next iteration of the same theme.  The difference
 being that
  the AOP paradigm finally let's you separate your business logic
 code from
  your distributed infrastructure.  You will see.  Everybody will
 jump on the
  AOP bandwagon eventually.  I'm just glad JBoss is a leader this
 time rather
  than being just a J2EE chump follower.
 
  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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Bill Burke


 -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-onlytrue/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

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Jeff Haynie

JBoss Remoting is much more fabulous.  We need to get the word out on
it...

I need to write some darn docs.. Too busy trying to get a new release
out on our side. Not enough hours in a day.


 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.

Could you dynamically do an insertBefore into the CtConstructor of the
advised class which would do the interception, even on reflection?

 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...

I was just going to email you about the Container - just looking through
the code. Is this just the ability to create an AOP namespace or
something?







---
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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Bill
 Burke
 Sent: Wednesday, March 26, 2003 11:37 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration




  -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.


One more thing...I don't think the constructor pointcut approach makes sense
most of the time for Remoting and Clustering.  The point being that you
don't want to hardcode your remotable object to a specific protocol.

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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Bill Burke


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of Jeff
 Haynie
 Sent: Wednesday, March 26, 2003 11:51 PM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration



 JBoss Remoting is much more fabulous.  We need to get the word out on
 it...

 I need to write some darn docs.. Too busy trying to get a new release
 out on our side. Not enough hours in a day.


  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.

 Could you dynamically do an insertBefore into the CtConstructor of the
 advised class which would do the interception, even on reflection?


I'm not sure...The problem with Versioning and Remoting is that a proxy
object is required.  You have to return a different object than the one
actually constructed.  You getting me?  I'm not sure if this can be done
within bytecode manipulation.  I'll have to ask the Javassist guys.

  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...

 I was just going to email you about the Container - just looking through
 the code. Is this just the ability to create an AOP namespace or
 something?


I guess you could think of it in that way and use it in that way, but the
original intent was to handle things like dynamic loading through the
persistence mechanism much in the same way an Entity Bean Container handles
invocations on objects that are not in memory yet.  You get what I'm saying?

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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Karthik
Hi bill,
   The versioning of POJO is very good. I have some issues here. If I
version a object, then I have to maintain all the state in the same POJO
which is not the general case and will bloat the code. The states are
maintained in the helper classes. Also defining each POJO as versioned is
meaningless. If new proxies are created for each transaction with the deep
copy of all the state or maintain a pool and synchronize the state after
update,  it will become real performance bottleneck.How do you tackle this
problem?
   Correct me if I am missing something.

   Where or when can get the code from the CVS?

Thanks

Karthi

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
 Behalf Of Bill
 Burke
 Sent: Thursday, March 27, 2003 10:43 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration




  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]
 Behalf Of Jeff
  Haynie
  Sent: Wednesday, March 26, 2003 11:51 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
 
  JBoss Remoting is much more fabulous.  We need to get the
 word out on
  it...
 
  I need to write some darn docs.. Too busy trying to get a
 new release
  out on our side. Not enough hours in a day.
 
 
   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.
 
  Could you dynamically do an insertBefore into the
 CtConstructor of the
  advised class which would do the interception, even on reflection?
 

 I'm not sure...The problem with Versioning and Remoting is
 that a proxy
 object is required.  You have to return a different object
 than the one
 actually constructed.  You getting me?  I'm not sure if this
 can be done
 within bytecode manipulation.  I'll have to ask the Javassist guys.

   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...
 
  I was just going to email you about the Container - just
 looking through
  the code. Is this just the ability to create an AOP namespace or
  something?
 

 I guess you could think of it in that way and use it in that
 way, but the
 original intent was to handle things like dynamic loading through the
 persistence mechanism much in the same way an Entity Bean
 Container handles
 invocations on objects that are not in memory yet.  You get
 what I'm saying?

 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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Karthik
Versioning --
Versioning can be done by Byte code manipulation. Instead of maintaining
the state as a proxy, you can maintain the state in a list in the
manipulated class.
Remoting --
 has to be done through proxy, but abstract the user by the Inteceptor
sending the proxy based on the communication layer.

Karthik


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
 Behalf Of Bill
 Burke
 Sent: Thursday, March 27, 2003 10:43 AM
 To: [EMAIL PROTECTED]
 Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration




  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED]
 Behalf Of Jeff
  Haynie
  Sent: Wednesday, March 26, 2003 11:51 PM
  To: [EMAIL PROTECTED]
  Subject: RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
 
 
 
  JBoss Remoting is much more fabulous.  We need to get the
 word out on
  it...
 
  I need to write some darn docs.. Too busy trying to get a
 new release
  out on our side. Not enough hours in a day.
 
 
   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.
 
  Could you dynamically do an insertBefore into the
 CtConstructor of the
  advised class which would do the interception, even on reflection?
 

 I'm not sure...The problem with Versioning and Remoting is
 that a proxy
 object is required.  You have to return a different object
 than the one
 actually constructed.  You getting me?  I'm not sure if this
 can be done
 within bytecode manipulation.  I'll have to ask the Javassist guys.

   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...
 
  I was just going to email you about the Container - just
 looking through
  the code. Is this just the ability to create an AOP namespace or
  something?
 

 I guess you could think of it in that way and use it in that
 way, but the
 original intent was to handle things like dynamic loading through the
 persistence mechanism much in the same way an Entity Bean
 Container handles
 invocations on objects that are not in memory yet.  You get
 what I'm saying?

 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