Re: ClassNotFoundException and not unique container name : cocoon-portal

[Geoff Howard]

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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]