org.quartz.SchedulerException: Scheduler with name 'Cocoon' already exists

[Jonny Pony <jo...@hotmail.com>]

Hi,

this was asked before, but never answered.

I'm running Apache 2.x, Tomcat 5.x, jdk 1.4.2.x on a Windows machine.
Now I "installed" cocoon 2.1.6. (dev) on tomcat. When I try to retrieve the 
cocoon I get the following error: org.quartz.SchedulerException: Scheduler 
with name 'Cocoon' already exists.


I found this thread: 
http://swforum.sun.com/jive/thread.jspa?threadID=46088&tstart=105.
Parts from the thread:

...
Once you've changed server.policy to grant AllPermission globally, you are 
probably going to see this exception:

Original Exception: org.quartz.SchedulerException: Scheduler with name 
'Cocoon' already exists.
at org.quartz.impl.SchedulerRepository.bind(SchedulerRepository.java:87)
at 
org.quartz.impl.DirectSchedulerFactory.createScheduler(DirectSchedulerFactory.java:340)

At the core of the problem is the following exception:

java.lang.NoClassDefFoundError: javax/portlet/PortletRequest

which is thrown by CocoonServlet.init().

Notice that the CocoonServlet's entry in the web.xml contains this line:

<load-on-startup>1</load-on-startup>

meaning that the CocoonServlet is loaded and initialized when its
containing webapp is started, as opposed to when it is first accessed.

However, because of the above exception during CocoonServlet.init(), the 
servlet engine does not consider the servlet initialized, and will 
initialize it again when the servlet is first accessed, resulting in the 
org.quartz.SchedulerException ("Scheduler with name 'Cocoon' already 
exists").

Notice that the Cocoon webapp bundles its own JAR with javax.portlet classes 
under WEB-INF/lib.

In AS 8.0, we made an effort to implement SRV.9.7.2: "Web Application Class 
Loader":

[...] Also, servlet containers that are part of a J2EE product should
not allow the application to override J2SE or J2EE platform
classes, such as those in java.* and javax.* namespaces, that
either J2SE or J2EE do not allow to be modified.

We obviously missed to add javax.portlet to the default list of packages 
that may be overridden, but luckily, this list is configurable:

Add "javax.portlet" to the value of the
com.sun.enterprise.overrideablejavaxpackages system property in 
${S1AS_HOME}/lib/launcher.xml, as follows:

<sysproperty key="com.sun.enterprise.overrideablejavaxpackages"

value="javax.sql.rowset,javax.faces,javax.servlet.jsp.jstl,javax.xml.bind,javax.help,javax.portlet"/>

Another option would be to copy the JAR containing the javax.portlet classes 
to your ${S1AS_HOME}/lib directory.
_________________________________________________--

>Another option would be to copy the JAR containing the javax.portlet 
>classes to your
>${S1AS_HOME}/lib directory.

Could I try this with Tomcat, because this was run on the Sun Java System 
Application Server 8?
Or is there a better solution?
Did I do something wrong in my configuration?

Thanks
Jonny

_________________________________________________________________
Die rote Karte für lästige E-Mails. MSN Hotmail mit Junk-Mail-Filter. 
http://www.msn.de/antispam/prevention/junkmailfilter Jetzt kostenlos 
anmelden!


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org