cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: [gump] cocoon2 build error
Date Thu, 06 Feb 2003 14:38:41 GMT
What's the status of this?

Leo Simons wrote:
> 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
>    IllegalArgumentException
> 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
> cheers,
> - 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