You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Royal <pr...@apache.org> on 2003/03/15 19:36:45 UTC
[phoenix] excalibur-logger jar in container lib directory
This breaks if you also include excalibur-logger in your application
jar (if say, you have your own child containers)...
java.lang.ClassCastException:
org.apache.avalon.excalibur.logger.factory.FileTargetFactory
at
org.apache.avalon.excalibur.logger.DefaultLogTargetFactoryManager.config
ure(DefaultLogTargetFactoryManager.java:177)
at
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerU
til.java:239)
at
org.apache.avalon.excalibur.logger.LogKitLoggerManager.setupTargetFactor
yManager(LogKitLoggerManager.java:262)
at
org.apache.avalon.excalibur.logger.LogKitLoggerManager.configure(LogKitL
oggerManager.java:227)
at
org.apache.avalon.framework.container.ContainerUtil.configure(ContainerU
til.java:239)
at
org.apache.avalon.phoenix.components.logger.DefaultLogManager.createHier
archy(DefaultLogManager.java:77)
at
org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy(Def
aultDeployer.java:282)
A "solution" would be to create the LoggerManager for applications in
DefaultLogManager using the application classloader. I think this won't
work fully as the application classloader and the container-private
classloader aren't connected at all and thus they won't share a common
view of the interface. If excalibur-logger was broked out into two
jars, one for interface one for impl, the interface jar could go into
the common classloader with the impl only in the container-private
classloader. I don't know if there will be enough benefit to make it
worth the effort.
Any objections to just moving excalibur-logger.jar back into the common
lib directory?
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [phoenix] excalibur-logger jar in container lib directory
Posted by Peter Royal <pr...@apache.org>.
On Saturday, March 15, 2003, at 09:15 PM, Peter Donald wrote:
> We previously enabled this so that users could define their own
> targets.
at my request :) I'm not doing that anymore though.
> Anyways I just temporarily disabled this - see if that fixes your
> problem.
Yes, it fixes it. The excalibur-logger-1.0.1 jar you have added does
not have support for the SMTP target factories though. I am also unable
to build a version of that jar with both SMTP *and* log4j support since
something is wacky in my environment:
check-environment:
BUILD FAILED
java.lang.VerifyError: (class: org/apache/log4j/LogManager, method:
<clinit> signature: ()V) Incompatible argument to function
at java.lang.Class.getConstructors0(Native Method)
at java.lang.Class.getDeclaredConstructors(Class.java:1072)
at
org.apache.tools.ant.AntClassLoader.initializeClass(AntClassLoader.java:
479)
at
org.apache.tools.ant.taskdefs.Available.checkClass(Available.java:493)
at
org.apache.tools.ant.taskdefs.Available.eval(Available.java:295)
at
org.apache.tools.ant.taskdefs.Available.execute(Available.java:247)
>> view of the interface. If excalibur-logger was broked out into two
>> jars, one for interface one for impl, the interface jar could go into
>> the common classloader with the impl only in the container-private
>> classloader.
>
> That would be the eventual plan.
And that would fix application log targets. cool.
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [phoenix] excalibur-logger jar in container lib directory
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 16 Mar 2003 05:36, Peter Royal wrote:
> A "solution" would be to create the LoggerManager for applications in
> DefaultLogManager using the application classloader.
Isn't that the problem? I thought that what is happening is that the factory s
using the application classloader. So when you load the LogTargetFactory it
is loaded from the application classloader and then tried to be cast to the
interface defined by the container classloader. We previously enabled this so
that users could define their own targets.
Anyways I just temporarily disabled this - see if that fixes your problem.
> I think this won't
> work fully as the application classloader and the container-private
> classloader aren't connected at all and thus they won't share a common
> view of the interface. If excalibur-logger was broked out into two
> jars, one for interface one for impl, the interface jar could go into
> the common classloader with the impl only in the container-private
> classloader. I don't know if there will be enough benefit to make it
> worth the effort.
That would be the eventual plan.
> Any objections to just moving excalibur-logger.jar back into the common
> lib directory?
Prefer not - does the above fix the problem.
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org