I am running into an unusual problem trying to get struts working with
Tomcat4.1.18.

We have a requirement to compile all of our classes for many applications on
the system classpath.  This is a bit different from the standard J2EE
specification of having applications compile their classes into the
WEB-INF/classes folder of their war file.

To write our applications correctly and use struts, we need struts on the
system classpath along with our application classes and many other 3rd party
applications.   

This works fine with struts1.0.2.  We put the jar in the system classpath
and this runs fine in Tomcat4.1.18.

We are now trying struts1.1-beta3 and we run into many problems.

On our first run, there is the issue of the commons files not available for
struts.




We add the commons files supplied by struts1.1-beta3 and we get the
following error from tomcat:

Catalina.start: java.lang.ClassNotFoundException:
org.apache.catalina.core.StandardServer
java.lang.ClassNotFoundException: org.apache.catalina.core.StandardServer
        at
org.apache.commons.digester.Digester.createSAXException(Digester.java:2383)
        at
org.apache.commons.digester.Digester.createSAXException(Digester.java:2409)
        at
org.apache.commons.digester.Digester.startElement(Digester.java:1271)
        at
org.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.j
ava:454)
        at
org.apache.xerces.impl.XMLNamespaceBinder.startElement(XMLNamespaceBinder.ja
va:571)
        at
org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(XMLDTDValidator.java
:756)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDo
cumentFragmentScannerImpl.java:752)
        at
org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElem
entHook(XMLDocumentScannerImpl.java:942)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatc
her.dispatch(XMLDocumentFragmentScannerImpl.java:1520)
        at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocume
ntFragmentScannerImpl.java:333)
        at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:524)
        at
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:580)
        at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
        at
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:116
9)
        at org.apache.commons.digester.Digester.parse(Digester.java:1543)
        at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
        at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
        at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
        at java.lang.reflect.Method.invoke(Native Method)
        at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
Cannot continue at c:\J2SEDomain\admin/Util/Process.pm line 37.

After a bit of troubleshooting, we determine that the commons-digester.jar
that we added to get struts1.1-beta3 working is now interfering with Tomcat
operation.
The way classloaders work, this makes sense.

I remove the commons-digester.jar and tomcat starts up again.   But the
struts.jar depends on the commons-digester so struts is again broken.

Does anyone know of a good way to resolve this conflict?  We need to get
struts running on the system classpath.   
Any help anyone can give is greatly appreaciated.

thanks,
Mark Holden


FYI.  I am aware of the classloader issue of the struts code not being able
to see code in the war files.  We resolve the issue by having all
application code on the system classpath.  Changing applications to build
classes into the war files is too much of an impact for our projects.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to