On Wed, 2012-01-11 at 01:01, Peter Firmstone 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.
>
Just curious...What is the advantage of Groovy's syntax over
ConfigurationFile?
Also, I just had an interesting thought: What if a service deployer (as
in "ServiceStarter is a service deployer") were to scan the service
class for JSR330 @Inject annotations and plug in values taken from the
config file?
Cheers,
Greg.
> 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 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
> >>
> >
> >
> >
