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" <j...@zeus.net.au> wrote:
> You could try Dennis Reedy's Groovy Configuration Provider, that'll give
> you Pojo's with Java like syntax. We still need to add an ant task to
> generate the groovy javadoc too.
>
> It would be nice to see that system used by default.
>
> Cheers,
>
> Peter.
>
>
> Greg Trasuk wrote:
>
>> On Tue, 2012-01-10 at 17:04, Tom Hobbs wrote:
>>
>>
>>> Hey dudes,
>>>
>>> I'm currently working (read: hacking) my way through the code trying
>>> to work out how to make it possible to remove the need for starting
>>> services with config files. I remember a user asking about this a
>>> while back, but their problem isn't the problem I'm trying to solve
>>> right now.
>>>
>>> I've quite easily gotten rid of the "start-xyz" config files, but I've
>>> not worked out a way of getting rid of the last piece of the puzzle.
>>>
>>> Consider the code;
>>>
>>> return new ServiceDescriptor[] {
>>> new NonActivatableServiceDescripto**r(
>>> codebase,
>>> policy,
>>> classpath,
>>> "com.sun.jini.reggie.**
>>> TransientRegistrarImpl",
>>> new String[] { config }) };
>>>
>>> Here, "config" wants to be the name of a config file such as can be
>>> found in $RIVER_HOME/examples/hello/**config/jrmp-reggie.config. What
>>> I'd much rather do is remove the need for that and instead replace it
>>> with some pojo or similar that could be the actual configuration (or
>>> pretend to be a config file...)
>>>
>>>
>>>
>>
>>
>>
>>
>>> Substituting null for config and running through a debugger blows up
>>> in a useful fashion, which shows me that the problem is (I think) in
>>> ConfigurationProvider:192 where it tries to assign a value to "cname".
>>> It fails to do this and so later on in line is assumes that it must
>>> be looking for a ConfigurationFile. Beyond looking for a resource
>>> called "META-INF/services/net.jini.**config.Configuration" on the
>>> classpath, I admit to not being entirely sure what else
>>> ConfigurationProvider:192 is trying to do or how it helps. Maybe I'm
>>> going about this the wrong way. Any suggests?
>>>
>>>
>>>
>>
>> ConfigurationProvider is checking for the resource to see if you want a
>> particular implementation of the Configuration interface. It defaults
>> to ConfigurationFile, which uses the argument as a file name from which
>> to read configuration entries (in the ConfigurationFile format). If
>> you'd prefer a different implementation for the Configuration interface,
>> you put the class name in the
>> 'META-INF/services/net.jini.**config.Configuration' resource. This way,
>> we're not locked into the oft-maligned ConfigurationFile format.
>>
>> So, if you really wanted to replace the configuration file with a POJO,
>> you could just write a POJO that implements Configuration (of course I
>> guess that would't really be a POJO, but you get the idea) and place the
>> name of that class in the aforesaid resource.
>>
>> If you're OK with the idea of a config file, but just don't like having
>> to have it in the file system, I did some work last year in the 'extra'
>> branch that might be of interest. Have a look at
>> http://svn.apache.org/viewvc/**river/extra/**RiverConfigurationResources/
>> **trunk/<http://svn.apache.org/viewvc/river/extra/RiverConfigurationResources/trunk/>
>> .
>> The project builds to 'RiverConfigurationResources.**jar'. When you
>> include that jar file in your classpath, you can include configuration
>> files as resources on the classpath. Also, there are two very plain
>> configuration files 'nonSecureClient.config' and
>> 'nonSecureService.config' that can be used for beginner-type services
>> and clients.
>>
>> You might also want to have a look at
>> http://svn.apache.org/viewvc/**river/extra/**JiniInfrastructure/<http://svn.apache.org/viewvc/river/extra/JiniInfrastructure/>,
>> which uses
>> the resource configuration to startup all the infrastructure services
>> (reggie, norm, outrigger, etc) from one command line. It can also start
>> the service browser (have a look in
>> http://svn.apache.org/viewvc/**river/extra/**
>> JiniInfrastructure/trunk/src/**org/apache/river/extra/start/**
>> infrastructure/Main.java?view=**markup<http://svn.apache.org/viewvc/river/extra/JiniInfrastructure/trunk/src/org/apache/river/extra/start/infrastructure/Main.java?view=markup>for
>> info).
>>
>> I envisioned these projects as 'extra' distrubutables apart from the
>> core distributable, hence the 'extra' branch. If people think they are
>> useful, we can talk about adding some documentation and a link from
>> 'river.apache.org'.
>>
>> Cheers,
>>
>> Greg.
>>
>>
>>
>>> My reason for this work is that I still maintain that starting with
>>> Jini/River, making services work and doing stuff is still to hard for
>>> new comers.
>>>
>>>
>>>
>>
>>
>>
>>
>>> Cheers,
>>>
>>> Tom
>>>
>>>
>>
>>
>>
>>
>
>
