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" <tvho...@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" <tras...@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" <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 > >> > >>> > >> > >>> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > >> > > > >> > >>
