No problem, code samples always help. (and I'll take a look at
AbstractConfiguration as you suggest.)
Beware, the following is being written on The Worlds Worst Tablet.
Configuration config = new EasyConfiguration();
config.setServiceClass(Myservice.class);
config.addLookupGroup("test");
config.addLookupGroup("cheese");
config.setServiceName("Fred");
...snip similar lines...
ServiceStarter.start(config);
imagine that the snip (or some parent of EasyConfiguration) was providing
other required data.
Sent via mobile device, please forgive typos and spacing errors.
On 11 Jan 2012 09:20, "Greg Trasuk" <tras...@stratuscom.com> wrote:
>
> 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
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
>
>
