[
https://issues.apache.org/jira/browse/DAEMON-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-351.
--------------------------------
Resolution: Won't Fix
This behaviour is by design.
See http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html
and
http://stackoverflow.com/questions/18354535/why-do-subsequent-jni-threads-return-null-on-currentthread-getclassloader
The main thread (created at start) will have the expected class loader but the
stop class loader will not. Your work-around is the way to go for jvm mode.
In java mode, you'll have a separate JVM so you won't have class loader problem
but you will have two instances of your app which may not be what you want.
> Context class loader of stopping thread is null
> -----------------------------------------------
>
> Key: DAEMON-351
> URL: https://issues.apache.org/jira/browse/DAEMON-351
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
> Affects Versions: 1.0.15
> Environment: Windows 10 x64, Java 1.8.x.
> Reporter: Eldin Okanovic
> Priority: Minor
>
> I don't know who is responsible for setting context class loader for current
> thread when starting and stopping service/app, but it's not set (is null)
> when stopping service.
> I am using jvm mode and main method in both cases (when starting and
> stopping).
> Example output in main method:
> //output is sun.misc.Launcher$AppClassLoader@c387f44 when starting service
> //output is null when stoping service
> System.out.println(Thread.currentThread().getContextClassLoader());
> This causes a problem when i need to load classes from app defined classpath
> in stopping process.
> So, i was forced to manually get classloader instance when starting service,
> and set the same classloader instance when stoping a service.
> //starting:
> classLoader = Thread.currentThread().getContextClassLoader();
> //stoping:
> Thread.currentThread().setContextClassLoader(classLoader);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
