Re: Config files with application class references

Bob Scheifler wrote:
>> I have a Jini application that uses com.sun.jini.start facilities to
>> specify the
>> launch of the application.  Its configuration file includes some
>> static factory
>> class usages which are from the application's classpath.  I've started
>> creating
>> a jar file for launching because I get the exception below.  Thus, I
>> have to
>> make parts of one services classpath visible in the app classloader to
>> get the
>> configuration to work.
>
> I can't say that I really understand what you think the problem is.
> Perhaps you could describe more explicitly what class(es) the service
> starter configuration needs to reference to get its job done, and why
> they shouldn't be in the system class loader.

I have a configuration class which provide static methods.  Let's say that I
have a service configuration file that contains

import some.package.of.ConfigMethods;

some.other.package.for.a.service {
        obj1 = ConfigMethods.getFactory( new Factory1() );
}

getFactory() inspects the environment it is running in, and decides what to
return based on that.

The construction of Factory1, and anything it constructs internally, is
something that is specific to the service, as is the environment that
ConfigMethods.getFactory() runs in.  Both the ClassLoader and the security
context active at the time of construction are not going to be that which the
service specified with its classpath and policy in the ServiceDescriptor.

In the stack trace, it appears that the configuration file passed to
ServerStarter on the command line, is parsed with the JVMs classpath and no
apparent security context (no security manager it seems). Factory1 and any
referenced classes must be resolved by the JVM app classloader.

I can understand why that is neccessary given the implementation today.  I'm
suggesting that this is probably something that can cause problems for many
people who are not completely familar with all the context in which each step of
  the launch of ServiceStarter occurs.  There are probably several scenarios
which result in ClassNotFoundException confusion, as well as ClassCastException
which will not be clearly identifiable as comming out of the fact that
ConfigurationFile requires all objects to be resolved at the time of the parse,
instead of waiting to resolve them until they are referenced.

I know that part of the benefits of ConfigurationFiles current implementation is
early identification of type issues.  This is a good thing.  I'm suggesting that
we think about how it might be possible to use a slightly different mechanism
for startup of ServiceStarter such that each services definition might be
processed under its own runtime parameterization.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]