On 11 January 2012 13:43, Tom Hobbs <tvho...@googlemail.com> wrote:
> 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 actually think the problem is there's plenty of documentation, it's
scattered all over the place and there's a whole pile of other stuff
that also needs wading through to do much of anything. It's no
different from any other substantial codebase be it an application
server or Spring.
> 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).
>
The simplest thing to do is nothing. That requires no reading of
documentation, no messing around with files, just fire it up and go.
Which brings me to a claim that improving configuration is the wrong
mindset. Eliminating configuration is what's required.
Of course, one cannot eliminate all configuration because there are
always cases where human's must wade in and deal with the dark
corners. But choose a set of common cases and support those out of the
box.
Alright, so what am I talking about? Convention over configuration -
and there isn't enough of that in the starter kit. Once the common
cases are taken care of, configuration becomes more of an exception
than the rule and then there is motivation to dig deeper and do
something more serious like use Groovy or whatever on the behalf of
the individual that will help them get over the hill to something
working.
Simple cases? Maybe two boxes on the same LAN (thus one can use the
subnet as a group name and make some reasonable assumptions about
multicast) and maybe a single box with a correctly configured local
loopback.
> 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
