cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: [gump] cocoon2 build error
Date Mon, 03 Feb 2003 16:57:42 GMT
Berin Loritsch wrote:
> Leo Simons wrote:
>> hi,
>> It looks like the problem is that an extra required first argument, 
>> namely role, was added to the ComponentHandler methods. This role in 
>> the end results in a call to ComponentProxyGenerator.getProxy(), where 
>> this role argument is passed in.
>> The role argument has to be a fully qualified classname, as it is 
>> simply used as m_classLoader.loadClass( role );.
> Right.

so isn't this a problem? ECM sometimes accept ROLE + "/selector", 
doesn't it? Shouldn't it be verified that the role passed in is a FQCN, 
and parse appropriately if it is not?

>> So, it seems to me that the additional role argument is totally 
>> redundant, and what should happen instead is that ComponentHandler 
>> should do a componentClass.class.getName() for passing in the role 
>> argument to the proxy generator.
> It would be even better to simply pass in the role's Class object.
> Keep in mind that it is the *ROLE* class and not the component
> implementation class.

gotcha. Duh!

> You need the component object for the proxy itself.
> You need the interface name to make the face for the proxy, adding
> to it the Component interface.  Otherwise we will run into problems
> with final classes that cannot be extended.

So would a feasible setup be...

1) add back in the methods with the old signatures
2) check whether the supplied component is an instanceof Component
     yes --> don't need a proxy, don't need a role either, pass null as
     the role
3) check whether the supplied component has a public ROLE member
     yes --> use that as the role
4) if(!Modifier.isFinal( clazz.getModifiers ))
     yes --> use clazz.getName() as the role, log a warning message
5) otherwise, well, we _could_ do getSuperClass() until we find a
    nonfinal base class, but we could also just throw an

I'm not so sure whether step (4) is a good idea. All existing client 
code relying on these methods should always pass in Component instances 
anyway, right?

Regardless, I think this is a showstopper issue for release of ECM, as 
it means current cocoon (and other apps bound to the old interface) 
won't work on current ECM. Regardless of the changes, cocoon should 
obviously upgrade components to use the new methods, so we probably want 
to deprecate the old methods. Err...maybe deprecate them after we release :D


- Leo

PS: hi cocoon-dev! Trying to sync up avalon and cocoon cvs heads. 
Comments welcome :D

To unsubscribe, e-mail:
For additional commands, email:

View raw message