cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Cocoon 2.1 showstopper?
Date Tue, 17 Jun 2003 07:48:44 GMT

Stefano Mazzocchi wrote, On 16/06/2003 21.12:

> on 6/16/03 1:20 AM Carsten Ziegeler wrote:
>>I think I found a showstopper for 2.1 :( :
>>2.1 is not binary compatible to 2.0.x -
>>Why is this so? Well, the reason is the change from Loggable
>>to LogEnabled. 
>>I think, mostly this affects own sitemap components inheriting from
>>the provided classes, but of course this can occur with every
>>class where we changed from Loggable to LogEnabled.
>>So, the question is: do we want to have this kind of compatibility
>>or do the users have to recompile (which works of course as we are
>>compatible on the source level)?
> Gosh, recompiling is not that big of a deal, but I'm with you that the
> concept sucks.
> I really don't know what to say about this :-/

Well, there is a way out, but I don't know if we want to do it. It's 
based on - ok, I'll say that word - an AOP interceptor mechanism(hehehe 
a big wording for a simple concept).

Basically, we would have to use our own classloader in the 
ComponentManager, and make it load the class only after having it 
proxyed with the LogEnabled interface.

Ok, down to simpler jargon. In JDK 1.3 there is java.lang.reflect.Proxy 
that can create a proxy.

A dynamic proxy class is a class that implements a list of interfaces 
specified at runtime when the class is created

A proxy interface is such an interface that is implemented by a proxy 

A proxy instance is an instance of a proxy class.

Each proxy instance has an associated invocation handler  object, which 
implements the interface InvocationHandler.

A method invocation on a proxy instance through one of its proxy 
interfaces will be dispatched to the invoke method of the instance's 
invocation handler, passing the proxy instance, a 
java.lang.reflect.Method object identifying the method that was invoked, 
and an array of type Object  containing the arguments. The invocation 
handler processes the encoded method invocation as appropriate and the 
result that it returns will be returned as the result of the method 
invocation on the proxy instance.

So we can get

LogEnabled f = (LogEnabled)
                      (LogEnabled .class.getClassLoader(),
                        new Class[] { LogEnabled .class },

Where handler has:

  Object invoke(Object proxy, Method method, Object[] args)

In this method we can recieve the LogEnabled call and make it go to the 
Loggable one.

I'm not saying that Proxies are the way to go, this is just an example, 
but the concept remains. A cool way of doing it would be with CGLib for 
example (

Maybe a nice opportunity for Fortress to add interceptors, and for us to 
use Fortress? Or maybe Fortress already has it? ;-)

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message