river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Removing the need for config files
Date Wed, 11 Jan 2012 14:49:20 GMT
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"<trasukg@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
>>>>>
>>>>
>>>>
>>


Mime
View raw message