You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/02/03 07:55:47 UTC
[gump] cocoon2 build error
from http://cvs.apache.org/builds/gump/latest/xml-cocoon2.html:
----------------------
compile-core:
[copy] Copying 31 files to
/home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
[roles-tool] Reading:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/classes/org/apache/cocoon/cocoon.roles
[roles-tool] Skipping:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/store/store.xroles
[roles-tool] Processing:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/modules/modules.xroles
[roles-tool] Processing:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/flow/flow.xroles
[roles-tool] Processing:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/deli/deli.xroles
[roles-tool] Skipping:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/sax/serializer.xroles
[roles-tool] Writing:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/classes/org/apache/cocoon/cocoon.roles
[echo] Compiling with Java 1.4, debug on, optimize off,
deprecation off
[mkdir] Created dir:
/home/rubys/jakarta/xml-cocoon2/build/cocoon/mock-classes
[javac] Compiling 17 source files to
/home/rubys/jakarta/xml-cocoon2/build/cocoon/mock-classes
[javac] Compiling 582 source files to
/home/rubys/jakarta/xml-cocoon2/build/cocoon/classes
[javac]
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/language/programming/java/JavaProgram.java:89:
cannot resolve symbol
[javac] symbol : method getComponentHandler
(java.lang.Class,org.apache.avalon.framework.configuration.DefaultConfiguration,org.apache.avalon.framework.component.ComponentManager,org.apache.avalon.framework.context.Context,org.apache.avalon.excalibur.component.RoleManager,org.apache.avalon.excalibur.component.LogkitLoggerManager)
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] return ComponentHandler.getComponentHandler(
[javac] ^
[javac]
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/components/language/programming/javascript/JavascriptProgram.java:109:
cannot resolve symbol
[javac] symbol : method getComponentHandler
(java.lang.Class,org.apache.avalon.framework.configuration.DefaultConfiguration,org.apache.avalon.framework.component.ComponentManager,org.apache.avalon.framework.context.Context,org.apache.avalon.excalibur.component.RoleManager,org.apache.avalon.excalibur.component.LogkitLoggerManager)
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] return ComponentHandler.getComponentHandler(
[javac] ^
[javac]
/home/rubys/jakarta/xml-cocoon2/build/cocoon/src/org/apache/cocoon/acting/ServerPagesAction.java:122:
cannot resolve symbol
[javac] symbol : method getComponentHandler
(java.lang.Class,org.apache.avalon.framework.configuration.Configuration,org.apache.avalon.framework.component.ComponentManager,<nulltype>,<nulltype>,<nulltype>)
[javac] location: class
org.apache.avalon.excalibur.component.ComponentHandler
[javac] this.generatorHandler =
ComponentHandler.getComponentHandler(
[javac] ^
[javac] 3 errors
BUILD FAILED
file:///home/rubys/jakarta/xml-cocoon2/build.xml:1052: Compile failed;
see the compiler error output for details.
----------------------
this has been failing for some time now.
is this due to a backwards-incompatible change in ECM or is cocoon cvs
head at fault?
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 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
Re: [gump] cocoon2 build error
Posted by Leo Simons <le...@apache.org>.
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>.
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
Re: [gump] cocoon2 build error
Posted by Berin Loritsch <bl...@apache.org>.
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, 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.
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.
---------------------------------------------------------------------
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 Leo Simons <le...@apache.org>.
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 );.
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.
Berin, can you confirm?
If this is not possible for some reason, it should still be trivial to
re-add the methods with no role argument in them and use class.getName()
on the componentClass to get the role.
cheers,
- Leo
PS: shame on us for letting an issue like this exist for 4 months! ;)
Nicola Ken Barozzi wrote:
>
>
> Leo Simons wrote:
>
>> from http://cvs.apache.org/builds/gump/latest/xml-cocoon2.html:
>> ----------------------
>
>
>> this has been failing for some time now.
>>
>> is this due to a backwards-incompatible change in ECM or is cocoon cvs
>> head at fault?
>
>
> Backward compat changes done by Berin IIRC. Basically a method was
> removed without deprecation in ComponentHandler.
>
> Being quite ignorant on why it was changed I had asked on avalon-dev
> about it some time ago. It seems it was about the introduction of proxies:
>
> "
> Revision 1.7 / (view) - annotate - [select for diffs] , Tue Sep 24
> 20:39:53 2002 UTC (4 months, 1 week ago) by bloritsch
> Branch: MAIN
> Changes since 1.6: +11 -7 lines
> Diff to previous 1.6 (colored)
>
> update component to use proxies
> "
>
> http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/component/src/java/org/apache/avalon/excalibur/component/ComponentHandler.java.diff?r1=1.6&r2=1.7&diff_format=h
>
>
>
> Sorry I didn't follow up on it :-/ Can you please?
> Thanx
---------------------------------------------------------------------
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 Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> from http://cvs.apache.org/builds/gump/latest/xml-cocoon2.html:
> ----------------------
> this has been failing for some time now.
>
> is this due to a backwards-incompatible change in ECM or is cocoon cvs
> head at fault?
Backward compat changes done by Berin IIRC. Basically a method was
removed without deprecation in ComponentHandler.
Being quite ignorant on why it was changed I had asked on avalon-dev
about it some time ago. It seems it was about the introduction of proxies:
"
Revision 1.7 / (view) - annotate - [select for diffs] , Tue Sep 24
20:39:53 2002 UTC (4 months, 1 week ago) by bloritsch
Branch: MAIN
Changes since 1.6: +11 -7 lines
Diff to previous 1.6 (colored)
update component to use proxies
"
http://cvs.apache.org/viewcvs/jakarta-avalon-excalibur/component/src/java/org/apache/avalon/excalibur/component/ComponentHandler.java.diff?r1=1.6&r2=1.7&diff_format=h
Sorry I didn't follow up on it :-/ Can you please?
Thanx
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org