Re: Tomcat 4.01 tag renders in wrong place
David, My architecture is pretty straightforward. I have a jsp page. It contains my tag. My tag does a RequestDispatcher.inlcude() to another jsp page based on whether a user is logged in. Nothing tricky here. Well, except for the trick of the included content magically appearing in the wrong spot! Thanks for your response, Bill Pfeiffer - Original Message - From: David M. Karr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 19, 2001 11:26 AM Subject: Re: Tomcat 4.01 tag renders in wrong place Bill == Bill Pfeiffer [EMAIL PROTECTED] writes: Bill The page buffer/autoFlush tag worked like a charm: Bill %@ page buffer=0 autoFlush=true % Bill Big Thanks!! Bill I will research into why I have to add this tag to get my include to work Bill correctly, but if anyone has a short answer on it, I'd be curious to know. It almost seems like your include machinery is writing to the main output stream, as opposed to the buffer owned by the tag. That seems to explain the circumstances you're seeing. -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004) -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Tomcat 4.01 tag renders in wrong place
I have a custom tag that performs an include. The included content gets positioned smack in the middle of a preceding td tag. The custom tag content actually appears in the middle of a word (part of one of the td attributes). Knowing almost nothing about Tomcat 4, it LOOKS like perhaps some preceding content is buffered, and then the custom tag content is written before the buffered content. But thats just a wild guess. I'd be happy to provide more info but I'm not sure exactly what to provide. Any ideas? Bill Pfeiffer -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Tomcat 4.01 tag renders in wrong place
The page buffer/autoFlush tag worked like a charm: %@ page buffer=0 autoFlush=true % Big Thanks!! I will research into why I have to add this tag to get my include to work correctly, but if anyone has a short answer on it, I'd be curious to know. Thanks, Bill Pfeiffer - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, December 18, 2001 3:19 PM Subject: Re: Tomcat 4.01 tag renders in wrong place Bill Pfeiffer [EMAIL PROTECTED] on 12/18/2001 02:10:59 PM Please respond to Tomcat Users List [EMAIL PROTECTED] To: Tomcat-User [EMAIL PROTECTED] cc: Subject: Tomcat 4.01 tag renders in wrong place I have a custom tag that performs an include. The included content gets positioned smack in the middle of a preceding td tag. The custom tag content actually appears in the middle of a word (part of one of the td attributes). Knowing almost nothing about Tomcat 4, it LOOKS like perhaps some preceding content is buffered, and then the custom tag content is written before the buffered content. But thats just a wild guess. Possibly correct. Turn of the buffering. Try this at the top of your jsp page: %@ page buffer=0 autoFlush=true % I'd be happy to provide more info but I'm not sure exactly what to provide. Any ideas? Bill Pfeiffer -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RequestDispatcher.include loses request.attribute
I have written a tag that will include another jsp's contents based on a user's login status. I am attempting to pass data to the included jsp(s) by setting an attribute on the request. I then call RequestDispatcher.include(req, resp). The problem I am enountering is that the included jsp does not see the attribute I set in the request within the tag code. It looks like the attributes are cleared before the included jsp is run. I encountered this in SilverStream and it turned out to be a bug (which they fixed). Any ideas here? TIA, Bill Pfeiffer
Re: RequestDispatcher.include loses request.attribute (tomcat 4.01)
BTW, using Tomcat 4.01 on jdk 1.3.1 01 on Win2000 sp2 - Original Message - From: Bill Pfeiffer [EMAIL PROTECTED] To: Tomcat-User [EMAIL PROTECTED] Sent: Friday, December 14, 2001 3:55 PM Subject: RequestDispatcher.include loses request.attribute I have written a tag that will include another jsp's contents based on a user's login status. I am attempting to pass data to the included jsp(s) by setting an attribute on the request. I then call RequestDispatcher.include(req, resp). The problem I am enountering is that the included jsp does not see the attribute I set in the request within the tag code. It looks like the attributes are cleared before the included jsp is run. I encountered this in SilverStream and it turned out to be a bug (which they fixed). Any ideas here? TIA, Bill Pfeiffer -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: jsp and tomcat 4
This is a known bug with Tomcat 4.0b5 release and WinNT/2000. Get a recent nightly build and the problem should go away. HTH, Bill Pfeiffer - Original Message - From: D. Jay Newman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, July 17, 2001 9:21 AM Subject: Re: jsp and tomcat 4 I have a question: if I modify a JSP under tomcat4 i don't see any change in browser because tomcat4 get the .class of JSP in cache (directory work) How can I say to recompile the jsp if there are changes in java?? This is strange. I'm using Tomcat 4.0b5 and had problems only once (I had to manually fix my system's time, and that changed the timestamps so that the older cached versions had newer timestamps than the JSP file I was editing). Otherwise I always get automatic recompilation if I only change the JSP file (if I change a package I call from there I have to go through hoops, but that's another story). This was on linux. -- D. Jay Newman ! For the pleasure and the profit it derives [EMAIL PROTECTED] ! I arrange things, like furniture, and http://www.sprucegrove.com/~jay/ ! daffodils, and ...lives. -- Hello Dolly
Re: . Reloading JSP's
Just confirming that this is a known bug with the win32 version. I believe using a recent nightly build fixes this problem. Bill Pfeiffer - Original Message - From: Drinkwater Glen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 11, 2001 8:32 AM Subject: . Reloading JSP's I am using tomcat 4.0 beta 5 on win NT and the problem is that when i make a change to a jsp page tomcat doesnt pick it up, i have tried to refresh the browser, shut down the start up again and nothing happens. The only thing i can do is resave the JSP as another name, which is really annoying. Any ideas on the situation?? Glen -- The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.
Tomcat 4 won't recognize servlet (repost)
Anybody know why my servlet under Tomcat 3.21 is not a servlet under Tomcat 4 b5? My servlet source appears to conform with spec 2.2 and 2.3. I'm a little confused why it won't cast to a servlet. I've listed the relevent snippets from the log.txt file. Thanks for any help, Bill Pfeiffer - 2001-05-15 21:00:05 StandardContext[/oasis-war]: Servlet /oasis-war threw load() exception javax.servlet.ServletException: Class com.pdma.oasis.servlets.InitServlet is not a Servlet at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813) - Root Cause - java.lang.ClassCastException: com.pdma.oasis.servlets.InitServlet at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:810)
Catalina-Servlet is not a Servlet
Anybody know why my servlet under Tomcat 3.21 is not a servlet under Tomcat 4 b5? My servlet source appears to conform with spec 2.2 and 2.3. I'm a little confused why it won't cast to a servlet. I've listed the relevent snippets from the log.txt file. Thanks for any help, Bill Pfeiffer - 2001-05-15 21:00:05 StandardContext[/oasis-war]: Servlet /oasis-war threw load() exception javax.servlet.ServletException: Class com.pdma.oasis.servlets.InitServlet is not a Servlet at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:813) - Root Cause - java.lang.ClassCastException: com.pdma.oasis.servlets.InitServlet at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:810)
Re: sealing violation in 4.0m5
Classpath is not set (ie set to empty) when starting Tomcat. My web app does include some jars, none of which should clash with Tomcat. Any other ideas on what to start looking for in terms of a clash?. The class in question appears to be one of my own in the WEB-INF/class directory. Thanks, Bill Pfeiffer - Original Message - From: "Kitching Simon" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 20, 2000 6:06 AM Subject: RE: sealing violation in 4.0m5 Hi Bill. I believe a "sealing violation" is when a class which was loaded under one classloader tries to call a class loaded under a different classloader, in circumstances where this isn't allowed. I suggest that the problem is therefore something to do with classpaths, ie your classpath includes some files it shouldn't. The result is that tomcat is expecting code to be loaded by a particular classloader, but because it is in the classpath, it has already been loaded by the system class loader. Hope this helps, Simon -Original Message- From: Bill Pfeiffer [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, December 20, 2000 6:06 AM To: Tomcat Subject: sealing violation in 4.0m5 Trying to port my 3.2 app to 4.0. One simple page works, but the main page of my app yeilds the exception below. Any idea what a "sealing violation' is? Sounds like a security issue. Ideas? TIA, Bill Pfeiffer A Servlet Exception Has Occurred Exception Report: javax.servlet.ServletException: Servlet.init() for servlet OasisCommand threw exception at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:774) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544 ) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve. ja va:227) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve. ja va:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1 61 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja va :159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.jav a: 811) at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:89 0) at java.lang.Thread.run(Thread.java:484) Root Cause: java.lang.SecurityException: sealing violation at java.net.URLClassLoader.defineClass(URLClassLoader.java:234) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.catalina.loader.StandardClassLoader.findClass(StandardClassLoad er .java:648) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoad er .java:987) at org.apache.catalina.loader.StandardClassLoader.loadClass(StandardClassLoad er .java:906) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at com.pdma.oasis.servlets.OasisCommandServlet.initCommands(OasisCommandServl et .java:94) at com.pdma.oasis.servlets.OasisCommandServlet.init(OasisCommandServlet.java: 27 ) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:755) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:544 ) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve. ja va:227) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve. ja va:196) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2038) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1 61 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja va :159) at org.apache.catalina.core.ContainerBase.invo
Re: jar's still not picked up in WEB-INF/lib
I am experiencing the same problem that others have reported on this topic. I explicitly set my Tomcat classpath to be sure of no redundancies in the jars. I have a Tomcat startup batch file with one line that adds in all the jars in my WEB-INF\lib to the classpath explicitly. When I comment that line out, I get the classnotfound errors. When I put it back in, my web app runs fine. Obviosly I want the line commented out and have the jars picked up in the lib dir, but that aint happening. Because the jars work when explicitly included in the classpath, I conclude that the jars are not corrupt. I also conclude, based on commenting out the explicit lib jars classpath, that there are not redundant jars in the classpath. I have also checked other sources for possible classpath jar redundancies and I am just not finding any. I am running under Win2000 using jdk1.3. These is the exact dir structure I have set up: D:\Java\jakarta-tomcat\webapps D:\Java\jakarta-tomcat\webapps\Oasis D:\Java\jakarta-tomcat\webapps\Oasis\jsp D:\Java\jakarta-tomcat\webapps\Oasis\META-INF D:\Java\jakarta-tomcat\webapps\Oasis\resources D:\Java\jakarta-tomcat\webapps\Oasis\WEB-INF D:\Java\jakarta-tomcat\webapps\Oasis\WEB-INF\classes D:\Java\jakarta-tomcat\webapps\Oasis\WEB-INF\lib I have gone through Craig McClanahans list of things to check and all seems to be as it should. Any hope for a fix? Should I continue to look at my config? I have heard some people talk about setting up an explicit context for the app in the server.xml. Does this solve the problem consistantly? TIA, Bill Pfeiffer
Re: jar's still not picked up in WEB-INF/lib
Forgot to mention, I'm using Tomcat 3.2beta6. - Original Message - From: Bill Pfeiffer To: Tomcat Sent: Wednesday, November 01, 2000 8:13 AM Subject: Re: jar's still not picked up in WEB-INF/lib I am experiencing the same problem that others have reported on this topic. I explicitly set my Tomcat classpath to be sure of no redundancies in the jars. I have a Tomcat startup batch file with one line that adds in all the jars in my WEB-INF\lib to the classpath explicitly. When I comment that line out, I get the classnotfound errors. When I put it back in, my web app runs fine. Obviosly I want the line commented out and have the jars picked up in the lib dir, but that aint happening. Because the jars work when explicitly included in the classpath, I conclude that the jars are not corrupt. I also conclude, based on commenting out the explicit lib jars classpath, that there are not redundant jars in the classpath. I have also checked other sources for possible classpath jar redundancies and I am just not finding any. I am running under Win2000 using jdk1.3. These is the exact dir structure I have set up: D:\Java\jakarta-tomcat\webapps D:\Java\jakarta-tomcat\webapps\Oasis D:\Java\jakarta-tomcat\webapps\Oasis\jsp D:\Java\jakarta-tomcat\webapps\Oasis\META-INF D:\Java\jakarta-tomcat\webapps\Oasis\resources D:\Java\jakarta-tomcat\webapps\Oasis\WEB-INF D:\Java\jakarta-tomcat\webapps\Oasis\WEB-INF\classes D:\Java\jakarta-tomcat\webapps\Oasis\WEB-INF\lib I have gone through Craig McClanahans list of things to check and all seems to be as it should. Any hope for a fix? Should I continue to look at my config? I have heard some people talk about setting up an explicit context for the app in the server.xml. Does this solve the problem consistantly? TIA, Bill Pfeiffer
Re: jar's still not picked up in WEB-INF/lib
Raghu, I did misread your message. My apologies. I agree that putting the libs in the $TOMCAT/lib is probably not a good thing (in terms of a self contained web app). I'm still curious about the lib ordering when they are picked up from the WEB-INF/lib directory though. If I set my classpath I can control this. How would you control it otherwise? Bill Pfeiffer - Original Message - From: Raghu Havaldar To: '[EMAIL PROTECTED]' Sent: Wednesday, November 01, 2000 10:42 AM Subject: RE: jar's still not picked up in WEB-INF/lib I think u misread me a bit. I would NOT recommend putting them under $TOMCAT/lib. However, their right place is (as the doc suggests) in $TOMCAT/webapps/APP/web-inf/lib. I have not yet looked at load-balancing issues. But, they are another beast (for upgrades and such). -raghu -Original Message-From: Bill Pfeiffer [mailto:[EMAIL PROTECTED]]Sent: Wednesday, November 01, 2000 9:28 AMTo: [EMAIL PROTECTED]Subject: Re: jar's still not picked up in WEB-INF/lib Aside from the fact that it does not work incertain situations, why would you think it is not a good idea to put your app specific libs under the WEB-INF\lib directory. The spec says to do it. It allows for good application orginization. What would be your arguments against it? Actually I can think of one argument against it, and that is that by including your libs in the classpath instead, you can control the order of the classpath.It appears that using the libs directory would allow for random ordering (based on OS directory ordering) of these libs. Also, I need to include zip files and these don't get picked up anyway. Maybe using the classpath is the way to go. Bill Pfeiffer - Original Message - From: Raghu Havaldar To: '[EMAIL PROTECTED]' Sent: Wednesday, November 01, 2000 9:34 AM Subject: RE: jar's still not picked up in WEB-INF/lib The Context setup is for the web-app. I do not think it is a good idea to put app-depedent libs under $TOMCAT/lib. Just for experimentation, I tried placing the JARs under $TOMCAT/lib and $TOMCAT/webapps/web-inf/lib. Does not work. Tried with 3.1 and 3.2beta6 on WinNT 4.0. -raghu -Original Message-From: Leon Palermo [mailto:[EMAIL PROTECTED]]Sent: Wednesday, November 01, 2000 7:31 AMTo: [EMAIL PROTECTED]Subject: Re: jar's still not picked up in WEB-INF/lib I would definitely set up a context in server.xml like this: Context path="/Oasis"docBase="webapps/Oasis" debug="0" reloadable="true" /Context That should solve you problem. Otherwise, just put the .jar files in theD:\Java\jakarta-tomcat\lib directory. Then the jars would be available for all applications served by tomcat. Leon Palermo Zedak Corporation Valhalla, NY - Original Message - From: Bill Pfeiffer To: Tomcat Sent: Wednesday, November 01, 2000 8:13 AM Subject: Re: jar's still not picked up in WEB-INF/lib I am experiencing the same problem that others have reported on this topic. I explicitly set my Tomcat classpath to be sure of no redundancies in the jars. I have a Tomcat startup batch file with one line that adds in all the jars in my WEB-INF\lib to the classpath explicitly. When I comment that line out, I get the classnotfound errors. When I put it back in, my web app runs fine. Obviosly I want the line commented out and have the jars picked up in the lib dir, but that aint happening. Because the jars work when explicitly included in the classpath, I conclude that the jars are not corrupt. I also conclude, based on commenting out the explicit lib jars classpath, that there are not redundant jars in the classpath. I have also checked other sources for possible classpath jar redundancies and I am just not finding any. I am running under Win2000 using jdk1.3. These is the exact dir structure I have set up: D:\Java\jakarta-tomcat\webapps D:\Java\jakarta-tomcat\webapps\Oasis D:\Java\jakarta-tomcat\webapps\Oasis\jsp D:\Java\jakarta-tomcat\webapps\Oasis\META-INF D:\Java\jakarta-tomcat\webapps\Oasis\resources D:\Java\jakarta-tomcat\webapps
Re: jar's still not picked up in WEB-INF/lib
Leon,
I added a "context" into the server and it found my
jars. But, careful what you ask for, the ordering ends up being
important. I had to go back to using the classpath to make sure that the
jars are hit in the proper order. Oh well.
BTW, my reply below was based on my having misread
Raghu's response. I incorrectly thought he was talking about not using
theWEB_INF\lib dir.
Unzipping my clashing jars would not bode
well. Problem is that my app talks to more than 1 app server and the jar
arrangement is precarious at best. Some of the same, slightly different,
packages included in client jars from the app server vendors. One
classpath ordering works, the other doesn't.
Bill P.
- Original Message -
From:
Leon Palermo
To: [EMAIL PROTECTED]
Sent: Wednesday, November 01, 2000 1:05
PM
Subject: Re: jar's still not picked up in
WEB-INF/lib
I agree that you should not put application
specific jar files in the main $TOMCAT/lib directory because the jar files
should reside with their application. I was saying, as a last resort try
putting the jars in the main TOMCAT lib. Did you try it?
I always just unzip any zip files in the
WEB-INF/classes directory or you could make your own jar file of those
classes.
-Leon
- Original Message -
From:
Bill Pfeiffer
To: [EMAIL PROTECTED]
Sent: Wednesday, November 01, 2000
10:28 AM
Subject: Re: jar's still not picked up
in WEB-INF/lib
Aside from the fact that it does not work
incertain situations, why would you think it is not a good idea to put
your app specific libs under the WEB-INF\lib directory.
The spec says to do it. It allows for
good application orginization. What would be your arguments against
it?
Actually I can think of one argument against
it, and that is that by including your libs in the classpath instead, you
can control the order of the classpath.It appears that using the
libs directory would allow for random ordering (based on OS directory
ordering) of these libs. Also, I need to include zip files and these
don't get picked up anyway. Maybe using the classpath is the way to
go.
Bill Pfeiffer
- Original Message -
From:
Raghu Havaldar
To: '[EMAIL PROTECTED]'
Sent: Wednesday, November 01, 2000
9:34 AM
Subject: RE: jar's still not picked
up in WEB-INF/lib
The Context setup is for the web-app.
I do not think it is a good idea to put
app-depedent
libs under $TOMCAT/lib.
Just for experimentation, I tried placing the JARs
under
$TOMCAT/lib and $TOMCAT/webapps/web-inf/lib.
Does
not work.
Tried with 3.1 and 3.2beta6 on WinNT 4.0.
-raghu
-Original Message-From: Leon Palermo [mailto:[EMAIL PROTECTED]]Sent:
Wednesday, November 01, 2000 7:31 AMTo:
[EMAIL PROTECTED]Subject: Re: jar's still not
picked up in WEB-INF/lib
I would definitely set up a context in
server.xml like this:
Context
path="/Oasis"docBase="webapps/Oasis" debug="0"
reloadable="true" /Context
That should solve you problem.
Otherwise, just put the .jar files in
theD:\Java\jakarta-tomcat\lib directory. Then the jars would
be available for all applications served by tomcat.
Leon Palermo
Zedak Corporation
Valhalla, NY
- Original Message -
From:
Bill Pfeiffer
To: Tomcat
Sent: Wednesday, November 01,
2000 8:13 AM
Subject: Re: jar's still not
picked up in WEB-INF/lib
I am experiencing the same problem that
others have reported on this topic. I explicitly set my Tomcat
classpath to be sure of no redundancies in the jars. I have a
Tomcat startup batch file with one line that adds in all the jars in
my WEB-INF\lib to the classpath explicitly. When I comment that
line out, I get the classnotfound errors. When I put it back in,
my web app runs fine. Obviosly I want the line commented out and
have the jars picked up in the lib dir, but that aint
happening.
Because the jars work when explicitly
included in the classpath, I conclude that the jars are not
corrupt. I also conclude, based on commenting out the explicit
lib jars classpath, that there are not redundant jars in the
classpath. I have also checked other sources for possible
classpath jar redundancies and I am just not finding any.
