I really don't have time for a full refactoring on this project right
now, but I got this going with a minor one. When I looked more closesly
at it, there was only one method in the equipment classes that was using
the servlet API, so I was able to rework that method and the place from
which it is called (which is in the webapp .war file), so that I was
able to pass just the information that I needed from the
HttpServletRequest, rather than the request object itself. That
eliminated the need to have the servlet api accessible from the utility
jar. Then I just had to apply this change to each of the 10 equipment
clases, then make one change to the classpath entry for the standalone
app, and I was done in about an hour.
Thanks for pointing this out, David!
Dave
David Kerber wrote:
David Smith wrote:
JAVA_HOME/lib/ext is in the bootstrap classloader (top-most, above
System). Given your need for running this code standalone and in a
webapp, I think a refactoring is in order. The parts that have to
live in JAVA_HOME/lib/ext should not refer to the servlet api. They
should just return data to classes in your webapp which intern handle
the servlet api stuff. That should get you out of your classloader
problem.
Hmm. Good thought. Please let me clarify my situation and ask for
your comments:
What I have is classes that represent general types of equipment.
Some of the methods for each equipment class are used from the webapp
for managemnt and configuration purposes, and other methods are used
from the standalone app for runtime purposes. There are a few utility
methods that are used both places, but not many. I thought I was
being smart by combining all aspects of each type of equipment into a
single class, but you seem to be saying that I should split each
equipment class into two classes, one for management/configuration,
and one for runtime. Is that interpretation correct?
Dave
--David
David Kerber wrote:
I did some more testing, and discovered an error in my OP. See
inline below...
I already have a message into the makers of the jni package I'm
using with my standalone app to see if they have any input on this.
David Smith wrote:
And where is the class that can't find HttpServletRequest? If in the
common/endorsed folder, try moving it to your WEB-INF/lib (just to
test
Originally, I had the jar's with the classes in question in the
jar/lib/ext folder, because they apparently need to be there for a
standalone app that uses jni to access some of the classes in these
same jars. If I *move* them from the lib/ext folder into the
web-inf/lib folder, then my web app works fine, but my standalone
app fails. What I had initially done when writing my op was to copy
the jars, so that they existed in both lib/ext, and in web-inf/lib,
and my web app doesn't like that, though my standalone app works ok.
a theory). I suspect your startup parameters essentially added the
common/endorsed folder to the system classloader which puts it
above the
My tomcat startup does specify the common/endorsed folders. Can I
take that out if I don't have anything of mine in there? Or can I
do something with common or shared to tell the tomcat to use the
classes from lib/ext?
common classloader where HttpServletRequest would be. If your
class is
in the System classloader it won't see the servlet api at all.
See http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html
I've read that several times in the past, but it's kind of short on
the information I need. I'll look again...
--David
David Kerber wrote:
Running tomcat 5.5.15 on Windows server 2003.
Why would I get the subject error when I'm deep into my code, and not
near the top when I first use it? I'm getting this in a class
that is
buried several layers deep in a utility jar file. The servlet that
calls this class is working fine, I get no compile errors, I am
importing the proper class, and my startup env vars are set to:
-Dcatalina.home=C:\Program Files\Apache Software Foundation\Tomcat
5.5
-Dcatalina.base=c:\TomcatClients\EddSrv
-Djava.endorsed.dirs=C:\Program Files\Apache Software
Foundation\Tomcat 5.5\common\endorsed
Here is the code snippet at issue, and the line where I'm getting the
error. This is in a utility .jar file in web-inf/lib
import javax.servlet.http.HttpServletRequest;
...
public static int updateDb( HttpServletRequest request ) {
HttpSession session;
error line:
session = request.getSession();
This is being called from a class in my .war file:
rslt = TCfgHose.updateDb( request );
It works fine in dev mode in Eclipse, but fails when deployed. What
am I missing? Do I need to put out a jdk after all? Or is there a
problem with passing a HttpServletRequest out of the webapp and
into a
utility .jar?
Dave
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
