river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: An in memory configuration builder
Date Mon, 10 Jan 2011 16:52:43 GMT

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 <trasukg@stratuscom.com> 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<sim@qcg.nl>
> >  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
> >
> >


Mime
View raw message