On Tue, 2012-01-10 at 17:04, Tom Hobbs wrote:
> Hey dudes,
>
> I'm currently working (read: hacking) my way through the code trying
> to work out how to make it possible to remove the need for starting
> services with config files. I remember a user asking about this a
> while back, but their problem isn't the problem I'm trying to solve
> right now.
>
> I've quite easily gotten rid of the "start-xyz" config files, but I've
> not worked out a way of getting rid of the last piece of the puzzle.
>
> Consider the code;
>
> return new ServiceDescriptor[] {
> new NonActivatableServiceDescriptor(
> codebase,
> policy,
> classpath,
> "com.sun.jini.reggie.TransientRegistrarImpl",
> new String[] { config }) };
>
> Here, "config" wants to be the name of a config file such as can be
> found in $RIVER_HOME/examples/hello/config/jrmp-reggie.config. What
> I'd much rather do is remove the need for that and instead replace it
> with some pojo or similar that could be the actual configuration (or
> pretend to be a config file...)
>
> Substituting null for config and running through a debugger blows up
> in a useful fashion, which shows me that the problem is (I think) in
> ConfigurationProvider:192 where it tries to assign a value to "cname".
> It fails to do this and so later on in line is assumes that it must
> be looking for a ConfigurationFile. Beyond looking for a resource
> called "META-INF/services/net.jini.config.Configuration" on the
> classpath, I admit to not being entirely sure what else
> ConfigurationProvider:192 is trying to do or how it helps. Maybe I'm
> going about this the wrong way. Any suggests?
>
ConfigurationProvider is checking for the resource to see if you want a
particular implementation of the Configuration interface. It defaults
to ConfigurationFile, which uses the argument as a file name from which
to read configuration entries (in the ConfigurationFile format). If
you'd prefer a different implementation for the Configuration interface,
you put the class name in the
'META-INF/services/net.jini.config.Configuration' resource. This way,
we're not locked into the oft-maligned ConfigurationFile format.
So, if you really wanted to replace the configuration file with a POJO,
you could just write a POJO that implements Configuration (of course I
guess that would't really be a POJO, but you get the idea) and place the
name of that class in the aforesaid resource.
If you're OK with the idea of a config file, but just don't like having
to have it in the file system, I did some work last year in the 'extra'
branch that might be of interest. Have a look at
http://svn.apache.org/viewvc/river/extra/RiverConfigurationResources/trunk/.
The project builds to 'RiverConfigurationResources.jar'. When you
include that jar file in your classpath, you can include configuration
files as resources on the classpath. Also, there are two very plain
configuration files 'nonSecureClient.config' and
'nonSecureService.config' that can be used for beginner-type services
and clients.
You might also want to have a look at
http://svn.apache.org/viewvc/river/extra/JiniInfrastructure/, which uses
the resource configuration to startup all the infrastructure services
(reggie, norm, outrigger, etc) from one command line. It can also start
the service browser (have a look in
http://svn.apache.org/viewvc/river/extra/JiniInfrastructure/trunk/src/org/apache/river/extra/start/infrastructure/Main.java?view=markup
for info).
I envisioned these projects as 'extra' distrubutables apart from the
core distributable, hence the 'extra' branch. If people think they are
useful, we can talk about adding some documentation and a link from
'river.apache.org'.
Cheers,
Greg.
> My reason for this work is that I still maintain that starting with
> Jini/River, making services work and doing stuff is still to hard for
> new comers.
>
> Cheers,
>
> Tom
