On Mon, 2011-01-10 at 11:44, Dan Creswell wrote: > Or we could fix up EmbeddedDescriptor to exploit either the new or existing > constructor? >
I agree in principle with another service constructor that takes a configuration explicitly. However, just having that constructor doesn't address creating the configuration in memory, as per Sim's original goal. For that, I like my idea (biased as I am) because: 1 - It can exploit the current ConfigurationFile class, which has a protected constructor that takes a reader. 2 - I've already sort of done it as part of my "surrogate" container work. 3 - It doesn't require any changes to existing code, so could be rolled out even without a full River release. Matter of fact, I like it so much, I think I'll go code it. Give me a few hours... Cheers, Greg. > On 10 January 2011 16:41, Greg Trasuk <[email protected]> wrote: > > > One more thing... > > > > An additional benefit is that services currently written would not have > > to be modified to provide a different constructor than the current > > non-activatable constructor. > > > > Cheers, > > > > Greg. > > > > On Mon, 2011-01-10 at 11:32, Greg Trasuk wrote: > > > How about this? > > > > > > - User includes "EasyDefaultConfig.jar" in their classpath. > > > - "EasyDefaultConfig.jar" uses the ConfigurationProvider mechanism > > > (which references a manifest entry in the jar file) to replace > > > FileConfiguration with a slightly modified subclass that reads a default > > > configuration as a resource from the classpath. > > > - Services remain coded to the current ServiceStarter API and get their > > > configuration as currently recommended through the > > > ConfigurationProvider, e.g. > > > > > > Configuration config= > > > ConfigurationProvider.getInstance("NonSecureJeri", > > > "groups=\"TEST\""); > > > > > > - "EasyDefaultConfig.jar" can contain a number of basic configurations, > > > e.g. "NonSecureJeri", "TLSJeri", "KerberosJeri", etc. > > > - Could even contain a configuration for ServiceStarter to start up the > > > usual infrastructure services (Reggie, Mahalo, etc). > > > > > > > > > That way, we allow for the fact that configuration is actually > > > complicated, but give the casual user a simple way to ignore most of it. > > > > > > If all are in favour, I can code it fairly quickly, but I'll need > > > suggestions for some basic configuration files. > > > > > > Cheers, > > > > > > Greg. > > > > > > On Mon, 2011-01-10 at 09:55, Sim IJskes - QCG wrote: > > > > On 10-01-11 15:48, Tom Hobbs wrote: > > > > > Is this part of the wider work discussed ages ago about supplying > > more > > > > > configuration options? POJOs, Groovy classes etc? > > > > > > > > > > On Mon, Jan 10, 2011 at 2:46 PM, Sim IJskes - QCG<[email protected]> > > wrote: > > > > >> > > > > >> When can use ServiceStarter with an in memory (=String) > > Configuration file. > > > > >> Any ideas for a ConfigurationBuilder that newcomers can use to get > > flying > > > > >> easily? > > > > > > > > Not sure. More of an autodeploy option. First we let newcomers to the > > > > technology code a client and a service. In the main method they > > > > instanciate the AutoConfigurer (or similar) set a few booleans, maybe a > > > > hostname or a prefered port, and off they go. > > > > > > > > Run service, run client, Peng! River is running! Kapow! > > > > > > > > Look ma, no config files. > > > > > > > > Gr. Sim > > > > > > > > -- > > > > QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl > > > > Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 > > > >
