Hi,
I'm working with Tomcat 4.1.
I have a library that has to be shared between all the applications,
but it has singletons that should have one instance per application.
In a normal situation, each application could have the .jar in it's
WEB-INF/lib directory, but there is a requirement saying
Hi,
I'm working with Tomcat 4.1.
I have a library that has to be shared between all the applications,
but it has singletons that should have one instance per application.
In a normal situation, each application could have the .jar in it's
WEB-INF/lib directory, but there is a requirement saying
change it to use catalina.home
instead of catalina.base, or add an additional path.
Cheers,
Larry
-Original Message-
From: Fran Varin [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 12:49 PM
To: users@tomcat.apache.org
Subject: Classloader Question
We are running
this message in context:
http://www.nabble.com/Classloader-Question-tf2417987.html#a6740606
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e
Canada
615 Booth St. Room 650
Ottawa, Ontario
K1A0E9
Phone: 613-947-0463
E-mail : [EMAIL PROTECTED]
-Original Message-
From: Fran Varin [mailto:[EMAIL PROTECTED]
Sent: October 10, 2006 12:49 PM
To: users@tomcat.apache.org
Subject: Classloader Question
We are running multiple Tomcat
-
From: King, Patrick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 10:32 AM
To: Tomcat Users List
Subject: RE: Classloader Question
A possible solution would be to use the analog of a unix file link for
windows based operating systems. One tomcat distribution would have the
actual
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 10, 2006 12:49 PM
To: users@tomcat.apache.org
Subject: Classloader Question
We are running multiple Tomcat 5.5 instances as Windows
services. We have some .jar files that are common between the
multiple Tomcat instances. We have been searching
with the intent of
sharing them with multiple running instances of Tomcat and each one's
associated application?
--
View this message in context:
http://www.nabble.com/Classloader-Question-tf2417987.html#a6743489
Sent from the Tomcat - User mailing list archive at Nabble.com
in the
shared jars folder.
If Tomcat does not have a similar facility as mentioned regarding WebSphere,
what is considered to be the best practices approach as far as Tomcat is
concerned?
--
View this message in context:
http://www.nabble.com/Classloader-question-t1332679.html#a3570566
Sent from
Hello,
Von: Fran Varin [EMAIL PROTECTED]
Yes, quite correct on your statement regarding using Application as the
definition. The essence of what we are looking for is a similar behavior
with Tomcat. Our over arching goal is to minimize or eliminate the need
to have jars that are to be shared
Hello Dave,
Von: David Kerber [EMAIL PROTECTED]
I understand the arguments on both sides, but tend to prefer the ease of
maintenance of what you call the single point of change in
shared/lib. Is it possible to make this configurable, so both sides
can be happy? Or is that too complex?
As
From: Boris Unckel [mailto:[EMAIL PROTECTED]
Subject: Re: Classloader question
To the mailing-list: If you have an library which has not
the explicit recommendation to put it in common/shared lib
path (i.E. a special JDBC driver where the vendor recommends
one to put it into shared) what
Boris Unckel wrote:
Hello,
Von: Fran Varin [EMAIL PROTECTED]
Yes, quite correct on your statement regarding using Application as the
definition. The essence of what we are looking for is a similar behavior
with Tomcat. Our over arching goal is to minimize or eliminate the need
to have jars
Hi,
Von: Fran Varin [EMAIL PROTECTED]
This approach sounds promising...would you mind elaborating just a little
on
what you're thinking? I'm not sure I follow when you mention using a
symbolic link into WEB-INF/lib.
it would require UNIX or LINUX system. A simple symbolic link:
ln -s
aah...now I understand the reason it sounded foreign to me. We are a Windows
shop so, I'm not sure we have the same capability.
--
View this message in context:
http://www.nabble.com/Classloader-question-t1332679.html#a3573581
Sent from the Tomcat - User forum at Nabble.com
SHORTCUT!
Fran Varin wrote:
aah...now I understand the reason it sounded foreign to me. We are a Windows
shop so, I'm not sure we have the same capability.
--
View this message in context:
http://www.nabble.com/Classloader-question-t1332679.html#a3573581
Sent from the Tomcat - User forum
...as in Windows shortcut...I'll have to look into that possibility.
--
View this message in context:
http://www.nabble.com/Classloader-question-t1332679.html#a3573968
Sent from the Tomcat - User forum at Nabble.com
Varin wrote:
...as in Windows shortcut...I'll have to look into that possibility.
--
View this message in context:
http://www.nabble.com/Classloader-question-t1332679.html#a3573968
Sent from the Tomcat - User forum at Nabble.com
somewhere where all the apps could
have access in the manner I've described. There is a good reason why app
servers like WAS allow this...it makes maintenance and deployment much
easier.
--
View this message in context:
http://www.nabble.com/Classloader-question-t1332679.html#a3575029
Sent from
changes
to each WAR. In our situation, we would not be distributing the WARs across
running server instances...the application is self-contained and runs as a
unit anyway. It's packaged software that requires customization.
--
View this message in context:
http://www.nabble.com/Classloader
ANT for our builds and such but, the point is to try and simplify the
implementation as much as possible.
--
View this message in context:
http://www.nabble.com/Classloader-question-t1332679.html#a3576644
Sent from the Tomcat - User forum at Nabble.com
Hello,
Fran Varin wrote:
The beauty of our WAS solution is that we can hot deploy various pieces like
the jars without having to do anything with the WARs and since we do not
have the jars contained in each WAR it makes maintenance much simpler.
Depending on the application, this approach makes
22 matches
Mail list logo