what I dont like about the "copying to jre/lib/ext" variant is that it
reminds me alot of the winnt/system32 phenomenon. And I remember well how an
application which made use of xerces always choked with a NoSuchMethodError
(or similar), until I tracked down the problem to an outdated xml parser
which I had copied to jre/lib/ext a while ago and forgotten about it.
And as far as the provider jars go, the problem goes even further, because
they are not all part of the standard. For example, several applications may
rely on provider implementations with different features (e.g. poppers.jar
vs. pop3.jar). Sounds like a nice little mess to me.
Ok, enough ranting - for now we will have to live with it the way it is, and
at least I have my application running. Thanks for all your sympathy.
-----Original Message-----
From: Russ White <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Date: Mittwoch, 1. November 2000 17:42
Subject: RE: accessing javamail provider
>Christian,
>
>If you read the JavaMail API docs you saw that putting all of the JavaMail
API
>jars in jre/lib/ext is the prescribed method for deploying the API. This
include
>mail.jar, activation.jar, and any providers custom or otherwise. At first I
did
>not like that much, but it is an extension API, so it does make some sense,
and
>after using for the last year plus I understand why.
>
>The reason the other jar files have to be in the /ext dir when you try to
put a
>provider in the /ext is because the classes in the jar files in the /ext
>directory are dynamically loaded every time you fire up an instance of the
vm.
>Naturally when a class is loaded if it can not find classes that it depends
on
>it will break. This is what was happening to you. The JVM does not know
anything
>about the stuff in the Orion classpath, so it needs the dependent classes
in the
>form of jar files in the ext directory.
>
>I have taken to deploying the JavaMail API the prescribed way as it is easy
to
>remember, and it also makes updating providers easy as you only do it in
one
>place. It is possible to use the API without installing it as an extension
>(Orion does it for portability), but I would not recommend it.
>
>Russ
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]On Behalf Of Christian Sell
>> Sent: Wednesday, November 01, 2000 7:27 AM
>> To: Orion-Interest
>> Subject: Re: accessing javamail provider
>>
>>
>> thanks alot for your mail. The only solution really seems to be to either
>> put everything in jre/lib/ext or to specify all jars at server startup
via
>> the command line.
>>
>> However, I find that when placing pop3.jar in the jre/lib/ext directory,
I
>> also have to put mail.jar and activation.jar there (even though they
reside
>> in the orion install dir). I finally ended up modifying the manifest
file...
>>
>> I think this library business is a pretty annoying problem, especially
>> considering the time spent to figure out whats going on..
>>
>> -----Original Message-----
>> From: Terence Kwan <[EMAIL PROTECTED]>
>> To: Orion-Interest <[EMAIL PROTECTED]>
>> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Mittwoch, 1. November 2000 09:20
>> Subject: RE: accessing javamail provider
>>
>>
>> See enclosed mail
>>
>> > -----Original Message-----
>> > From: [EMAIL PROTECTED]
>> > [mailto:[EMAIL PROTECTED]]On Behalf Of Christian
Sell
>> > Sent: Monday, October 30, 2000 5:04 PM
>> > To: Orion-Interest
>> > Subject: accessing javamail provider
>> >
>> >
>> > Hello,
>> >
>> > I've posted this before on orion-interest:
>> >
>> > I am using JavaMail to access a pop3 mailbox. No matter where I place
the
>> > pop3.jar file (from sun, or poppers.jar) in the system, I always get a
>> > NoSuchProviderException saying thath no pop3 provider was
>> > available. I have
>> > tried the following locations for the pop3.jar:
>> >
>> > <orion-install>,
>> > <orion-install>/lib
>> > WEB-INF/lib
>> > any other path referenced through <library path=> in
orion-application.xml
>> >
>> > The problem happens even though I am able to load classes from the jar
via
>> > Class.forName().
>> >
>> > To verify this problem further, I deployed the same application
>> > on JRun 3.0.
>> > With JRun, I have to place the jar file in <jrun-install>/lib/ext
>> > (actually
>> > thats where the one that comes with JRun is located), and everything
works
>> > fine.
>> >
>> > thanks,
>> > Christian Sell
>> >
>> >
>> >
>>
>>
>>
>
>
