Proxy Based POJOs (No AOP) in POJO Cache

[jason.greene]

In a conversation we had offline, Vincent Marquez has advocated a proxy based approach in addition to the current AOP approach for POJO Cache. Best of all, he has offered to work on the implementation. The primary use case for this is scenarios where it is impractical or undesirable to instrument classes. With Java 5 loadtime weaving this is less of an issue, but there are still cases where you might not want it, such as:

1. 
   
2. Your app uses conflicting bytecode modification
   
3. You need to cluster a class you dont know about until AFTER its been loaded, and you dont want to instrument everything
   
4. Your app uses a serialization framework that is sensitive to the class structure
   
   The current proposal would replace conforming non-advised objects with a proxy that would intercept all method calls. One of the restrictions would be that the object must follow the JavaBean style, which allows us to determine the correct operation and attribute we are operating on. This gives us fine-grained replication, does not require the class to implement serializable, and gives us correct object identity semantics. Essentially this is the same behavior of interception used by hibernate.
   
   In summary it would provide close to the same advantages of AOP (over serialization), but with some trade-offs for not requiring instrumentation.
   
   They are:
   
   1. 
      
   2. Application code has to reget an object after attaching, so that it can use the proxy instead (this is already the case today with collections)
      
   3. Objects must be java bean style only (getBlah/setBlah), since we can only catch method invocations. However, this is the prevalent style for domain models.
      
   4. Not possible to intercept array access. Application code will have to *touch* the field reference to trigger a compare and update.
      
      
      I think this exchange is worth the added benefits, so provided certain implementation details can be worked out, I am all for this. One such issue is the precedence rules for determining the correct storage handler for an object. We would essentially have 3, Advised, Proxy, and Serialized.
      
      Thoughts?

[belaban]

I don't like this approach, as it defeats the uniformity of byte code instrumentation. I always disliked that - although we do instrument user classes - we cannot do the same for collections, so that's where we use AOP proxies.
I'd prefer a uniform approach. Having to writter getters and setters in one case and being able to use complete POJOs in another is cumbersome IMO.

[manik]

Wasn't JBoss AOP going to offer generated proxies as an alternative to manipulating bytecode at some point? Is this already there? Or am I completely off the mark? :-)

I think having options is always valuable. The JavaBean standard is not a huge deal - I think people should follow this anyway.

[belaban]

I think having options is always valuable. The JavaBean standard is not a huge deal - I think people should follow this anyway.

Why ? I never liked the JavaBeans approach, where even internal methods need to call accessors, like

public int increment() {
int retval=getAge();
setAge(retval +1);
return retval
}

instead of

public int increment() {
return age++;
}

[jason.greene]

I don't like this approach, as it defeats the uniformity of byte code instrumentation. I always disliked that - although we do instrument user classes - we cannot do the same for collections, so that's where we use AOP proxies.
I'd prefer a uniform approach. Having to writter getters and setters in one case and being able to use complete POJOs in another is cumbersome IMO.

Thanks for sharing your thoughts on this, to be honest, my initial reaction to this request was pretty much the same. I agree that the AOP approach is better. I also don't like introducing confusion, and I have a feeling that having to reget proxy objects after they are attached will do exactly that. However, if there is enough community demand for this, especially enough that someone is willing to submit the code to do it, provided the final patch looks good, and doesn't over complicate the code base, I'm ok with making some kind of option for it.

-Jason

[jason.greene]

Wasn't JBoss AOP going to offer generated proxies as an alternative to manipulating bytecode at some point? Is this already there? Or am I completely off the mark? :-)

Yes we already use them today for collections. Although it doesn't really matter what the proxy framework is.

I think having options is always valuable. The JavaBean standard is not a huge deal - I think people should follow this anyway.

Yeah this is common for domain models, so I think its workable. This does lead to some big pitfalls (anything remotely exotic breaks) if you don't expect it, so it would most definitely not be the default behavior, and it would have to be documented.

-Jason

[vincent.marquez]

For the precedence issue, we could identify if a class followed the 'JavaBean' standard when we initially construct a CachedType for it.

Since the CachedType objects are cached, there would only be a slight performance impact the first time an unrecognized class is attached.

So, the precedence rules would be: first check if object is advisable, then check if it is a collection, then check if it follows standard javabean symantics, and finally use the serializable handler.

[jason.greene]

"vincent.marquez" wrote:

So, the precedence rules would be: first check if object is advisable, then check if it is a collection, then check if it follows standard javabean symantics, and finally use the serializable handler.

Yeah this is reasonable. The problem is that someone might actually prefer the serializable mode with a class that is a javabean, or looks like one. This is a significant behavior change that likely should merit some kind of configuration value (something like proxyJavaBeans).

-Jason

[vincent.marquez]

Ok, the config value is something I can add. I didn't see a JIRA issue for this so if its alright with everyone i'll go ahead and add it, then post a patch to it for review.

[jason.greene]

Cool. I went ahead and created one for you here:

http://jira.jboss.com/jira/browse/PCACHE-54