You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rick Anderson <ri...@rci.rutgers.edu> on 2000/11/02 19:49:08 UTC
mod_jk.conf-auto source file
Which file is used to generate mod_jk.conf-auto from?
Thanks,
-_Rick Anderson
______________________________________________________
Rick Anderson | rianders@rci.rutgers.edu
________________|_____________________________________
Continuous Education & Outreach
Manager of Computer Systems, (732)932-5071
______________________________________________________
Re: mod_jk.conf-auto source file
Posted by John Elia <je...@ratedg.com>.
I am getting a java.lang.OutOfMemoryError while building Tomcat on RedHat
Linux 6.2 with tomcat V. 3.2 . My problem starts when I try to build tomcat
with ant (which I just compiled, and it went well). so here is a [snip!] of
what I did.
[root@node1 tomcat]# ../ant/bin/ant
Buildfile: build.xml
init:
prepare:
BUILD FAILED
java.lang.OutOfMemoryError:
at java.lang.StringBuffer.expandCapacity(StringBuffer.java:200)
at java.lang.StringBuffer.append(StringBuffer.java:392)
at java.io.UnixFileSystem.resolve(UnixFileSystem.java:92)
at java.io.File.<init>(File.java:271)
at
org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:637)
at
org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:648)
at
org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:648)
[end snip!]
Any suggestions???
John Elia
711.NET
Re: mod_jk.conf-auto source file
Posted by "Robert M. Zigweid" <ti...@internation.co.uk>.
Rick Anderson wrote:
>
> Which file is used to generate mod_jk.conf-auto from?
>
> Thanks,
> -_Rick Anderson
>
> ______________________________________________________
> Rick Anderson | rianders@rci.rutgers.edu
> ________________|_____________________________________
> Continuous Education & Outreach
> Manager of Computer Systems, (732)932-5071
> ______________________________________________________
IIRC it's from server.xml
Robert M. Zigweid
Re: Tomcat ... sealing violation - [Cool! Answered before I get my message echoed ;)]
Posted by Ray Allis <ra...@boeing.com>.
"Craig R. McClanahan" wrote:
>
> Willie Wheeler wrote:
>
> > Hi all,
RE: Tomcat 4.0 m3, 4 sealing violation
Posted by Willie Wheeler <ww...@andrew.cmu.edu>.
Hi Craig,
I understand that there is nothing in the short run that can be done about
the sealing violation problem for webapps requiring JSP that use parsers
noncompliant with JAXP 1.1, but from your response I'm inferring that the
issue of how properly to handle this in the long run is still up for
discussion. I would think that Tomcat shouldn't limit the non-servlet
libraries (e.g., XML libraries) that webapps can use by putting sealed
packages in the way. That way, JSP-based apps using older XML parsers (and
I'm sure that there are plenty of apps in this category) can migrate to
Tomcat 4.0. Something along the lines you suggested--namely, giving Jasper
its own private classloader, or at least making it an option to load
crimson.jar with a private classloader--seems quite reasonable. Even if it
is not a trivial amount of work, it would be better for Tomcat to assume its
burden than to push it onto app developers, thus making migration hard or
impossible.
Willie
-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: Thursday, November 02, 2000 4:03 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: Tomcat 4.0 m3, 4 sealing violation
Willie Wheeler wrote:
> Hi all,
>
> I get package sealing violations when I run my web app on Tomcat
4.0 m3 and
> m4. I never got these with previous releases, and it looks to me as if
the
> cause is the addition of the sealed crimson.jar JAR file to the library.
> Problem is that my app uses JDOM b4, which is using Xerces 1.1.2, and
Xerces
> contains a bunch of JAXP/DOM/SAX classes that also appear in crimson.jar
> (hence the sealing violation).
> Does anybody have any advice on how best to handle this situation?
I guess
> that one way is to remove the duplicate classes from either crimson.jar or
> xerces_1_1_2.jar, but that seems less than ideal, and could easily lead to
> breakage. Maybe some solution involving loading the JARs with different
> class loaders?
>
> Thanks,
> Willie
Welcome to the wonderful world of classloaders :-).
You're correct -- trying to remove classes from one or the other of the JAR
files is
not going to work at all. Each library will be depending on its own
internal
implementation of those classes.
The crimson.jar file is placed in $CATALINA_HOME/lib (and therefore visible
to web
apps) because Jasper needs a JAXP-1.1 compatible parser. It would be
technically
feasible for Jasper to load its own XML parser in a private classloader, but
this is
not a trivial amount of work. Once Xerces is upgraded to JAXP-1.1
compatibility you
will simply be able to use Xerces instead (and thus not have these
conflicts).
If your app does not need JSP, you could simply remove crimson.jar from
$CATALINA_HOME/lib (you will want to comment out the JSP servlet in
$CATALINA_HOME/conf/web.xml as well). If you do, I'm afraid there isn't
much that can
be done in the short run until all the parsers catch back up with JAXP
compatibility
again.
Craig McClanahan
Re: Tomcat 4.0 m3, 4 sealing violation
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Willie Wheeler wrote:
> Hi all,
>
> I get package sealing violations when I run my web app on Tomcat 4.0 m3 and
> m4. I never got these with previous releases, and it looks to me as if the
> cause is the addition of the sealed crimson.jar JAR file to the library.
> Problem is that my app uses JDOM b4, which is using Xerces 1.1.2, and Xerces
> contains a bunch of JAXP/DOM/SAX classes that also appear in crimson.jar
> (hence the sealing violation).
> Does anybody have any advice on how best to handle this situation? I guess
> that one way is to remove the duplicate classes from either crimson.jar or
> xerces_1_1_2.jar, but that seems less than ideal, and could easily lead to
> breakage. Maybe some solution involving loading the JARs with different
> class loaders?
>
> Thanks,
> Willie
Welcome to the wonderful world of classloaders :-).
You're correct -- trying to remove classes from one or the other of the JAR files is
not going to work at all. Each library will be depending on its own internal
implementation of those classes.
The crimson.jar file is placed in $CATALINA_HOME/lib (and therefore visible to web
apps) because Jasper needs a JAXP-1.1 compatible parser. It would be technically
feasible for Jasper to load its own XML parser in a private classloader, but this is
not a trivial amount of work. Once Xerces is upgraded to JAXP-1.1 compatibility you
will simply be able to use Xerces instead (and thus not have these conflicts).
If your app does not need JSP, you could simply remove crimson.jar from
$CATALINA_HOME/lib (you will want to comment out the JSP servlet in
$CATALINA_HOME/conf/web.xml as well). If you do, I'm afraid there isn't much that can
be done in the short run until all the parsers catch back up with JAXP compatibility
again.
Craig McClanahan
Tomcat 4.0 m3, 4 sealing violation
Posted by Willie Wheeler <ww...@andrew.cmu.edu>.
Hi all,
I get package sealing violations when I run my web app on Tomcat 4.0 m3 and
m4. I never got these with previous releases, and it looks to me as if the
cause is the addition of the sealed crimson.jar JAR file to the library.
Problem is that my app uses JDOM b4, which is using Xerces 1.1.2, and Xerces
contains a bunch of JAXP/DOM/SAX classes that also appear in crimson.jar
(hence the sealing violation).
Does anybody have any advice on how best to handle this situation? I guess
that one way is to remove the duplicate classes from either crimson.jar or
xerces_1_1_2.jar, but that seems less than ideal, and could easily lead to
breakage. Maybe some solution involving loading the JARs with different
class loaders?
Thanks,
Willie