Good suggestion. Your hack is better than mine -- I ended up deleting
JRun's
parser.jar, thus making jaxp.jar and crimson.jar the ones JRun itself had to
use for XML processing! Some of the methods in parser.jar which JRun uses
are
now deprecated, but in the Java tradition, they are still supported in the
new version.
Obviously, this isn't a permanent solution either. A future release of JRun
could put the XML jar file yet some other place.
Duane Morse, Eldorado Computing Inc., Phoenix AZ
-----Original Message-----
From: Jules A. Yasuna [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 21, 2001 5:01 AM
To: [EMAIL PROTECTED]
Subject: Re: Dealing with incompatible jar files in servlet container
Had this problem with JRun (indeed, exactly this problem when using jaxp1.1)
One solution is to get your JAR files ahead of the container's JAR
file in the load schema (in general, not a good idea, but that is how we
solved this one)
A few possibilities ...
1) place your JAR files in the <installDir>lib/ext directory of the JVM.
This should
result in the JVM accessing your JAR files first. (untested !)
2) for JRun, place your JAR files in the so-called "user" library
directories. For all of the
JRun servers, this is <installDir>/servers/lib. For a particular JRun
server (for example,
the default server) this is <installDir>/servers/default/lib. Now, you
still have to modify
the properties file (<installDir>/lib/global.properties or
<installDir>/servers/default/local.properties) to get the so-called
"user" libraries ahead
of the JRun's libraries.
in global.properties, JRun has the following ...
java.classpath={jrun.classpath};{user.classpath};{ejb.classpath};{servlet.cl
asspath}
jrun.classpath={jrun.rootdir}/lib/ext;{jrun.rootdir}/lib/jrun.jar;{jrun.root
dir}/lib/install.jar
user.classpath={jrun.rootdir}/servers/lib;{jrun.server.rootdir}/lib
notice that you have placed your JAR files in their "user.classpath", but
their "java.classpath"
uses their "jrun.classpath" ahead of the "user.classpath". So, we swapped
these around (you
can add the following line in global.properties if you want it to effect
all the servers or
in local.properties if you want it to effect just that server)
java.classpath={user.classpath};{jrun.classpath};{ejb.classpath};{servlet.cl
asspath}
Please note that I do not advocate this methodology. One *should* be able to
distribute
a WAR and, at the discretion of (and responsibility of) the deployer, have
the code
in that WAR supersede application server code in this type of conflicting
situation.
Perhaps this is indeed possible with JRun, and if so I would gladly welcome
a more
professional solution than the ugly hack which we have employed (as
described in item
2 above)
--
jules
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
