hi all,
I have developed an application using JBoss (an EJB application that
encapsulates business logic and both JSP and Swing front-ends). I aspire to
deploy this application to small businesses using Java Web Start (JWS).
However, I am having a hell of a time getting JBoss services to successfully
load resources when running in the Java Web Start runtime enviroment.
I have traced the source of the problem to the fact that I mark all the
JBoss jar files as part of my JWS application definition. That is, I tell
JWS that all the JBoss jar files are part of my application and then JWS
takes care of downloading then, updating them if they change, and also
loading them when my application is run. This would be similar to putting
all the JBoss jar files on the system classpath before running JBoss.
The problem is that most, if not all, JBoss services are coded to use their
classloaders to find resources. If you put JBoss.jar on the system
classpath then any services defined in jboss.jar will only be able to find
resources that are on the system classpath. If directories that hold
resources are not also on the system classpath then those JBoss services
will not be able to find them. My problem is that JWS knows enough about my
application to load class files, but no more.
My problem is that when deploying under JWS I really REALLY want JWS to
manage the jars files (so that they are automagically downloaded, and
updated, etc). This means that I JWS will be the owner of these jar files
and only JWS will be able to load the classes inthese jar files.
Unfortunately, this also means that JBoss classes will not be able to
successfully find associated resources using their classloader.
Here is a specific example...
The org.jboss.logging.FileLogging class discovers the directory where it
should write log files by calling the getResource method on its classloader
and getting the URL of a file named "log.properties"....
private void openLogFile()
throws FileNotFoundException
{
URL properties = getClass().getResource("/log.properties");
if(properties == null)
throw new FileNotFoundException("Unable to identify logging
directory!");
When my application is installed a directory is created that contains the
log.properties file, /myapplication/log/log.properties. However,
org.jboss.logging.FileLogging's classloader has no knowledge of this
directory and so it fails to find log.properties.
However, there is an ALTERNATIVE WORKAROUND.
If org.jboss.logging.FileLogging were to use the current thread's
ContextClassLoader then it WOULD find the log.properties file. That is, if
org.jboss.logging.FileLogging did this instead...
URL properties =
Thread.currentThread().getContextClassLoader().getResource("/log.properties"
);
...then it would not fail.
The reason is that my application, like a normal JBoss application, still
uses the org.jboss.Main class to start the server. Since org.jboss.Main
sets the main Thread's contextClassLoader to a classloader that will be
aware of the extra directories specified in the jboss.conf file the
org.jboss.logging.FileLogging could still successfully find the
log.properties resource.
Whew!... all this leads me to this question...Should services in JBoss
really use getClass().getResource(..) to find resources or should they
instead use Thread.currentThread().getContextClassLoader().getResource(..).
It seems to me that JBoss services should really use the Thread's context
classloader since this will always work whereas getClass().getResource(...)
may not always work (as I have demonstrated).
If you agree that JBoss services should always use
Thread.currentThread().getContextClassLoader().getResource instead of
getClass().getResource then naturally I would like to change all such calls
in the JBoss code instead of creating a custom version of JBoss for myself
that I'll have to maintain. I would be willing to help with this by doing
it myself and sending diff files.
Anyway...any comments, suggestions, ideas, etc, would be appreciated.
thanks,
ted stockwell
