DO NOT REPLY [Bug 33358] - jasper2 bug because classloader-problems

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33358] - jasper2 bug because classloader-problems

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33358] New: - jasper2 bug because classloader-problems

gzilla/show_bug.cgi?id=33358 Summary: jasper2 bug because classloader-problems Product: Tomcat 5 Version: 5.0.30 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component:

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

gzilla/show_bug.cgi?id=16211 Classloader problems with Xerces --- Additional Comments From [EMAIL PROTECTED] 2003-01-30 09:43 --- Hello, it is stated that the classloader must not allow the WAR to override J2SE or Java servlet API classes. Does the class org.apache.xml.serialize.XMLSeri

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

gzilla/show_bug.cgi?id=16211 Classloader problems with Xerces --- Additional Comments From [EMAIL PROTECTED] 2003-01-17 19:24 --- I would never imagine that Xerces is actually blocked from loading, since I'm running, as I said, on JDK 1.3.1_06... :-))) But, I have a few more words:

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

gzilla/show_bug.cgi?id=16211 Classloader problems with Xerces --- Additional Comments From [EMAIL PROTECTED] 2003-01-17 18:19 --- Well, let try to clarify a little bit more. From the Servlet specs: SRV.9.7.2 Web Application Classloader The classloader that a container uses to load a servle

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

gzilla/show_bug.cgi?id=16211 Classloader problems with Xerces --- Additional Comments From [EMAIL PROTECTED] 2003-01-17 17:37 --- Forgot to say: I'm using JDK 1.3.1_06 "This is the proper behaviour." Sounds like a contradiction to me, as Tomcat docs says that the WEB-INF/lib

DO NOT REPLY [Bug 16211] - Classloader problems with Xerces

gzilla/show_bug.cgi?id=16211 Classloader problems with Xerces [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Reso

DO NOT REPLY [Bug 16211] New: - Classloader problems with Xerces

gzilla/show_bug.cgi?id=16211 Classloader problems with Xerces Summary: Classloader problems with Xerces Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority:

Re: ClassLoader problems

Once again - debugging it is close to impossible ( just like most classloader problems), but luckily I guessed how to fix it - just remove the "endorsed" property and it works again... What "endorsed dirs" has to do with ActionHook - I don't know. Costin Costin Manol

ClassLoader problems

Ok, that's another really strange JDK1.4 problem. I hate class loaders. It works perfectly fine with JDK1.3 - but fails with JDK1.4.1. Needless to say - tomcat-coyote is in lib, and if I enable -verbose:class it actually displays a line showing ActionHook is loaded - only to throw the exception f

Re: 4.1.12-LE ClassLoader Problems

Kevin Ross wrote: > I successfully started over again with a fresh installation of Tomcat > 4.1.12-LE, uncovering another side effect of the tomcat classloader. I > find that the ClassLoader-HOWTO is very vague in explaining the exact > boundaries of the classloaders...here's why: > > To make

Re: 4.1.12-LE ClassLoader Problems

I successfully started over again with a fresh installation of Tomcat 4.1.12-LE, uncovering another side effect of the tomcat classloader. I find that the ClassLoader-HOWTO is very vague in explaining the exact boundaries of the classloaders...here's why: To make it work: moved commons-beanut

4.1.12-LE ClassLoader Problems

Environment: commons-logging-1.0.2.jar log4j-1.2.6.jar Apache Tomcat/4.1.12-LE-jdk14 Situation: I have my own realm implementation that is stable in Tomcat 4.0.3-LE, and I'm moving up to 4.1.12. In addition, I am also moving all of my codebase to the commons-logging package. After moving

DO NOT REPLY [Bug 7359] - Classloader problems with RMI

gzilla/show_bug.cgi?id=7359 Classloader problems with RMI --- Additional Comments From [EMAIL PROTECTED] 2002-08-29 13:57 --- Hi, Yes, I have also met this problem. The RMI server works fine with other Java applications but not with Tomcat as client to the RMI server. There is a workarou

Re: Logging: more classloader problems.

t;[EMAIL PROTECTED]> > Subject: Logging: more classloader problems. > > > The problem: it won't work if commons-logging.jar is installed in the > parent class loader, and log4j.jar ( or another logger ) is installed in > a child loader ( like WEB-INF/lib ). > > What happens

Re: Logging: more classloader problems.

On Thu, 6 Jun 2002, Geir Magnusson Jr. wrote: > On 6/6/02 2:08 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > > > Solution: > > Split commons-logging.jar in commons-logging-api.jar ( only the API and > > the LogFactoryImpl, no adapteer ) and commons-logging-impl.jar. > > :) If you k

Logging: more classloader problems.

The problem: it won't work if commons-logging.jar is installed in the parent class loader, and log4j.jar ( or another logger ) is installed in a child loader ( like WEB-INF/lib ). What happens: - the factory uses the thread class loader to check if the log4j ( or any other impl. ) exists ( an

Tomcat 4.0.3 ClassLoader problems

Hey guys, I have a question about the classloader... When reading the following message, please keep in the back of your mind that my application does NOT reside in the default webapps directory... I created my own virtual host, with its context in a location like /var/www/mywebapp. I don

DO NOT REPLY [Bug 7359] - Classloader problems with RMI

gzilla/show_bug.cgi?id=7359 Classloader problems with RMI --- Additional Comments From [EMAIL PROTECTED] 2002-03-28 13:48 --- I'm seeing the same problem on W2K with 4.0.3 final. The following happens in an internal Jini thread when trying to establish a link to a newly discovere

DO NOT REPLY [Bug 7359] - Classloader problems with RMI

gzilla/show_bug.cgi?id=7359 Classloader problems with RMI [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Major --- Additional Comment

DO NOT REPLY [Bug 7359] New: - Classloader problems with RMI

gzilla/show_bug.cgi?id=7359 Classloader problems with RMI Summary: Classloader problems with RMI Product: Tomcat 4 Version: 4.0.3 Final Platform: All OS/Version: Linux Status: NEW Severity: Blocker Priority:

Re: Classloader problems. Tomcat won't load Xalan from WEB-INF/lib

On 4 Aug 2001, burtonator wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > OK. > > I running Tomcat under with Xalan under JDK 1.3. I want to have > Tomcat reload all my Xalan extensions when I recompile. > > The only problem is that since the Tomcat core uses Xalan the syste

Classloader problems. Tomcat won't load Xalan from WEB-INF/lib

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK. I running Tomcat under with Xalan under JDK 1.3. I want to have Tomcat reload all my Xalan extensions when I recompile. The only problem is that since the Tomcat core uses Xalan the system classloader is used and therefore when I recompile non