Re: Using custom classloader

2014-06-05 Thread Konstantin Kolinko
2014-06-04 19:46 GMT+04:00 Don Asper don.as...@sas.com:
 Hi:  I want my web apps running on Tomcat 7.0.35 to use a custom classloader. 
  The reason is that I want each web app classloader instance to do some 
 processing to set up the classpath for the web app it belongs to.  I have the 
 following questions:  1) Is org.apache.catalina.loader.WebappClassLoader  a 
 good class to derive my custom classloader from?  Is it a good choice going 
 forward for later versions of Tomcat?  2) Is there a recommended way for my 
 custom classloader to identify which web app it belongs to?  It needs to 
 identify which web app it is for so that it will know what jars to put on its 
 classpath.  Thanks!

Look at VirtualWebappLoader. Maybe it suits your needs as is.

Also the same trick that it does can be performed from a Listener.
There is no need to extend WebappLoader just for that.

A Listener and a WebappLoader have access to Tomcat's Context class
and can get the paths.

The VirtualWebappLoader is not available in Tomcat 8, replaced by new
Pre/Post/... resources APIs.

Beware that webapp's classloader should be able to produce class path
that is used by JSP compiler (Eclipse JCP or by external javac
depending on how your Tomcat is configured). Tomcat WebappClassLoader
has API for that.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Using custom classloader

2014-06-04 Thread Don Asper
Hi:  I want my web apps running on Tomcat 7.0.35 to use a custom classloader.  
The reason is that I want each web app classloader instance to do some 
processing to set up the classpath for the web app it belongs to.  I have the 
following questions:  1) Is org.apache.catalina.loader.WebappClassLoader  a 
good class to derive my custom classloader from?  Is it a good choice going 
forward for later versions of Tomcat?  2) Is there a recommended way for my 
custom classloader to identify which web app it belongs to?  It needs to 
identify which web app it is for so that it will know what jars to put on its 
classpath.  Thanks!


Re: Using custom classloader

2014-06-04 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Don,

On 6/4/14, 11:46 AM, Don Asper wrote:
 Hi:  I want my web apps running on Tomcat 7.0.35 to use a custom 
 classloader.  The reason is that I want each web app classloader 
 instance to do some processing to set up the classpath for the web
  app it belongs to.

Can you be more specific? Perhaps you don't actually need to write a new
ClassLoader... you may be able to configure the existing ClassLoader to
behave the way you want, or possibly use a non-ClassLoader-related
solution.

 I have the following questions:  1) Is 
 org.apache.catalina.loader.WebappClassLoader  a good class to
 derive my custom classloader from?

Yes.

 Is it a good choice going forward for later versions of Tomcat?

Probably. I don't think that class (name) has changed significantly in a
very long time. If you hook-into the constructor or lifecycle methods
you should be good. Remember: always test with new versions :)

 2) Is there a recommended way for my custom classloader to identify
  which web app it belongs to? It needs to identify which web app it
 is for so that it will know what jars to put on its classpath.

If you are using WebapClassLoader as your parent, you can call
super.getContextName(), but that will just get you the name of the
context, not the location of the deployment artifact. What information
do you actually need?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTj7f0AAoJEBzwKT+lPKRYG3AP/3gJCphgLXN8hZvojSz760CO
JRzw+YR3qubhFPH+K2diwveA4tLwIpmL7rMiCljXIVZz+q5illbYtrMR6Ou9nCmt
k7L9R2rjX5Fyr+Eew4qevXQHL+0V0MbVsuRd9Gs9D4LVvMgNpOb1ArhIkweZEi2A
67GTPKENU+o29yJrxXU/19EMbyItu6O/w26boPeX6+7MQXfvSycSeJZdytNA3Sws
psiEf+5/5th2jppDB2aoS/lpZbAoODLUPkeOryGZPjAL5KFCqVAUvhtV/CmfHqKw
VSbaa6XCvhFlijXETArWiSgjdaWm5dBEWK+XdKhAV9PWt10zBHeL4+vXdsan3K6Z
3tXy9ceMTeHC9oXAJDOcdXIjiL8wIJlPOH0P05/cbnMaGL2ItKu1H+V6y9NqvKXw
hr07SypVdWzjez+1s3u0Uv7hzyoRXVtfbA5vpCAOgo0jL04bLLfzlJ/JE+yZwdk1
Y37XBxRWvRpUfeax0+U/q5X+8Io3bBHwBzUW9JPJnQE1iLxej/H4Db1Fp+kXnVaz
GtwLYEAechGXgAnZF+0msocTdLb7OjecCcKmVDmwHayUqHPAQNrh0Bn2vaw4EWef
HkV6XH3Rt3bcvgw+CUQoiDa+k02BTtBOCLRlCCYc6L8MTL9wh2uVUWIrijBNMTjn
jETFSqYlIC2H6O5mGiJ2
=Lc35
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Embedded Tomcat stops deploying WARs when using custom ClassLoader

2006-04-14 Thread Andrew McDowall
It would appear that my problem was solved by simply changing the line
'new Catalina();' to 'new Embedded();', so now it unpacks.

-Original Message-
From: Andrew McDowall [mailto:[EMAIL PROTECTED] 
Sent: 13 April 2006 16:56
To: users@tomcat.apache.org
Subject: Embedded Tomcat stops deploying WARs when using custom
ClassLoader

Hi,

I am currently working on a fairly complex system which provides a means
to incorporate 'pluggable' functionality using an embedded Tomcat -
essentially it allows WARs to be dropped into a specific directory, the
embedded Tomcat then unpacks and deploys the WAR.

This has been working without any problems up until a few days ago when
I started incorporating our own proprietary ClassLoader into the system.
The rationale behind the ClassLoader is that I need to provide a degree
of separation between certain sub-components of the system while still
providing common shared libraries for all components - much like the
ClassLoading solution provided by Catalina.  My own ClassLoader now
allows me to navigate a tree of child ClassLoaders in an order different
to that of the standard Java delegation model ie: in my solution I wish
to perform a depth-first search rather than simply being limited to one
branch. 

The solution implemented is working (give or take a few minor flaws)
except for now the embedded Tomcat no longer deploys WARs.  At first I
believed this to be an issue with the ContextClassLoader for the Thread
in which the embedded Tomcat runs, but after investigation I am not so
sure.  It should be noted that the embedded Tomcat itself does not
produce any errors so I am at a loss to understand exactly why it has
stopped working, it's as if it is failing silently.  None of the
configuration for Tomcat has changed between the versions using the
System ClassLoader and the new version using the new custom ClassLoader.

I would be very grateful for any help with this problem, thanks in
advance.

 

Andy McDowall



--- Disclaimer ---

Unless otherwise agreed expressly in writing by a Director of Edina
Software, this communication is to be treated as confidential and the
information in it may not be used or disclosed except for the purpose
for which it has been sent. If you have reason to believe that you are
not the intended recipient of this communication, please contact the
sender immediately. 

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__


--- Disclaimer ---

Unless otherwise agreed expressly in writing by a Director of Edina Software, 
this communication is to be treated as confidential and the information in it 
may not be used or disclosed except for the purpose for which it has been sent. 
If you have reason to believe that you are not the intended recipient of this 
communication, please contact the sender immediately. 

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Embedded Tomcat stops deploying WARs when using custom ClassLoader

2006-04-13 Thread Andrew McDowall
Hi,

I am currently working on a fairly complex system which provides a means
to incorporate 'pluggable' functionality using an embedded Tomcat -
essentially it allows WARs to be dropped into a specific directory, the
embedded Tomcat then unpacks and deploys the WAR.

This has been working without any problems up until a few days ago when
I started incorporating our own proprietary ClassLoader into the system.
The rationale behind the ClassLoader is that I need to provide a degree
of separation between certain sub-components of the system while still
providing common shared libraries for all components - much like the
ClassLoading solution provided by Catalina.  My own ClassLoader now
allows me to navigate a tree of child ClassLoaders in an order different
to that of the standard Java delegation model ie: in my solution I wish
to perform a depth-first search rather than simply being limited to one
branch. 

The solution implemented is working (give or take a few minor flaws)
except for now the embedded Tomcat no longer deploys WARs.  At first I
believed this to be an issue with the ContextClassLoader for the Thread
in which the embedded Tomcat runs, but after investigation I am not so
sure.  It should be noted that the embedded Tomcat itself does not
produce any errors so I am at a loss to understand exactly why it has
stopped working, it's as if it is failing silently.  None of the
configuration for Tomcat has changed between the versions using the
System ClassLoader and the new version using the new custom ClassLoader.

I would be very grateful for any help with this problem, thanks in
advance.

 

Andy McDowall



--- Disclaimer ---

Unless otherwise agreed expressly in writing by a Director of Edina Software, 
this communication is to be treated as confidential and the information in it 
may not be used or disclosed except for the purpose for which it has been sent. 
If you have reason to believe that you are not the intended recipient of this 
communication, please contact the sender immediately. 

__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__