Don't know about the Groovy stuff, because I want configuration to be easy
and non-scary to newbies, I have looked at it at all. Learning Jini/River
is enough without expecting people to learn Groovy as well (assuming they
don't already).
Injecting values based on annotations is an idea, but again I want to keep
the configuration side of things as plain and simple as possible. What you
suggest might be a good idea as an additional option for configuration
though.
Sent via mobile device, please forgive typos and spacing errors.
On 11 Jan 2012 09:12, "Greg Trasuk" <tras...@stratuscom.com> wrote:
>
> 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=markupfor
> 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
> > >>
> > >
> > >
> > >
>
>
