You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "VARIN, FRANCIS A." <FV...@AMICA.com> on 2006/03/23 21:33:23 UTC
Classloader question
A little background:
We are currently in the process of developing an application that will
be managed by Tomcat. We have several Java EE applications that have
been running with WebSphere for approximately 5 years. Those
applications include some classes that form a home grown application
framework that we wish to reuse as part of the new application targeted
for Tomcat.
The question/issue:
One of the classes that we would like to reuse resides in a jar file
that is contained at the shared jars folder within Tomcat and has the
capability using reflection to perform a "factory" behavior and
instantiate various classes based on their fully qualified name.
When this "factory" needs to instantiate a class that resides in the
shared jars folder it works great. However, when the class to be
instantiated resides below that, i.e. an application it is subject to
the rules of delegation in the classloader hierarchy, and fails trying
to instantiate the class.
As mentioned above, we have used this class for several years in WAS. In
that case, the jar that contains the factory resides at the EAR level
and can instantiate classes that live in the associated WAR files just
fine. The problem only exists in Tomcat.
Admittedly, we are new to using Tomcat and are looking to see if there
is a way where we might configure Tomcat's behavior to mimic that of an
app. server like WebSphere?
Francis A. Varin, M.S.
IT Architect II
Corporate Information Systems
Amica Mutual Insurance Company
1-800-652-6422 ext. 24536
http://www.amica.com <http://www.amica.com/>
-----------------------------------------
**********************************************************
This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify
postmaster@amica.com
and the sender of the message. Thank you.
**********************************************************
Re: Classloader question
Posted by Fran Varin <FV...@AMICA.com>.
I tend to agree with your postion. I'm not sure that Tomcat will see the
native Windows shortcut. I'll see if we can figure out how to do it. If you
have any ideas I'm all ears.
It sure would be nice if Tomcat had the ability to have the shared lib see
down the hierarchy or be able to put jars 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 the Tomcat - User forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Mike Sabroff <mi...@cygnusb2b.com>.
I run cygwin (a linux like application/environment) on my windows box at
home. When I create a symbolic link in that system and look at it frm
the windows side of it, it IS a shortcut.
try it....I think it may work, but I am not sure that tomcat will see it
as cygwin does. Curious.....
Fran 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Mike Sabroff
Web Services
Developer
mike.sabroff@cygnusb2b.com
920-568-8379
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Fran Varin <FV...@AMICA.com>.
...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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Mike Sabroff <mi...@cygnusb2b.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 at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Mike Sabroff
Web Services
Developer
mike.sabroff@cygnusb2b.com
920-568-8379
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Fran Varin <FV...@AMICA.com>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Boris Unckel <bo...@gmx.net>.
Hi,
> Von: Fran Varin <FV...@AMICA.com>
> 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 /opt/libs/java/shared/myjar.jar myjar.jar run in WEB-INF/lib
Again: consider that after each deployment the link has to be set again.
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Fran Varin <FV...@AMICA.com>.
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.
--
View this message in context: http://www.nabble.com/Classloader-question-t1332679.html#a3573086
Sent from the Tomcat - User forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Boris Unckel <bo...@gmx.net>.
Hello Dave,
> Von: David Kerber <dc...@verizon.net>
> 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 far as I know this is possible with WebSphere where you have a concept
for shared libraries (not only a shared classpath) but not with Tomcat.
You can imagine them as symbolic links: You declare them once and tell
WebSphere which applications uses them.
For Tomcat it would be possible to have them once in the filesystem and
symbolic link them into WEB-INF/lib. This should be scripted in the
deployment to avoid tomcat deleting the symbolic links.
I would consider this as a workaround... It is not so nice as simply putting
them as shared library or shared classpath and reduces the ease of
maintenance again.
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by David Kerber <dc...@verizon.net>.
Boris Unckel wrote:
...
>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 do you
>prefer - the single point of change in shared or the isolated point of view
>with WEB-INF/lib?
>
>Regards
>Boris
>
>
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?
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by David Smith <dn...@cornell.edu>.
Boris Unckel wrote:
>Hello,
>
>
>>Von: Fran Varin <FV...@AMICA.com>
>>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 by more than one applicaiton (WAR) be
>>copied into each applicaiton.
>>
>>
>You are following the wrong approach in my oppinion. The goal of the
>Classloaders is to have every application as independent as possible and to
>offer an isolated context where possible.
>The pro side of the shared classloader is to have the chance to have a
>single point of change for the JARs for all applications. I understand the
>approach but I (and I think others at the list too) think it is the wrong
>approach because it has disadvantages for static variables, logging etc.
>
>
>
>>We would like to have them in one place
>>where they can be accessed by all applicaitons. We've achieved this
>>somewhat by placing the jar in the shared jars folder. However, the
>>delegation model prohibits instantiating classes that belong to an
>>application from any entity 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?
>>
>>
>Best practise (not only for Tomcat) is elimante the need for shareds jars.
>
>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 do you
>prefer - the single point of change in shared or the isolated point of view
>with WEB-INF/lib?
>
>Regards
>Boris
>
>
>
>
IMHO, the better approach is to manage common classes and jars in the
build or source repository system rather than the servlet container.
Versioning gets easier as refactoring is no longer an all or nothing
project. Plus the individual webapps no longer need to even be on the
same server and can be moved with a minimum of dependency issues.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Boris Unckel <bo...@gmx.net>.
Hello,
> Von: Fran Varin <FV...@AMICA.com>
> 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 by more than one applicaiton (WAR) be
> copied into each applicaiton.
You are following the wrong approach in my oppinion. The goal of the
Classloaders is to have every application as independent as possible and to
offer an isolated context where possible.
The pro side of the shared classloader is to have the chance to have a
single point of change for the JARs for all applications. I understand the
approach but I (and I think others at the list too) think it is the wrong
approach because it has disadvantages for static variables, logging etc.
> We would like to have them in one place
> where they can be accessed by all applicaitons. We've achieved this
> somewhat by placing the jar in the shared jars folder. However, the
> delegation model prohibits instantiating classes that belong to an
> application from any entity 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?
Best practise (not only for Tomcat) is elimante the need for shareds jars.
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 do you
prefer - the single point of change in shared or the isolated point of view
with WEB-INF/lib?
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Fran Varin <FV...@AMICA.com>.
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 by more than one applicaiton (WAR) be copied
into each applicaiton. We would like to have them in one place where they
can be accessed by all applicaitons. We've achieved this somewhat by placing
the jar in the shared jars folder. However, the delegation model prohibits
instantiating classes that belong to an application from any entity 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 the Tomcat - User forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Boris Unckel <bo...@gmx.net>.
Hello Francis,
VARIN, FRANCIS A. wrote:
>
> As mentioned above, we have used this class for several years in WAS.
> In that case, the jar that contains the factory resides at the EAR
> level and can instantiate classes that live in the associated WAR
> files just fine. The problem only exists in Tomcat.
>
>
>
> Admittedly, we are new to using Tomcat and are looking to see if there
> is a way where we might configure Tomcat's behavior to mimic that of
> an app. server like WebSphere?
>
I have no experience with WebSphere below 5.0, but I know about 5.0, 5.1
and 6.0. I assume that you were using a ClassLoader policy in WebSphere
"Application",
so EAR and WAR shared the same classloader.
If you want to check this out try the following in one of the WAR classes:
ClassLoader current = Thread.currentThread().getContextClassloader();
System.out.println(current.toString());
ClassLoader parent current.getParentClassLoader();
System.out.println(parent.toString());
You will see the full classpath of the application, the policy.
Summary: WebSphere does not provide a feature to load childLoader
classes. You simply did not have a child Classloader but one single
classloader for EAR and WAR instead.
Regards
Boris
Re: Classloader question
Posted by Boris Unckel <bo...@gmx.net>.
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 a lot of sense. We do use
> ANT for our builds and such but, the point is to try and simplify the
> implementation as much as possible.
There are two points: HotDeploy is something most useful in development
and test environments. For
a production environment it may make sense but is not so important.
Before you are looking for a solution to reduce the points of change for
jar consider:
- the shared code (jar) is made and tested for use in shared use
- there is no third party code used by the homegrown shared code were
you just consider it to be made for shared use,
but you do not know it, and it is not a feature guaranteed by the
producer of the third party lib.
- it is _really_ a headache for you to use ant for deployment in the
test environment and keep control of the jars used by more than
one application.
- you are _sure_ that the time saved by sharing one or more jar(s) by
all applications is not consumed by looking for errors caused by
sharing the jar(s)
Have a look at:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak
Chapter: Keep component libs in components
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Fran Varin <FV...@AMICA.com>.
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 a lot of sense. We do use
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Classloader question
Posted by Reinhard Moosauer <rm...@moosauer.de>.
Hi,
this sounds like "repackage" would be a huge job.
If yes, I would suggest: learn ant
If not: You have to reload the apps anyway. So what do you achieve?
just my 2 cents.
R.
Am Freitag, 24. März 2006 16:19 schrieb Fran Varin:
> Yes, that is the exact situation we are attempting to avoid in Tomcat. In
> our WSA implementation we can simply replace the effected JARS in one
> location and it is implemented against all WARs running in that server's
> context. In the illustration you provided below we would need to repackage,
> or at the very least, redistribute the "shared" jar files that have 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-question-t1332679.html#a3573057 Sent from
> the Tomcat - User forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Classloader question
Posted by Fran Varin <FV...@AMICA.com>.
Yes, that is the exact situation we are attempting to avoid in Tomcat. In our
WSA implementation we can simply replace the effected JARS in one location
and it is implemented against all WARs running in that server's context. In
the illustration you provided below we would need to repackage, or at the
very least, redistribute the "shared" jar files that have 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-question-t1332679.html#a3573057
Sent from the Tomcat - User forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org