You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Tom Hobbs <tv...@googlemail.com> on 2012/01/10 23:04:56 UTC
Removing the need for config files
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?
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
Re: Removing the need for config files
Posted by Gregg Wonderly <gr...@wonderly.org>.
Did you try EmptyConfiguration.INSTANCE?
Gregg
Sent from my iPhone
On Jan 10, 2012, at 4:04 PM, Tom Hobbs <tv...@googlemail.com> 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?
>
> 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
Re: Removing the need for config files
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Wed, 2012-01-11 at 07:03, Tom Hobbs wrote:
> Am I reading the JiniConfiguration and VelocityConfigration bits
> correctly? They both look like they start with a config file which
> contains placeholder strings, then swap those placeholders for real values
> and present Configuration with a Reader to the whole? Essentially they're
> pretending to be config files, but created in memory rather than stored on
> disk.
>
> Is that more or less what's going on?
>
ConfigurationFile already allows for "overrides". When you call
'ConfigurationProvider.getInstance(String[] options)', the options are
passed on to the Configuration implementation's constructor. For
ConfigurationFile, the first option is the path to the configuration
file in the file system. The ResourceConfigurationFile provided in
RiverConfigurationResources treats this as a resource path and reads the
file from the classpath, but otherwise delegates to ConfigurationFile.
The second and subsequent option strings, if provided, can be
"overrides" in the form of "entryName=value". These definitions
override any definitions contained in the configuration file. The
overrides are even used when resolving the entries in the configuration
file, so they can be referenced by other entries. Have a look at the
'nonSecureService.config' file in extra/RiverConfigurationResources/src
to see what I mean.
http://svn.apache.org/viewvc/river/extra/RiverConfigurationResources/trunk/src/nonSecureService.config?view=co
Cheers,
Greg.
> Sent via mobile device, please forgive typos and spacing errors.
>
> On 11 Jan 2012 09:49, "Tom Hobbs" <tv...@googlemail.com> wrote:
>
> > 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" <tr...@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" <ji...@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
> >> > >>>
> >> > >>>
> >> > >>
> >> > >>
> >> > >>
> >> > >>
> >> > >
> >> > >
> >>
> >>
Re: Removing the need for config files
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-01-12 13:03, Tom Hobbs wrote:
> Am I reading the JiniConfiguration and VelocityConfigration bits
> correctly? They both look like they start with a config file which
> contains placeholder strings, then swap those placeholders for real values
> and present Configuration with a Reader to the whole? Essentially they're
> pretending to be config files, but created in memory rather than stored on
> disk.
>
> Is that more or less what's going on?
I can only speak for the VelocityConfigurationBuilder part, and you are
right.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Removing the need for config files
Posted by Tom Hobbs <tv...@googlemail.com>.
Am I reading the JiniConfiguration and VelocityConfigration bits
correctly? They both look like they start with a config file which
contains placeholder strings, then swap those placeholders for real values
and present Configuration with a Reader to the whole? Essentially they're
pretending to be config files, but created in memory rather than stored on
disk.
Is that more or less what's going on?
Sent via mobile device, please forgive typos and spacing errors.
On 11 Jan 2012 09:49, "Tom Hobbs" <tv...@googlemail.com> wrote:
> 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" <tr...@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" <ji...@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
>> > >>>
>> > >>>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >
>> > >
>>
>>
Re: Removing the need for config files
Posted by Tom Hobbs <tv...@googlemail.com>.
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" <tr...@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" <ji...@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
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
>
>
Re: Removing the need for config files
Posted by Greg Trasuk <tr...@stratuscom.com>.
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" <ji...@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
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
Re: Removing the need for config files
Posted by Tom Hobbs <tv...@googlemail.com>.
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.
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" <ji...@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
>>>
>>>
>>
>>
>>
>>
>
>
Re: Removing the need for config files
Posted by Dan Creswell <da...@gmail.com>.
On 12 January 2012 10:26, Tom Hobbs <tv...@googlemail.com> wrote:
> I've no intention of removing or changing the interface, but we'll see what
> happens when I work out what to do. I like Dan's convention over
> configuration plug.
>
Oh good ;)
There are various ways to achieve that of course. One would be for an
installer to generate the basic config using conventions and
auto-discovery. A similar thing could be used to construct a one-off
configuration each and every time one starts up.
Alternatively, one removes the need for reading configuration from a
file and can read one from memory with a set of conventions (or
auto-discovered defaults).
Perhaps we need a tweak to ServiceStarter that allows it to accept
start-up requests with no in-line configuration. We might have to
modify all the in-the-box services to follow one naming convention for
base configs so they can all be auto-configured from one source. That
or we change each service to auto-configure in absence of overrides.
Many ways to go, the key is to not need configuration by default...
> There's a number of improvements worthy of their own jiras mentioned on
> this tread. I need to write them down before they get lost!
>
> Sent via mobile device, please forgive typos and spacing errors.
>
> On 12 Jan 2012 08:04, "Simon IJskes - QCG" <si...@qcg.nl> wrote:
>
>> On 11-01-12 15:49, Gregg Wonderly wrote:
>>
>> The deal with ConfigurationFile, of course, is to be able to do
>>> configuration at deployment time, instead of at development time, and
>>> thus, even your development environment is a "deployment" that might be
>>> different from production. For example, in development, you might just
>>> use TCP endpoints, no policy, and a LUS group that is different from the
>>> production environment, so that there is no chance to interfere with
>>> production, which might be on the same routable/multicast-accessible
>>> network.
>>>
>>
>> So in order to keep this scenario in the future, we need to keep the
>> Configuration interface as the main interface to exchange the configuration
>> on. Agree?
>>
>> Gr. Sim
>>
>> --
>> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
>> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>>
Re: Removing the need for config files
Posted by Tom Hobbs <tv...@googlemail.com>.
I've no intention of removing or changing the interface, but we'll see what
happens when I work out what to do. I like Dan's convention over
configuration plug.
There's a number of improvements worthy of their own jiras mentioned on
this tread. I need to write them down before they get lost!
Sent via mobile device, please forgive typos and spacing errors.
On 12 Jan 2012 08:04, "Simon IJskes - QCG" <si...@qcg.nl> wrote:
> On 11-01-12 15:49, Gregg Wonderly wrote:
>
> The deal with ConfigurationFile, of course, is to be able to do
>> configuration at deployment time, instead of at development time, and
>> thus, even your development environment is a "deployment" that might be
>> different from production. For example, in development, you might just
>> use TCP endpoints, no policy, and a LUS group that is different from the
>> production environment, so that there is no chance to interfere with
>> production, which might be on the same routable/multicast-accessible
>> network.
>>
>
> So in order to keep this scenario in the future, we need to keep the
> Configuration interface as the main interface to exchange the configuration
> on. Agree?
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>
Re: Removing the need for config files
Posted by Gregg Wonderly <ge...@cox.net>.
I think the Configuration interface has a lot of simplicity going for it. I
also think that there could be some additional value provided in some changes to
that interface. But, I'd suggest doing anything like that in a sub-interface.
public interface OtherBitsForConfiguration extends Configuration {
....
}
Gregg
On 1/12/2012 2:04 AM, Simon IJskes - QCG wrote:
> On 11-01-12 15:49, Gregg Wonderly wrote:
>
>> The deal with ConfigurationFile, of course, is to be able to do
>> configuration at deployment time, instead of at development time, and
>> thus, even your development environment is a "deployment" that might be
>> different from production. For example, in development, you might just
>> use TCP endpoints, no policy, and a LUS group that is different from the
>> production environment, so that there is no chance to interfere with
>> production, which might be on the same routable/multicast-accessible
>> network.
>
> So in order to keep this scenario in the future, we need to keep the
> Configuration interface as the main interface to exchange the configuration
> on. Agree?
>
> Gr. Sim
>
Re: Removing the need for config files
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-01-12 15:49, Gregg Wonderly wrote:
> The deal with ConfigurationFile, of course, is to be able to do
> configuration at deployment time, instead of at development time, and
> thus, even your development environment is a "deployment" that might be
> different from production. For example, in development, you might just
> use TCP endpoints, no policy, and a LUS group that is different from the
> production environment, so that there is no chance to interfere with
> production, which might be on the same routable/multicast-accessible
> network.
So in order to keep this scenario in the future, we need to keep the
Configuration interface as the main interface to exchange the
configuration on. Agree?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Removing the need for config files
Posted by Gregg Wonderly <gr...@wonderly.org>.
My org.wonderly.jini2.PersistentJiniService class at
http://startnow.dev.java.net, was my attempt to create this "traceable" layer of
"Java" using "Configuration" so that people could start with something that was
100% java, and then see the basics of how "Configuration" could be used to
provide "values". At the time, I wasn't really wanting to say "don't use
configuration, just use Java", because I wanted to see how Configuration would
work out, with various implementations. The ConfigurationFile syntax is fairly
close to Java, but the "subtle" differences can be a little confusing,
especially if documentation doesn't lead you, easily, to a discovery/learning
experience.
A lot of Java developers, seem to be more than willing to click through Javadoc,
because that's easy to navigate in web form. The Javadoc for Configuration,
leads to ConfigurationFile, so I think its practical to believe that it would be
possible for people to find "documentation" for that.
But, Dennis' work on Groovy configuration, makes some things a lot easier, if
you grok Groovy. I think that annotations, could have some traction for people
who have used them. Otherwise, in the end, if you just want Java, then creating
a factory class, or some sort of "ServiceContainer" class, which has "Java/PoJo"
interfaces to the values you need, might be the right path.
The deal with ConfigurationFile, of course, is to be able to do configuration at
deployment time, instead of at development time, and thus, even your development
environment is a "deployment" that might be different from production. For
example, in development, you might just use TCP endpoints, no policy, and a LUS
group that is different from the production environment, so that there is no
chance to interfere with production, which might be on the same
routable/multicast-accessible network.
Gregg Wonderly
On 1/11/2012 3:17 AM, Tom Hobbs wrote:
> 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"<tr...@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
>>>>>
>>>>
>>>>
>>
Re: Removing the need for config files
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-01-12 10:17, Tom Hobbs wrote:
> but again I want to keep
> the configuration side of things as plain and simple as possible.
I like those configuration classes, where one specifies the intent, and
in the end serves as a factory. Partial or completely in fluent style.
(in fowler terms: construction builder, method chaining).
You can configure programmatically, with data from the runtime
environment, decide at runtime how to configure, and provide multiple
configuration builders for different use cases. And you can change the
implementation behind it while keeping the API stable.
I tried to make a start with the velocity template, but i think it is
better to create a pluggable Configuration class, where you can plugin
component.name mapped 'Function' objects. Normalize conventions for the
'.name' part. Create Function<T> objects for factories and static config
variables.
The ConfigurationBuilder (or configuration construction builder) above
can create a Configuration instance in the end. It is possbible that we
need to create a few other things as well, but thats easily added.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Removing the need for config files
Posted by Tom Hobbs <tv...@googlemail.com>.
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" <tr...@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
> > >>
> > >
> > >
> > >
>
>
Re: Removing the need for config files
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 1/11/2012 9:12 AM, Dan Creswell wrote:
> On 11 January 2012 15:11, Gregg Wonderly<gr...@wonderly.org> wrote:
>> On 1/11/2012 8:30 AM, Dennis Reedy wrote:
>>> On Jan 11, 2012, at 920AM, Dan Creswell wrote:
>>>> Alright, so what am I talking about? Convention over configuration -
>>>> and there isn't enough of that in the starter kit.
>>> Excellent point.
>>>
>>>
>>>> Once the common
>>>> cases are taken care of, configuration becomes more of an exception
>>>> than the rule and then there is motivation to dig deeper and do
>>>> something more serious like use Groovy or whatever on the behalf of
>>>> the individual that will help them get over the hill to something
>>>> working.
>>>>
>>>> Simple cases? Maybe two boxes on the same LAN (thus one can use the
>>>> subnet as a group name and make some reasonable assumptions about
>>>> multicast) and maybe a single box with a correctly configured local
>>>> loopback.
>>> Maybe:
>>>
>>> groups - default to user.name
>>> multicast - assume available (warn if not)
>>
>> To whit, the simple webserver tries to connect to itself at startup and
>> announces if it can't. It might be interesting if Reggie issued a unicast
>> to itself on local host, as well as expecting itself to appear on multicast
>> discovery (maybe it does and I've forgotten about this), and announcing if
>> it can't, at least, see itself via unicast and multicast discovery.
>>
> I would imagine it's possible to put all these checks in a little tool
> that runs ahead of everything else at install time (and maybe when
> starting things in general or similar). After all, the reason for
> these checks is to assist in diagnosing a problem that has occurred.
> Better to do all these tests and checks from one place before a
> problem occurs and confuses people.
Yes, that could work well for diagnosis too. What ever happened the "console"
tool that existed in Jini 1.x days, which did discovery and show what was
"visible"? We need something, that can separate "was discovered" from "can't
download and instantiate. My changes to reggie, to return unmarshalled objects,
conveniently gave me that new opportunity, and I really appreciated that my
"serviceUI client" app, can show me all the services that were discovered, and
then if I invoke one that has a non-resolvable codebase, it can tell me that too.
Gregg Wonderly
Re: Removing the need for config files
Posted by Dan Creswell <da...@gmail.com>.
On 11 January 2012 15:11, Gregg Wonderly <gr...@wonderly.org> wrote:
> On 1/11/2012 8:30 AM, Dennis Reedy wrote:
>>
>> On Jan 11, 2012, at 920AM, Dan Creswell wrote:
>>>
>>> Alright, so what am I talking about? Convention over configuration -
>>> and there isn't enough of that in the starter kit.
>>
>> Excellent point.
>>
>>
>>> Once the common
>>> cases are taken care of, configuration becomes more of an exception
>>> than the rule and then there is motivation to dig deeper and do
>>> something more serious like use Groovy or whatever on the behalf of
>>> the individual that will help them get over the hill to something
>>> working.
>>>
>>> Simple cases? Maybe two boxes on the same LAN (thus one can use the
>>> subnet as a group name and make some reasonable assumptions about
>>> multicast) and maybe a single box with a correctly configured local
>>> loopback.
>>
>> Maybe:
>>
>> groups - default to user.name
>> multicast - assume available (warn if not)
>
>
> To whit, the simple webserver tries to connect to itself at startup and
> announces if it can't. It might be interesting if Reggie issued a unicast
> to itself on local host, as well as expecting itself to appear on multicast
> discovery (maybe it does and I've forgotten about this), and announcing if
> it can't, at least, see itself via unicast and multicast discovery.
>
I would imagine it's possible to put all these checks in a little tool
that runs ahead of everything else at install time (and maybe when
starting things in general or similar). After all, the reason for
these checks is to assist in diagnosing a problem that has occurred.
Better to do all these tests and checks from one place before a
problem occurs and confuses people.
Re: Removing the need for config files
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 1/11/2012 8:30 AM, Dennis Reedy wrote:
> On Jan 11, 2012, at 920AM, Dan Creswell wrote:
>> Alright, so what am I talking about? Convention over configuration -
>> and there isn't enough of that in the starter kit.
> Excellent point.
>
>
>> Once the common
>> cases are taken care of, configuration becomes more of an exception
>> than the rule and then there is motivation to dig deeper and do
>> something more serious like use Groovy or whatever on the behalf of
>> the individual that will help them get over the hill to something
>> working.
>>
>> Simple cases? Maybe two boxes on the same LAN (thus one can use the
>> subnet as a group name and make some reasonable assumptions about
>> multicast) and maybe a single box with a correctly configured local
>> loopback.
> Maybe:
>
> groups - default to user.name
> multicast - assume available (warn if not)
To whit, the simple webserver tries to connect to itself at startup and
announces if it can't. It might be interesting if Reggie issued a unicast to
itself on local host, as well as expecting itself to appear on multicast
discovery (maybe it does and I've forgotten about this), and announcing if it
can't, at least, see itself via unicast and multicast discovery.
Gregg Wonderly
Re: Removing the need for config files
Posted by Tom Hobbs <tv...@googlemail.com>.
Good ideas all.
You sound like you're describing River On Rails. ;-). I've barely
scratched the surface of what I want to do, so changing direction is now is
easy.
Sent via mobile device, please forgive typos and spacing errors.
On 11 Jan 2012 14:31, "Dennis Reedy" <de...@gmail.com> wrote:
>
> On Jan 11, 2012, at 920AM, Dan Creswell wrote:
> >
> > Alright, so what am I talking about? Convention over configuration -
> > and there isn't enough of that in the starter kit.
>
> Excellent point.
>
>
> > Once the common
> > cases are taken care of, configuration becomes more of an exception
> > than the rule and then there is motivation to dig deeper and do
> > something more serious like use Groovy or whatever on the behalf of
> > the individual that will help them get over the hill to something
> > working.
> >
> > Simple cases? Maybe two boxes on the same LAN (thus one can use the
> > subnet as a group name and make some reasonable assumptions about
> > multicast) and maybe a single box with a correctly configured local
> > loopback.
>
> Maybe:
>
> groups - default to user.name
> multicast - assume available (warn if not)
>
> Dennis
>
Re: Removing the need for config files
Posted by Dennis Reedy <de...@gmail.com>.
On Jan 11, 2012, at 920AM, Dan Creswell wrote:
>
> Alright, so what am I talking about? Convention over configuration -
> and there isn't enough of that in the starter kit.
Excellent point.
> Once the common
> cases are taken care of, configuration becomes more of an exception
> than the rule and then there is motivation to dig deeper and do
> something more serious like use Groovy or whatever on the behalf of
> the individual that will help them get over the hill to something
> working.
>
> Simple cases? Maybe two boxes on the same LAN (thus one can use the
> subnet as a group name and make some reasonable assumptions about
> multicast) and maybe a single box with a correctly configured local
> loopback.
Maybe:
groups - default to user.name
multicast - assume available (warn if not)
Dennis
Re: Removing the need for config files
Posted by Dan Creswell <da...@gmail.com>.
On 11 January 2012 13:43, Tom Hobbs <tv...@googlemail.com> wrote:
> Thanks for the samples. I'm just trying to find a way of doing (at least
> simple/basic) configuration in a way that is less alien to new comers than
> the config files are. I've done similar things in my own config files in
> the past.
>
> My problem isn't with config files as such, I just maintain that they can
> scare and frustrate people who have never seen them before. There's also
> not much by way of documentation for them - although I'm happy to be
> corrected and pointed in the right direction if no one else agrees.
>
I actually think the problem is there's plenty of documentation, it's
scattered all over the place and there's a whole pile of other stuff
that also needs wading through to do much of anything. It's no
different from any other substantial codebase be it an application
server or Spring.
> I'm purposely shying away from annotations and groovy in the hope that I
> can find a workable solution, maybe only good enough for the simplest
> cases, that looks like normal familiar Java code (at least at point of use).
>
The simplest thing to do is nothing. That requires no reading of
documentation, no messing around with files, just fire it up and go.
Which brings me to a claim that improving configuration is the wrong
mindset. Eliminating configuration is what's required.
Of course, one cannot eliminate all configuration because there are
always cases where human's must wade in and deal with the dark
corners. But choose a set of common cases and support those out of the
box.
Alright, so what am I talking about? Convention over configuration -
and there isn't enough of that in the starter kit. Once the common
cases are taken care of, configuration becomes more of an exception
than the rule and then there is motivation to dig deeper and do
something more serious like use Groovy or whatever on the behalf of
the individual that will help them get over the hill to something
working.
Simple cases? Maybe two boxes on the same LAN (thus one can use the
subnet as a group name and make some reasonable assumptions about
multicast) and maybe a single box with a correctly configured local
loopback.
> Thanks to all for the ideas.
>
> Sent via mobile device, please forgive typos and spacing errors.
>
> On 11 Jan 2012 13:29, "Dennis Reedy" <de...@gmail.com> wrote:
>
>>
>> On Jan 11, 2012, at 309AM, Greg Trasuk 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?
>>
>> You get to use *real* code in your configuration. From my experience
>> people are usually very confused with configuration file syntax, and why it
>> is java-like but you cannot use any logic. Just to show a simple example
>> for reggie (I hope you'll be able to get the gist of it), figuring out the
>> correct unicast discovery host based on a system property would be as
>> follows (note the initialUnicastDiscoveryProperty is declared just as a
>> property as well):
>>
>> @Component('com.sun.jini.reggie')
>> class ReggieConfig {
>> int initialUnicastDiscoveryPort = 10500
>>
>> String[] getInitialMemberGroups() {
>> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
>> System.getProperty('user.name'))]
>> return groups as String[]
>> }
>>
>> String getUnicastDiscoveryHost() {
>> String host = java.net.InetAddress.getLocalHost().getHostAddress()
>> String value = System.getProperty("java.rmi.server.hostname")
>> if(value != null) {
>> host = java.net.InetAddress.getByName(value).getHostAddress()
>> }
>> return host
>> }
>>
>> }
>>
>> Inheritance is supported as well, etc.. etc ...
>>
>> I also use a DynamicConfiguration (extends AbstractConfiguration) class as
>> well. Its use is shown here:
>>
>> DynamicConfiguration config = new DynamicConfiguration();
>> config.setEntry("org.rioproject.watch", "collectionSize", collectionSize);
>> Watch watch = construct2("watch", config);
>>
>> Lastly, I recall Calum Shaw-Mackay was doing work with the Glyph project
>> that was using annotations to wire up configs with annotations.
>>
>> >
>> > 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?
>>
>> Sure, that would be nice (just be careful not to fill up the perm-gen
>> space when looking for annotations though). I'm wondering though how you
>> would map the component and name to the property or method to be set.
>>
>> Dennis
Re: Removing the need for config files
Posted by Dennis Reedy <de...@gmail.com>.
On Jan 11, 2012, at 843AM, Tom Hobbs wrote:
> Thanks for the samples. I'm just trying to find a way of doing (at least
> simple/basic) configuration in a way that is less alien to new comers than
> the config files are. I've done similar things in my own config files in
> the past.
>
> My problem isn't with config files as such, I just maintain that they can
> scare and frustrate people who have never seen them before. There's also
> not much by way of documentation for them - although I'm happy to be
> corrected and pointed in the right direction if no one else agrees.
>
> I'm purposely shying away from annotations and groovy in the hope that I
> can find a workable solution, maybe only good enough for the simplest
> cases, that looks like normal familiar Java code (at least at point of use).
Sure no problem. FWIW, you can make Groovy look just like Java, and not use any Groovy idioms. Again, FWIW, I've found that Java developers adapt really, really quickly to the groovy approach as opposed to the configuration file.
Regards
Dennis
Re: Removing the need for config files
Posted by Tom Hobbs <tv...@googlemail.com>.
Thanks for the samples. I'm just trying to find a way of doing (at least
simple/basic) configuration in a way that is less alien to new comers than
the config files are. I've done similar things in my own config files in
the past.
My problem isn't with config files as such, I just maintain that they can
scare and frustrate people who have never seen them before. There's also
not much by way of documentation for them - although I'm happy to be
corrected and pointed in the right direction if no one else agrees.
I'm purposely shying away from annotations and groovy in the hope that I
can find a workable solution, maybe only good enough for the simplest
cases, that looks like normal familiar Java code (at least at point of use).
Thanks to all for the ideas.
Sent via mobile device, please forgive typos and spacing errors.
On 11 Jan 2012 13:29, "Dennis Reedy" <de...@gmail.com> wrote:
>
> On Jan 11, 2012, at 309AM, Greg Trasuk 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?
>
> You get to use *real* code in your configuration. From my experience
> people are usually very confused with configuration file syntax, and why it
> is java-like but you cannot use any logic. Just to show a simple example
> for reggie (I hope you'll be able to get the gist of it), figuring out the
> correct unicast discovery host based on a system property would be as
> follows (note the initialUnicastDiscoveryProperty is declared just as a
> property as well):
>
> @Component('com.sun.jini.reggie')
> class ReggieConfig {
> int initialUnicastDiscoveryPort = 10500
>
> String[] getInitialMemberGroups() {
> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
> System.getProperty('user.name'))]
> return groups as String[]
> }
>
> String getUnicastDiscoveryHost() {
> String host = java.net.InetAddress.getLocalHost().getHostAddress()
> String value = System.getProperty("java.rmi.server.hostname")
> if(value != null) {
> host = java.net.InetAddress.getByName(value).getHostAddress()
> }
> return host
> }
>
> }
>
> Inheritance is supported as well, etc.. etc ...
>
> I also use a DynamicConfiguration (extends AbstractConfiguration) class as
> well. Its use is shown here:
>
> DynamicConfiguration config = new DynamicConfiguration();
> config.setEntry("org.rioproject.watch", "collectionSize", collectionSize);
> Watch watch = construct2("watch", config);
>
> Lastly, I recall Calum Shaw-Mackay was doing work with the Glyph project
> that was using annotations to wire up configs with annotations.
>
> >
> > 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?
>
> Sure, that would be nice (just be careful not to fill up the perm-gen
> space when looking for annotations though). I'm wondering though how you
> would map the component and name to the property or method to be set.
>
> Dennis
Re: Removing the need for config files
Posted by Dennis Reedy <de...@gmail.com>.
On Jan 11, 2012, at 309AM, Greg Trasuk 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?
You get to use *real* code in your configuration. From my experience people are usually very confused with configuration file syntax, and why it is java-like but you cannot use any logic. Just to show a simple example for reggie (I hope you'll be able to get the gist of it), figuring out the correct unicast discovery host based on a system property would be as follows (note the initialUnicastDiscoveryProperty is declared just as a property as well):
@Component('com.sun.jini.reggie')
class ReggieConfig {
int initialUnicastDiscoveryPort = 10500
String[] getInitialMemberGroups() {
def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
System.getProperty('user.name'))]
return groups as String[]
}
String getUnicastDiscoveryHost() {
String host = java.net.InetAddress.getLocalHost().getHostAddress()
String value = System.getProperty("java.rmi.server.hostname")
if(value != null) {
host = java.net.InetAddress.getByName(value).getHostAddress()
}
return host
}
}
Inheritance is supported as well, etc.. etc ...
I also use a DynamicConfiguration (extends AbstractConfiguration) class as well. Its use is shown here:
DynamicConfiguration config = new DynamicConfiguration();
config.setEntry("org.rioproject.watch", "collectionSize", collectionSize);
Watch watch = construct2("watch", config);
Lastly, I recall Calum Shaw-Mackay was doing work with the Glyph project that was using annotations to wire up configs with annotations.
>
> 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?
Sure, that would be nice (just be careful not to fill up the perm-gen space when looking for annotations though). I'm wondering though how you would map the component and name to the property or method to be set.
Dennis
Re: Removing the need for config files
Posted by Greg Trasuk <tr...@stratuscom.com>.
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
> >>
> >
> >
> >
Re: Removing the need for config files
Posted by Peter Firmstone <ji...@zeus.net.au>.
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 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
>>
>
>
>
Re: Removing the need for config files
Posted by Greg Trasuk <tr...@stratuscom.com>.
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