river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Removing the need for config files
Date Wed, 11 Jan 2012 08:18:47 GMT

On Wed, 2012-01-11 at 03:56, Tom Hobbs wrote:
> Thanks for all the ideas, chaps.  I haven't tried any of it yet beyond
> running regime up through a main method and the debugger and seeing what
> ServiceStarter did.
> 
> I'm hoping to find a solution that's *really simple* and looks as much like
> "normal Java" as possible.
> 

For discussion purposes, could you post an example of what you'd like
the configuration to look like if it were a "POJO" rather than a
"configuration file"?

I think it would be fairly easy to create a Configuration impl that
takes a class name and then retrieves entries by doing reflection on
that class.  Have a look at net.jini.config.AbstractConfiguration as a
starting point.

Cheers,

Greg.

> I'll take a look at the suggestions and see how far I get next time.
> 
> Cheers.
> 
> Sent via mobile device, please forgive typos and spacing errors.
> 
> On 11 Jan 2012 06:11, "Peter Firmstone" <jini@zeus.net.au> wrote:
> 
> > You could try Dennis Reedy's Groovy Configuration Provider, that'll give
> > you Pojo's with Java like syntax.  We still need to add an ant task to
> > generate the groovy javadoc too.
> >
> > It would be nice to see that system used by default.
> >
> > Cheers,
> >
> > Peter.
> >
> >
> > Greg Trasuk wrote:
> >
> >> 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 NonActivatableServiceDescripto**r(
> >>>                            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/<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/<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<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
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >


Mime
View raw message