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" <j...@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
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
