Re: [OT] classloader issue with bouncycastle

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 10/26/17 3:58 PM, Chris Cheshire wrote:
> On Thu, Oct 26, 2017 at 9:42 AM, Christopher Schultz 
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Chris,
>> 
>> Just curious... why are you using BC and not the JVM-provided
>> crypto provider? What JVM are you using?
>> 
> 
> When I first starting looking for examples on doing PGP encryption
> in Java, all I found were (albeit obsolete) guides to doing it with
> BC.

Say no more: AFAIK, PGP is not supported directly by any JVM, so use
of BC is pretty much required (unless you want to use one of those
wrapper-libraries that just spawns separate processes to call the
command-line tools).

> JVM is OpenJDK 1.8. I first started fiddling with this using 1.6.

Let us know if you find anything more convenient than using BC.
Everything we do with PGP is done through non-Java tools, and I'd like
to be able to use Java if possible.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln3NwcACgkQHPApP6U8
pFgsnQ//dsWktkaQXxVlRqyK0U36MAXz2Kca2BnB3Lk85oMCZh/7zquFadd8adLV
iNXtuaKFWQBbK+9LDaG/crHbCzuHs9jliK51r09u6LVG3m13FRcN8WsU3aOunaSh
Xl3L9kxL9eUfWMgd11eClT7/LziQSuVafsFze4lfN/60ka1K9GQtKX3ClKfd5pgN
wTm0qL5OHvkojw4fLshI74hh7MrYWbEAVSIh8o+NKEBkshlDOI3v3x72thIfeIWS
2aZb9y/nnAYYqMXsldz/aUMEapQV7ZY/4v+bZzOj1pbLk+HR7/ajnGY20dCB8W7M
NqjA4pzHYMfYNTdEONEmPf6Nb84PTEK34YjzihBBj0AOYdA29hklrdTMftaPN97o
uSNDJTzfy2vLbG7f81SKSGUXBg8nad+PG6xTG2b1nvXhuwkDe7gT0rpDxxGM9v2R
AVBr2VIbSRbvraUrYJpYcsuYevNEXttwu79R/KKcUEC2xM+21ST07V+GToaCMKCS
2IcFOu04g+dQny/X+GYlh7F32g69eriKqROdIDpIDvNoXwfcecg7GbiQjqBvnqyg
DGe9sHWAjERdNcdiMeOT+xbhbjEnouljw+SoicWftXkIWGZE5ZgAWXJAtGKUywfV
et/dLvbg6u4vT4SxzhZ56nd9yf5WN3GH1fbBe/yaRWTbNOgEd5w=
=dJEu
-END PGP SIGNATURE-

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

Re: [OT] classloader issue with bouncycastle

[Chris Cheshire]

On Thu, Oct 26, 2017 at 9:42 AM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris,
>
> Just curious... why are you using BC and not the JVM-provided crypto
> provider? What JVM are you using?
>

When I first starting looking for examples on doing PGP encryption in
Java, all I found
were (albeit obsolete) guides to doing it with BC.

JVM is OpenJDK 1.8. I first started fiddling with this using 1.6.

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

Re: [OT] classloader issue with bouncycastle

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

Just curious... why are you using BC and not the JVM-provided crypto
provider? What JVM are you using?

- -chris

On 10/18/17 10:56 AM, Chris Cheshire wrote:
> Using bouncy castle v1.58, Tomcat 8.5, java 1.8.
> 
> I have the unlimited security policy files installed, the BC jars
> in my WEB-INF/lib directory and in order to register the BC
> provider, I do
> 
> static { Security.addProvider(new BouncyCastleProvider()); }
> 
> in a utility class that handles the keyring 
> setup/encryption/decryption methods for me. This works great until
> I update the jar that contains my utility class and reload the
> webapp. Then I get an exception thrown from it being unable to
> locate the BC provider.
> 
> mypackage.crypto.CryptoException: 
> org.bouncycastle.openpgp.PGPException: exception on setup: 
> java.security.NoSuchAlgorithmException: class configured for 
> MessageDigest (provider: BC) cannot be found. at
> mypackage.crypto.PGPUtils.decrypt(PGPUtils.java:304)
> ~[mypackage.jar:na] at
> mypackage.web.action.user.priv.settings.View.view(View.java:139) 
> ~[classes/:na] at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[na:1.8.0_141] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
ava:62)
>
> 
~[na:1.8.0_141]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orImpl.java:43)
>
> 
~[na:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498)
> ~[na:1.8.0_141] at
> net.sourceforge.stripes.controller.DispatcherHelper$6.intercept(Dispat
cherHelper.java:456)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionC
ontext.java:176)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> mypackage.web.interceptors.AuthenticateInterceptor.intercept(Authentic
ateInterceptor.java:41)
>
> 
[classes/:na]
> at
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionC
ontext.java:173)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.interc
ept(BeforeAfterMethodInterceptor.java:113)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionC
ontext.java:173)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionCont
ext.java:86)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DispatcherHelper.invokeEventHandler
(DispatcherHelper.java:454)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DispatcherServlet.invokeEventHandle
r(DispatcherServlet.java:278)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DispatcherServlet.service(Dispatche
rServlet.java:160)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) 
> [servlet-api.jar:na] at
> net.sourceforge.stripes.controller.DynamicMappingFilter$2.doFilter(Dyn
amicMappingFilter.java:464)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilte
r.java:260)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> net.sourceforge.stripes.controller.DynamicMappingFilter.doFilter(Dynam
icMappingFilter.java:451)
>
> 
[stripes-1.6.0.jar:1.6.0]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:166)
>
> 
[catalina.jar:8.5.23]
> at
> org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.ja
va:176)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145
)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewrit
er.java:92)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewrite
Filter.java:394)
>
> 
[urlrewritefilter-4.0.3.jar:4.0.3]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:166)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCha
racterEncodingFilter.java:108)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 
[catalina.jar:8.5.23]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
lterChain.java:166)
>
> 
[catalina.jar:8.5.23]
> at
> ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCI
nsertingServletFilter.java:51)
>
> 
[logback-classic-1.0.9.jar:na]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
cationFilterChain.java:193)
>
> 

Re: classloader issue with bouncycastle

[Chris Cheshire]

On Wed, Oct 18, 2017 at 11:31 AM, Konstantin Kolinko
 wrote:
> 2017-10-18 17:56 GMT+03:00 Chris Cheshire :
>> Using bouncy castle v1.58, Tomcat 8.5, java 1.8.
>>
>> I have the unlimited security policy files installed, the BC jars in
>> my WEB-INF/lib directory and in order to register the BC provider, I
>> do
>>
>> static {
>> Security.addProvider(new BouncyCastleProvider());
>> }
>>
>> in a utility class that handles the keyring
>> setup/encryption/decryption methods for me. This works great until I
>> update the jar that contains my utility class and reload the webapp.
>> Then I get an exception thrown from it being unable to locate the BC
>> provider.
>>
>> mypackage.crypto.CryptoException:
>> org.bouncycastle.openpgp.PGPException: exception on setup:
>> java.security.NoSuchAlgorithmException: class configured for
>> MessageDigest (provider: BC) cannot be found.
>> [...]
>> Caused by: java.lang.ClassNotFoundException: Illegal access: this web
>> application instance has been stopped already.
>
>
>> If I move the call
>>
>> Security.addProvider(new BouncyCastleProvider())
>>
>> into the contextInitialized() method of a ServletContextListener,
>> everything works on reloading a webapp, no matter what classes or jars
>> I update.
>>
>> Can someone explain why the static initializer breaks down here please?
>
>
> The "Illegal access: this web application instance has been stopped
> already." exception is the expected behaviour.
>
> Please see "Memory Leaks" presentation (2010) by markt here:
> http://tomcat.apache.org/presentations.html
>
> and
> http://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html
>

Ahhh this explains it somewhat. I was wondering why I was seeing
"application already stopped" errors when the application was clearly
still running. This error is actually referring to the classloader
instance before the reload?

>
> (Maybe moving the BC.jar and its dependencies to ${catalina.home}/lib
> is sufficient to fix your issue. A more robust solution is to move the
> initialization code as well to some listener configured in
> server.xml).
>

Assuming you mean web.xml here using a ServletContextListener? This is
what I have changed to already. Should I also be doing a
Security.removeProvider() in the contextDestroyed() method of the
listener?

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

Re: classloader issue with bouncycastle

[Konstantin Kolinko]

2017-10-18 17:56 GMT+03:00 Chris Cheshire :
> Using bouncy castle v1.58, Tomcat 8.5, java 1.8.
>
> I have the unlimited security policy files installed, the BC jars in
> my WEB-INF/lib directory and in order to register the BC provider, I
> do
>
> static {
> Security.addProvider(new BouncyCastleProvider());
> }
>
> in a utility class that handles the keyring
> setup/encryption/decryption methods for me. This works great until I
> update the jar that contains my utility class and reload the webapp.
> Then I get an exception thrown from it being unable to locate the BC
> provider.
>
> mypackage.crypto.CryptoException:
> org.bouncycastle.openpgp.PGPException: exception on setup:
> java.security.NoSuchAlgorithmException: class configured for
> MessageDigest (provider: BC) cannot be found.
> [...]
> Caused by: java.lang.ClassNotFoundException: Illegal access: this web
> application instance has been stopped already.


> If I move the call
>
> Security.addProvider(new BouncyCastleProvider())
>
> into the contextInitialized() method of a ServletContextListener,
> everything works on reloading a webapp, no matter what classes or jars
> I update.
>
> Can someone explain why the static initializer breaks down here please?


The "Illegal access: this web application instance has been stopped
already." exception is the expected behaviour.

Please see "Memory Leaks" presentation (2010) by markt here:
http://tomcat.apache.org/presentations.html

and
http://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html


(Maybe moving the BC.jar and its dependencies to ${catalina.home}/lib
is sufficient to fix your issue. A more robust solution is to move the
initialization code as well to some listener configured in
server.xml).

Best regards,
Konstantin Kolinko

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

classloader issue with bouncycastle

[Chris Cheshire]

Using bouncy castle v1.58, Tomcat 8.5, java 1.8.

I have the unlimited security policy files installed, the BC jars in
my WEB-INF/lib directory and in order to register the BC provider, I
do

static {
Security.addProvider(new BouncyCastleProvider());
}

in a utility class that handles the keyring
setup/encryption/decryption methods for me. This works great until I
update the jar that contains my utility class and reload the webapp.
Then I get an exception thrown from it being unable to locate the BC
provider.

mypackage.crypto.CryptoException:
org.bouncycastle.openpgp.PGPException: exception on setup:
java.security.NoSuchAlgorithmException: class configured for
MessageDigest (provider: BC) cannot be found.
at mypackage.crypto.PGPUtils.decrypt(PGPUtils.java:304) ~[mypackage.jar:na]
at mypackage.web.action.user.priv.settings.View.view(View.java:139)
~[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.8.0_141]
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[na:1.8.0_141]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.8.0_141]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_141]
at 
net.sourceforge.stripes.controller.DispatcherHelper$6.intercept(DispatcherHelper.java:456)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:176)
[stripes-1.6.0.jar:1.6.0]
at 
mypackage.web.interceptors.AuthenticateInterceptor.intercept(AuthenticateInterceptor.java:41)
[classes/:na]
at 
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:173)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:173)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:86)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.DispatcherHelper.invokeEventHandler(DispatcherHelper.java:454)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.DispatcherServlet.invokeEventHandler(DispatcherServlet.java:278)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.DispatcherServlet.service(DispatcherServlet.java:160)
[stripes-1.6.0.jar:1.6.0]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
[servlet-api.jar:na]
at 
net.sourceforge.stripes.controller.DynamicMappingFilter$2.doFilter(DynamicMappingFilter.java:464)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:260)
[stripes-1.6.0.jar:1.6.0]
at 
net.sourceforge.stripes.controller.DynamicMappingFilter.doFilter(DynamicMappingFilter.java:451)
[stripes-1.6.0.jar:1.6.0]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[catalina.jar:8.5.23]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[catalina.jar:8.5.23]
at 
org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
[urlrewritefilter-4.0.3.jar:4.0.3]
at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
[urlrewritefilter-4.0.3.jar:4.0.3]
at 
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
[urlrewritefilter-4.0.3.jar:4.0.3]
at 
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:394)
[urlrewritefilter-4.0.3.jar:4.0.3]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[catalina.jar:8.5.23]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[catalina.jar:8.5.23]
at 
org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
[catalina.jar:8.5.23]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[catalina.jar:8.5.23]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[catalina.jar:8.5.23]
at 
ch.qos.logback.classic.helpers.MDCInsertingServletFilter.doFilter(MDCInsertingServletFilter.java:51)
[logback-classic-1.0.9.jar:na]
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
[catalina.jar:8.5.23]
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
[catalina.jar:8.5.23]
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
[catalina.jar:8.5.23]
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
[catalina.jar:8.5.23]
at 

Need HELP !! Classloader issue in deserialization

[dhruv patel]

Hi Team,


i am developing one application it uses *platonos plugin engine.*

design  is like :
*
server  (intiates plugin engine)
  |
  |  plugin 1 (dynamically deployed)
  |  plugin 2*


server accepts plugins, install them and manage their lifecycle.

server maintain registry of services provided by plugins

plugin register their *service classes* to server

Note : service classes loaded by plugin class loader
   server loaded by system default class loader

when any request come to server server identifies proper service class from
registry and call method of plugin

before calling it is doing
*
Thread.currentThread().setContextClassLoader(pluginClassLoader);*

this works better for non custom objects. like standard JRE objects (Int,
Long,String etc..)

now my one plugin have one custom object

which is visible in plugin class loader. (present in class path of plugin)


but when it used Java *ObjectInputStream to deserialize* custom object

protected Class? resolveClass(ObjectStreamClass desc)
throws IOException, ClassNotFoundException
{
  
   return Class.forName(name, false, *latestUserDefinedLoader()*);
 

}

*
latestUserDefinedLoader()  *causes class not found exception.

*latestUserDefinedLoader() return server class loader (IN DEBUG VIEW)*


actually it should use plugin class loader


but this same scenario works properly in Tomact and other webservers with
different classloaders.
*
i am surprised how to change behaviour of latestUserDefinedLoader()* ??

do i need to change classloader for some security or permission or something
else pls help ???


awaiting for ur reply 


*Regards*
*Dhruv Patel*
*
*

JSP Classloader issue

[Pat C]

Hi,

Similar to how different servlets run in different classloaders scope, 
we have written a web application (WAR File) that runs the applications 
for each customer by creating a classloader per customer within the same 
servlet context.


This means that all the dependent jar files of the project are NOT 
placed under WEB-INF/lib, but instead under another folder where the 
applications can be hot-swapped. While we successfully implemented 
customer specific classloader, we run into problems when the servlet 
forwarded the request to a JSP.


JSP apparently takes the class loader in which the WAR file is running 
and NOT our classloader, inspite of setting 
Thread.getCurrentThread().setContextClassLoader(CustomerSpecificClassLoader) 
in the servlet before the request was forwarded.


I am now stuck after committing so far in the project and now unable to 
find a solution.


Can you please advice me a way out?
Pat

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JSP Classloader issue

[Caldarale, Charles R]

 From: Pat C [mailto:[EMAIL PROTECTED] 
 Subject: JSP Classloader issue
 
 Similar to how different servlets run in different 
 classloaders scope, 

Actually, it's different webapps that are handled by separate
classloaders.  All servlets of a given webapp are under the same
classloader.

 we run into problems when the servlet forwarded the
 request to a JSP.

What happens if you pre-compile the JSPs, so they all become servlets
and you can place them in the necessary directories?  See:
http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html#Web%20Applicat
ion%20Compilation

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JSP Classloader issue

[Martin Gainty]

Pat-

appears to be a security error
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#setContextClas
sLoader(java.lang.ClassLoader)
you'll need to set the runtime permission for the classLoader to execute via
1) make these edits to $CATALINA_HOME/conf/catalina.policy
grant codeBase file:${catalina.home}/webapps/AppX/-{
permission java.lang.RuntimePermission setContextClassLoader;
}

2)restart TC to use the SecurityManager
%CATALINA_HOME%\bin\catalina start -security

3)read the logs to determine the contextClassLoader is in fact being loaded
and executed by catalina..

M-
- Original Message -
From: Pat C [EMAIL PROTECTED]
To: users@tomcat.apache.org
Sent: Thursday, March 06, 2008 11:25 AM
Subject: JSP Classloader issue


 Hi,

 Similar to how different servlets run in different classloaders scope,
 we have written a web application (WAR File) that runs the applications
 for each customer by creating a classloader per customer within the same
 servlet context.

 This means that all the dependent jar files of the project are NOT
 placed under WEB-INF/lib, but instead under another folder where the
 applications can be hot-swapped. While we successfully implemented
 customer specific classloader, we run into problems when the servlet
 forwarded the request to a JSP.

 JSP apparently takes the class loader in which the WAR file is running
 and NOT our classloader, inspite of setting

Thread.getCurrentThread().setContextClassLoader(CustomerSpecificClassLoader)
 in the servlet before the request was forwarded.

 I am now stuck after committing so far in the project and now unable to
 find a solution.

 Can you please advice me a way out?
 Pat

 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

classloader issue?

[Rik Claesen]

hi,

I'm having a problem with Tomcat 5 with the security manager activated:
javassist.NotFoundException: java.lang.Object
javassist.ClassPool.get(ClassPool.java:374)
org.apache.hivemind.service.impl.CtClassSource.getCtClass(CtClassSource.java:52)
org.apache.hivemind.service.impl.CtClassSource.newClass(CtClassSource.java:62) 
 ...


It looks like someone in the javassist.jar cannot find java.lang.Object in 
the rt.jar


Can it be, that when the security manager is activated, a classloader used 
by javassist cannot find the classes in rt.jar due to security restrictions?


Do I have to move the javassist.jar to another location? if so where?

This simple thing is driving me nuts because all works fine when the 
security manager is not active.


My eternal gratitude for the one who can help me.
Rik



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

Re: classloader issue?

[Boris Unckel]

Hi,

 Do I have to move the javassist.jar to another location? if so where?
Where is the javassist.jar now? In your web application (WEB-INF/lib)?

Boris

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

Re: classloader issue?

[Rik Claesen]

Thnx Boris, I forgot to mention it.
The assist.jar is currently located in the WEB-INF/lib.
and ...this is working fine as long as the security manager is not active.

Rik



From: Boris Unckel [EMAIL PROTECTED]
Reply-To: Tomcat Users List users@tomcat.apache.org
To: Tomcat Users List users@tomcat.apache.org
Subject: Re: classloader issue?
Date: Wed, 15 Feb 2006 13:28:41 +0100 (MET)

Hi,

 Do I have to move the javassist.jar to another location? if so where?
Where is the javassist.jar now? In your web application (WEB-INF/lib)?

Boris

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





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

Re: classloader issue?

[Boris Unckel]

Rik Claesen wrote:

Thnx Boris, I forgot to mention it.
The assist.jar is currently located in the WEB-INF/lib.
and ...this is working fine as long as the security manager is not 
active.


Maybe to put this into the system path would solve your problem. But I 
think it is better to solve the security issue.

I have no experience with the Tomcat security manager, maybe
http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html
helps.

Boris


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