Thanks for the samples.  I'm just trying to find a way of doing (at least
simple/basic) configuration in a way that is less alien to new comers than
the config files are.  I've done similar things in my own config files in
the past.

My problem isn't with config files as such, I just maintain that they can
scare and frustrate people who have never seen them before.  There's also
not much by way of documentation for them - although I'm happy to be
corrected and pointed in the right direction if no one else agrees.

I'm purposely shying away from annotations and groovy in the hope that I
can find a workable solution, maybe only good enough for the simplest
cases, that looks like normal familiar Java code (at least at point of use).

Thanks to all for the ideas.

Sent via mobile device, please forgive typos and spacing errors.

On 11 Jan 2012 13:29, "Dennis Reedy" <dennis.re...@gmail.com> wrote:

>
> On Jan 11, 2012, at 309AM, Greg Trasuk wrote:
>
> >
> > On Wed, 2012-01-11 at 01:01, Peter Firmstone 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.
> >>
> >
> > Just curious...What is the advantage of Groovy's syntax over
> > ConfigurationFile?
>
> You get to use *real* code in your configuration. From my experience
> people are usually very confused with configuration file syntax, and why it
> is java-like but you cannot use any logic. Just to show a simple example
> for reggie (I hope you'll be able to get the gist of it), figuring out the
> correct unicast discovery host based on a system property would be as
> follows (note the initialUnicastDiscoveryProperty is declared just as a
> property as well):
>
> @Component('com.sun.jini.reggie')
> class ReggieConfig {
>    int initialUnicastDiscoveryPort = 10500
>
>    String[] getInitialMemberGroups() {
>        def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
>                                         System.getProperty('user.name'))]
>        return groups as String[]
>    }
>
>    String getUnicastDiscoveryHost() {
>        String host = java.net.InetAddress.getLocalHost().getHostAddress()
>        String value = System.getProperty("java.rmi.server.hostname")
>        if(value != null) {
>            host = java.net.InetAddress.getByName(value).getHostAddress()
>        }
>        return host
>    }
>
> }
>
> Inheritance is supported as well, etc.. etc ...
>
> I also use a DynamicConfiguration (extends AbstractConfiguration) class as
> well. Its use is shown here:
>
> DynamicConfiguration config = new DynamicConfiguration();
> config.setEntry("org.rioproject.watch", "collectionSize", collectionSize);
> Watch watch = construct2("watch", config);
>
> Lastly, I recall Calum Shaw-Mackay was doing work with the Glyph project
> that was using annotations to wire up configs with annotations.
>
> >
> > Also, I just had an interesting thought: What if a service deployer (as
> > in "ServiceStarter is a service deployer") were to scan the service
> > class for JSR330 @Inject annotations and plug in values taken from the
> > config file?
>
> Sure, that would be nice (just be careful not to fill up the perm-gen
> space when looking for annotations though). I'm wondering though how you
> would map the component and name to the property or method to be set.
>
> Dennis

Reply via email to