Just to prove I'm still here;
If it's spitting out of config files you're interested in, a little while
ago I put some code in that allowed programmatic config generation. I
forget the exact syntax, but something like;
myconfig.setLookupGroups(grps).setName("My
Service").setEndpoint(EnpointType.class);
SeriviceStarter.start(myconfig)
...and so on.
This used (from memory) Velocity (?) to create an in-memory file which the
existing ConfigurationFile bits could be fooled into thinking was a real
file and allow configuration off the back of that.
Using the above, with Velocity (or whatever it was) to then write that file
to disk for tweaking, would be a reasonably trivial task.
I'm interested in Dennis' assertion that developers are more interested in
lifecycle than config. I think that's probably true of developers, but
probably not true of people new to River and who just want to write Hello
World services. That's just my gut feel. But I'm still interested in his
point. So if we were to give Dennis' developers a magic annotation wand,
what kind of annotations would they like to see? What would they look
like? Or is it some other lifecycle mechanism handling thing they're
interested in?
On Tue, Sep 25, 2012 at 9:34 PM, Gregg Wonderly <[email protected]> wrote:
>
> On Sep 25, 2012, at 3:10 PM, Dennis Reedy <[email protected]> wrote:
>
> >
> > On Sep 25, 2012, at 405PM, Gregg Wonderly wrote:
> >
> >>
> >> On Sep 25, 2012, at 2:52 PM, Simon IJskes - QCG <[email protected]> wrote:
> >>
> >>> On 25-09-12 21:37, Gregg Wonderly wrote:
> >>>
> >>>> From my perspective, it seems that the most predominate step forward
> >>>> that we might take, would be to make all configuration used in
> >>>> services be visible to tooling on the outside which could then guide
> >>>> the deployment much more dependably and accelerate this small but
> >>>> currently oh so fragile set of steps toward getting River up and
> >>>> running in your environment.
> >>>
> >>> To me this reads like a mode where the 'easy' environment spits out a
> configuration file, which if presented to the easy environment produces the
> exact same result, and allows for editting to tweak things. Does it?
> >>
> >>
> >> That might be one of the things which happens. But, the annotations,
> ultimately, provide the metadata which defines the "parameters" of
> configuration which are valid. So, tooling of all different nature can use
> that meta-data.
> >>
> >
> > Interesting idea! You also could create a ConfigurationProvider that
> writes out component, name, type, defaultValue (if any) and optional data.
> Might be a start for services that already exist and may not have
> annotations applied.
>
> One of the scenarios that I think about here, is that
> ConfigurationProvider then remains as the "interface" to configuration
> data. An implementation which is constructed with a service that has
> annotations as being discussed here, could then read the annotations and
> know what should be available. A subclass of that might be provided for a
> particular deployment environment to bridge from the annotated application
> to the runtime deployment needs as administered by the particular
> environments tooling.
>
> public class AnnotationNotProvidedException extends ConfigurationException
> { }
>
> public AnnotationBasedConfigurationProvider implements
> ConfigurationProvider {
> private final Map<String,Object> configValues;
> public AnnotationBasedConfigurationProvider( Remote svc ) throws
> AnnotationNotProvidedException {
> …look for annotations and create a map for Configuration
> Provider containing defaults from annotations…
> localConfigurationChanges();
> }
> protected abstract void localConfigurationChanges() throws
> ConfigurationException;
> }
>
> public RioAnnotationConfigurationProvider extends
> AnnotationBasedConfigurationProvider {
> protected void localConfigurationChanges() throws
> ConfigurationException {
> }
> }
>
> Gregg
