You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Bert Van Kets <be...@vankets.com> on 2004/02/09 11:20:42 UTC
ClassNotFoundException and not unique container name : cocoon-portal
Hi all,
I just did an update of my CVS Head and built the whole thing (clean
built!).
Checking the logs I saw that I got an ClassNotFoundException
org.exolab.jms.jndi.InitialContextFactory.
So, I go to Sourceforge, get the needed classes, build and add the lib to
Cooon.
Now, when I start up Cocoon again, I get a stack trace (see below)
complaining about a duplicate container name called "cocoon-portal". A text
search on this string doesn't give me anything. So I'm stuck (again). :-(
Isn't there supposed to be a dummy class for the openJMS classes???
Is the container name hard coded? If so, it's never goign to be unique is
it? :-/
I can live without JMS, but it seems there's something wrong here.
Bert
P.S. Using JDK 1.3.1_6 and Tomcat 4.1.29 on WinXP
java.lang.IllegalArgumentException: The given container name is not unique:
cocoon-portal
at
org.apache.pluto.PortletContainerServices.createReference(PortletContainerSe
rvices.java:53)
at
org.apache.pluto.PortletContainerImpl.init(PortletContainerImpl.java:101)
at
org.apache.cocoon.portal.impl.PortletPortalManager.initContainer(PortletPort
alManager.java:211)
at
org.apache.cocoon.portal.impl.PortletPortalManager.initialize(PortletPortalM
anager.java:173)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil
.java:282)
at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(De
faultComponentFactory.java:313)
at
org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(
ThreadSafeComponentHandler.java:143)
at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(E
xcaliburComponentManager.java:558)
at
org.apache.cocoon.components.CocoonComponentManager.initialize(CocoonCompone
ntManager.java:547)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil
.java:282)
at org.apache.cocoon.Cocoon.initialize(Cocoon.java:340)
at
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil
.java:282)
at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1371
)
at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:514)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:93
5)
at
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:210)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:191)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:171)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:641)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
eNext(StandardPipeline.java:643)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:193)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:781)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:549)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:589)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:666)
at java.lang.Thread.run(Thread.java:479)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Bert Van Kets <be...@vankets.com>.
> Ok, that's bizarre. Can anyone else confirm this? There are very few
> logical places where any interaction between the jms and portal block
> should be happening. You're saying that the portal block works as long
> as you remove the openJMS library?
I did another test to pin down the problem a little bit more.
I exluded the portal and portal-fw blocks from the blocks.properties file
and tested again. This time I had another NoClassFoundException requesting a
openJMS util package. I found this in the exolabcore.jar file and included
that in the lib directory. After this Cocoon ran fine again.
Soooooo, I added the portal and portal-fw blocks again and recompiled
(phew). Using both the openjms-0.7.6.jar and exolabcore-0.3.7.jar files got
rid of all problems.
Cocoon runs fine now with everything enabled. So it seems one error was
covering up for another one. :-/
Anyways, problem solved.
Bert
>
> Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Bert Van Kets <be...@vankets.com>.
> Ok, that's bizarre. Can anyone else confirm this? There are very few
> logical places where any interaction between the jms and portal block
> should be happening. You're saying that the portal block works as long
> as you remove the openJMS library?
yep, that is correct.
I just did a clean CVS HEAD checkout at 4PM GMT and did a clean build. No
local properties files were used. I did a build clean before building!
I copied the build/webapp directory to my Tomcat webapps directory and added
the openJMS library in the WEB-INF/lib directory.
Starting Tomcat doesn't give any errors what so ever.
Going to the cocoon home page gives me the IllegalArgumentException in the
browser, mentioning "The given container name is not unique: cocoon-portal".
No other errors are reported in the log files.
Removing the openJMS library starts Tomcat and Cocoon with only the mention
of the openJMS ClassNotFoundException.
Very easy to reproduce on my system.
Using JDK 1.3.1_6, Tomcat 4.1.29 on WinXP. Using openJMS 0.7.6 from
http://openjms.sourceforge.net
Bert
>
> Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Geoff Howard <co...@leverageweb.com>.
Ok, that's bizarre. Can anyone else confirm this? There are very few
logical places where any interaction between the jms and portal block
should be happening. You're saying that the portal block works as long
as you remove the openJMS library?
Geoff
Bert Van Kets wrote:
> Oops, my bad. JD was not refering to the problem I reported. :-/
>
> The cocoon-portal duplicate container name only appears when you add the
> openJMS library to Cocoon, so that is why I reported it in one mail.
>
> Bert
>
> ----- Original Message -----
> From: "Geoff Howard" <co...@leverageweb.com>
> To: <us...@cocoon.apache.org>
> Sent: Monday, February 09, 2004 4:21 PM
> Subject: Re: ClassNotFoundException and not unique container name :
> cocoon-portal
>
>>Bert Van Kets wrote:
>>
>>>>>Checking the logs I saw that I got an ClassNotFoundException
>>>>>org.exolab.jms.jndi.InitialContextFactory.
>>>>>So, I go to Sourceforge, get the needed classes, build and add the
>>>>>lib to Cooon.
>>>
>>>>Yes, this comes from the jms block which by default is configured to use
>>>>OpenJMS but we do not bundle it with Cocoon. If you don't plan on using
>>>>jms either exclude the jms block, or ignore the warning. If you do need
>>>>jms, either get OpenJMS, start it, and put its client jar in WEB-INF\lib
>>>>(and/or in %COCOON_HOME%\optional so it's added there after any future
>>>>rebuilds)
>>>
>>>As mentioned in my mail, I had already put the open JMS lib in the
>>>WEB-INF/lib folder, which in turn brought to light the bug mentioned by
> JD.
>
>>>As the bug is already filed, there's nothing else to do at this time but
> try
>>>to find the time to tackle it and file a patch.
>>Sorry, I understood your message to be linking the two issues - perhaps
>>I didn't read carefully enough.
>>Which bug are you referring to? I don't see a related message from "JD".
>>
>>Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Bert Van Kets <be...@vankets.com>.
Oops, my bad. JD was not refering to the problem I reported. :-/
The cocoon-portal duplicate container name only appears when you add the
openJMS library to Cocoon, so that is why I reported it in one mail.
Bert
----- Original Message -----
From: "Geoff Howard" <co...@leverageweb.com>
To: <us...@cocoon.apache.org>
Sent: Monday, February 09, 2004 4:21 PM
Subject: Re: ClassNotFoundException and not unique container name :
cocoon-portal
> Bert Van Kets wrote:
>
> >>>Checking the logs I saw that I got an ClassNotFoundException
> >>>org.exolab.jms.jndi.InitialContextFactory.
> >>>So, I go to Sourceforge, get the needed classes, build and add the
> >>>lib to Cooon.
> >
> >>Yes, this comes from the jms block which by default is configured to use
> >>OpenJMS but we do not bundle it with Cocoon. If you don't plan on using
> >>jms either exclude the jms block, or ignore the warning. If you do need
> >>jms, either get OpenJMS, start it, and put its client jar in WEB-INF\lib
> >>(and/or in %COCOON_HOME%\optional so it's added there after any future
> >>rebuilds)
> >
> > As mentioned in my mail, I had already put the open JMS lib in the
> > WEB-INF/lib folder, which in turn brought to light the bug mentioned by
JD.
> > As the bug is already filed, there's nothing else to do at this time but
try
> > to find the time to tackle it and file a patch.
>
> Sorry, I understood your message to be linking the two issues - perhaps
> I didn't read carefully enough.
>
> Which bug are you referring to? I don't see a related message from "JD".
>
> Geoff
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Geoff Howard <co...@leverageweb.com>.
Bert Van Kets wrote:
>>>Checking the logs I saw that I got an ClassNotFoundException
>>>org.exolab.jms.jndi.InitialContextFactory.
>>>So, I go to Sourceforge, get the needed classes, build and add the
>>>lib to Cooon.
>
>>Yes, this comes from the jms block which by default is configured to use
>>OpenJMS but we do not bundle it with Cocoon. If you don't plan on using
>>jms either exclude the jms block, or ignore the warning. If you do need
>>jms, either get OpenJMS, start it, and put its client jar in WEB-INF\lib
>>(and/or in %COCOON_HOME%\optional so it's added there after any future
>>rebuilds)
>
> As mentioned in my mail, I had already put the open JMS lib in the
> WEB-INF/lib folder, which in turn brought to light the bug mentioned by JD.
> As the bug is already filed, there's nothing else to do at this time but try
> to find the time to tackle it and file a patch.
Sorry, I understood your message to be linking the two issues - perhaps
I didn't read carefully enough.
Which bug are you referring to? I don't see a related message from "JD".
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Bert Van Kets <be...@vankets.com>.
> > Checking the logs I saw that I got an ClassNotFoundException
> > org.exolab.jms.jndi.InitialContextFactory.
> > So, I go to Sourceforge, get the needed classes, build and add the lib
to
> > Cooon.
> Yes, this comes from the jms block which by default is configured to use
> OpenJMS but we do not bundle it with Cocoon. If you don't plan on using
> jms either exclude the jms block, or ignore the warning. If you do need
> jms, either get OpenJMS, start it, and put its client jar in WEB-INF\lib
> (and/or in %COCOON_HOME%\optional so it's added there after any future
> rebuilds)
>
> Geoff
>
As mentioned in my mail, I had already put the open JMS lib in the
WEB-INF/lib folder, which in turn brought to light the bug mentioned by JD.
As the bug is already filed, there's nothing else to do at this time but try
to find the time to tackle it and file a patch.
Thanks,
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Geoff Howard <co...@leverageweb.com>.
Sorry, didn't finish my sentence:
Geoff Howard wrote:
> If you do need
> jms, either get OpenJMS, start it, and put its client jar in WEB-INF\lib
> (and/or in %COCOON_HOME%\optional so it's added there after any future
> rebuilds)
or configure the JMS block in cocoon.xconf to use some other jms
implementation.
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: ClassNotFoundException and not unique container name : cocoon-portal
Posted by Geoff Howard <co...@leverageweb.com>.
Bert Van Kets wrote:
> Hi all,
> I just did an update of my CVS Head and built the whole thing (clean
> built!).
> Checking the logs I saw that I got an ClassNotFoundException
> org.exolab.jms.jndi.InitialContextFactory.
> So, I go to Sourceforge, get the needed classes, build and add the lib to
> Cooon.
> Now, when I start up Cocoon again, I get a stack trace (see below)
> complaining about a duplicate container name called "cocoon-portal". A text
> search on this string doesn't give me anything. So I'm stuck (again). :-(
>
> Isn't there supposed to be a dummy class for the openJMS classes???
>
> Is the container name hard coded? If so, it's never goign to be unique is
> it? :-/
>
> I can live without JMS, but it seems there's something wrong here.
Yes, this comes from the jms block which by default is configured to use
OpenJMS but we do not bundle it with Cocoon. If you don't plan on using
jms either exclude the jms block, or ignore the warning. If you do need
jms, either get OpenJMS, start it, and put its client jar in WEB-INF\lib
(and/or in %COCOON_HOME%\optional so it's added there after any future
rebuilds)
AFAIK, the rest of the issue below has to do with the portal and has
nothing whatsoever to do with the jms block. If you don't get answers
on it, it's because you've mixed issues in one email and the people who
know about the portal issue (not me) skipped past the message.
Geoff
> P.S. Using JDK 1.3.1_6 and Tomcat 4.1.29 on WinXP
>
> java.lang.IllegalArgumentException: The given container name is not unique:
> cocoon-portal
> at
> org.apache.pluto.PortletContainerServices.createReference(PortletContainerSe
> rvices.java:53)
> at
> org.apache.pluto.PortletContainerImpl.init(PortletContainerImpl.java:101)
> at
> org.apache.cocoon.portal.impl.PortletPortalManager.initContainer(PortletPort
> alManager.java:211)
> at
> org.apache.cocoon.portal.impl.PortletPortalManager.initialize(PortletPortalM
> anager.java:173)
> at
> org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil
> .java:282)
> at
> org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(De
> faultComponentFactory.java:313)
> at
> org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(
> ThreadSafeComponentHandler.java:143)
> at
> org.apache.avalon.excalibur.component.ExcaliburComponentManager.initialize(E
> xcaliburComponentManager.java:558)
> at
> org.apache.cocoon.components.CocoonComponentManager.initialize(CocoonCompone
> ntManager.java:547)
> at
> org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil
> .java:282)
> at org.apache.cocoon.Cocoon.initialize(Cocoon.java:340)
> at
> org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil
> .java:282)
> at
> org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1371
> )
> at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:514)
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:93
> 5)
> at
> org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:668)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
> va:210)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
> va:191)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
> )
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
> java:171)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:641)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172
> )
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:641)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
> :174)
> at
> org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invok
> eNext(StandardPipeline.java:643)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:193)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:781)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
> ction(Http11Protocol.java:549)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:589)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
> a:666)
> at java.lang.Thread.run(Thread.java:479)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org