You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Leo Simons <le...@apache.org> on 2003/02/03 17:57:42 UTC
Re: [gump] cocoon2 build error
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [gump] cocoon2 build error
Posted by Leo Simons <le...@apache.org>.
fingers crossed.......
- Leo
Leo Simons wrote:
> Sam Ruby wrote:
>
>> What's the status of this?
>
>
> still "TODO".
leosimons 2003/02/08 06:49:16
Modified: component/src/java/org/apache/avalon/excalibur/component
ComponentHandler.java DefaultComponentFactory.java
Log:
Adding back in the methods removed in version 1.6 when proxying was implemented, which broke backwards compatibility. This restores compatibility for ComponentHandler and should allow cocoon to build against ECM cvs again. We should carefully check all changes made with the comment "update component to use proxies" as things might have broken in more areas, for example
- protected PoolableComponentHandler( final Class componentClass,
+ protected PoolableComponentHandler( final String role,
+ final Class componentClass,
final Configuration config,
final ComponentManager manager,
final Context context,
could lead to problems in packages that extend ECM or some of its classes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [gump] cocoon2 build error
Posted by Leo Simons <le...@apache.org>.
Sam Ruby wrote:
> What's the status of this?
still "TODO".
my current priority list:
1) fix up all places that need fixing because of avalon cvs rename
2) check out latest logkit RC, then vote on release
3) figure out then fix up jar&licensing&autoconf (in preparation for
avalon-framework release)
4) fix broken builds, including this one
5) ... (it goes on for ages :D)
So it'll likely be a few more days if I make the changes unless someone
sends a patch.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [gump] cocoon2 build error
Posted by Leo Simons <le...@apache.org>.
Sam Ruby wrote:
> What's the status of this?
still "TODO".
my current priority list:
1) fix up all places that need fixing because of avalon cvs rename
2) check out latest logkit RC, then vote on release
3) figure out then fix up jar&licensing&autoconf (in preparation for
avalon-framework release)
4) fix broken builds, including this one
5) ... (it goes on for ages :D)
So it'll likely be a few more days if I make the changes unless someone
sends a patch.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [gump] cocoon2 build error
Posted by Sam Ruby <ru...@apache.org>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [gump] cocoon2 build error
Posted by Sam Ruby <ru...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org