The JNI threads that call serviceRequest/serviceMain do not have a context classloader setup (i.e. Thread.currentThread().getContextClassLoader() == null). Allthough this probably isn't wrong persé, it is a situation that a lot of code out there (including Java's own SPI/ServiceLoader classes) don't account for.
I suggest you initialize the context classloader from your JNI calling code to the same contextclassloader that is used to create the service class. If that's not an option, you might want to call Thread.currentThread().setContextClassLoader(getClass().getClassLoader()) as a first thing in the serviceMain/serviceRequest of e.g. ServiceMain, AbstractService, ...
The JNI threads that call serviceRequest/serviceMain do not have a context classloader setup (i.e. Thread.currentThread().getContextClassLoader() == null). Allthough this probably isn't wrong persé, it is a situation that a lot of code out there (including Java's own SPI/ServiceLoader classes) don't account for.
I suggest you initialize the context classloader from your JNI calling code to the same contextclassloader that is used to create the service class. If that's not an option, you might want to call Thread.currentThread().setContextClassLoader(getClass().getClassLoader()) as a first thing in the serviceMain/serviceRequest of e.g. ServiceMain, AbstractService, ...
That will solve a lot of weird issues of code breaking when using winrun4j as a service, while the same code works when using winrun4j as an executable, e.g.: http://sourceforge.net/projects/winrun4j/forums/forum/693148/topic/5334049