I ran into a similar problem today that I can not explain while upgrading to
tomcat 3.3. The JSP we created accesses a bean that uses the oracle 1.2 JDBC
driver, classes12.zip.

I placed the Oracle classes12.zip file in the myapp/WEB-INF/lib directory
and then I got the NoClassDef exception.

I unjar'd the .zip file in the myapp/WEB-INF/lib directory and still got the
NoClassDef exception.

I unjar'd the .zip file in the myapp/WEB-INF/classes directory and it
worked.

Where should the .zip file be placed for inclusion in a bean? I recycled
Tomcat after every attempt.

> From: "Lauer, Oliver" <[EMAIL PROTECTED]>
> Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Date: Mon, 17 Dec 2001 18:56:34 +0100
> To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
> Subject: AW: Classloader question
> 
> But why wasn't the class found in myapp/WEB-INF/lib ? Sorry, but I don't
> understand that !?
> 
>> AXA eSolutions GmbH
>> AXA Konzern AG Germany
>> Oliver Lauer 
>> Web Architect
>> W�rthstra�e 34
>> D-50668 K�ln
>> Germany
>> Tel.: +49 221 148 31277
>> Fax: +49 221 148 43963
>> Mobil: +49 179 59 064 59
>> e-Mail: [EMAIL PROTECTED]
>> _____________________________
>> 
> 
> 
> -----Urspr�ngliche Nachricht-----
> Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Gesendet: Montag, 17. Dezember 2001 18:50
> An: Tomcat Users List
> Betreff: Re: Classloader question
> 
> 
> 
> 
> On Mon, 17 Dec 2001, Heikki Doeleman wrote:
> 
>> Date: Mon, 17 Dec 2001 13:06:21 +0100
>> From: Heikki Doeleman <[EMAIL PROTECTED]>
>> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
>> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
>> Subject: Classloader question
>> 
>> Hi everyone,
>> 
>> trying to make a web application work using Tomcat 4.0.1 I found the
>> following behaviour, which I don't quite understand:
>> 
>> my application uses a library called xhive.jar
>> 
>> - putting xhive.jar in [catalina]/common/lib
>> This works fine, as expected
>> 
>> 
>> - putting it in [myapp]/WEB-INF/lib
>> Causes a ClassDefNotFoundError. I don't know why this is so, it does not
>> seem to conform to the description in class-loader-howto.html. However I
> did
>> see someone saying that in that directory, only .class files are added to
>> the classpath, not .jars
>> (http://www.geocrawler.com/archives/3/193/2000/12/0/4841079/).
>> 
>> 
>> - putting it in both those places
>> Causes a ClassCastException ?? Something seems to go terribly wrong when
> the
>> jar is placed in both those directories.
>> 
>> Can anyone explain more about this? I'd like to know exactly how this
> works,
>> especially I'd like to know why classes from a jar in my application's
>> WEB-INF/lib apparently are not loaded.
>> 
> 
> This has been discussed numerous times in the archives, but the short
> answer is this:  it is fundamental to the way Java class loaders work.
> The key issues:
> 
> * A class named "a.b.c.Foo" loaded from two different
> class loaders is ***not*** the same class, even if the
> bytecodes are identical.  Trying to assign from one to
> the other will give you ClassCastException errors.
> 
> * The "new" operator in Java tries to load the specified
> class from the same classloader that loaded the class
> containing this code.  If the class of that name has
> already been loaded by the "other" classloader, you
> again get ClassNotFoundException errors.
> 
> * Class loader hierarchies can delegate "up" but not "down".
> Thus, it's also easy to have the "new" operator cause
> ClassNotFoundException errors, even though you "know" that
> the class is there.
> 
> Moral of the story -- you are *always* best off having one and only one
> copy of a class visible to a web application.  There's ways to deal with
> some of these issues, but they get pretty intricate.
> 
>> Thanks
>> Heikki Doeleman
>> 
> 
> Craig McClanahan
> 
> 
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]>
> 
> 
> ------------------------------------------------------------------------------
> Aus Rechts- und Sicherheitsgruenden ist die in dieser E-Mail gegebene
> Information nicht rechtsverbindlich. Eine rechtsverbindliche Bestaetigung
> reichen wir Ihnen gerne auf Anforderung in schriftlicher Form nach. Beachten
> Sie bitte, dass jede Form der unautorisierten Nutzung, Veroeffentlichung,
> Vervielfaeltigung oder Weitergabe des Inhalts dieser E-Mail nicht gestattet
> ist.Diese Nachricht  ist ausschliesslich fuer den bezeichneten Adressaten oder
> dessen Vertreter bestimmt. Sollten Sie nicht der vorgesehene Adressat dieser
> E-Mail oder dessen Vertreter sein, so bitten wir Sie, sich mit dem Absender
> der E-Mail in Verbindung zu setzen.
> ----------------------------
> For legal and security reasons the information provided in this e-mail is not
> legally binding. Upon request we would be pleased to provide you with a
> legally binding confirmation in written form. Any form of unauthorised use,
> publication, reproduction, copying or disclosure of the content of this e-mail
> is not permitted. This message is exclusively for the person addressed or
> their representative. If you are not the intended recipient of this message
> and its contents, please notify the sender immediately.
> 
> ==============================================================================
> 
> 
> --
> 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]>

Reply via email to