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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
