river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Ramsdale" <jeff.ramsd...@gmail.com>
Subject Re: Drowning in the River
Date Thu, 08 Feb 2007 20:55:38 GMT
Hey Greg,

Sorry for the delay--had to introduce a new baby to the world!

On 2/6/07, Greg Trasuk <trasukg@stratuscom.com> wrote:
> Hi Jeff:
>
>         Question below...
>
> > As an example, I'd like to see the Configuration mechanism refactored
> > to be entirely Java-based. Then the current code could be modified to
> > adapt from the current configuration format to the Java configuration.
>
> Could you elaborate on what isn't Java-based about it?  Or are you just
> saying that there's a configuration file (not unlike how Spring has a
> configuration file, except the format isn't XML)?

It's been a while since I looked into it, but from my previous
exploration it seemed like there was a lot of work done in
ConfigurationFile and other classes to turn the configuration syntax
into Java method calls. That's fine but there's no intermediate format
to ease an alternative entry point. That is, you are stuck either
using pretty low-level (non-obvious, to the newcomer) Jini calls or
you have to use the configuration file format. If possible I'd rather
see some sort of intermediate Configuration object. Since the
configuration file format allows for the use of custom static methods,
though, this might be difficult. I'd like to see the options
considered, though.

In short, a newbie comfortable with Java but not the config file
format might prefer another method of starting a service. Providing a
file path to a main method is not elegant or familiar. Also, if I
recall the thread is launched in the background automatically by the
service starter. I'd rather see the creation of the Configuration
object and the deploying of the service as separate steps so that the
user can be more aware of what's going on.

> > The hard-core dev could still have the full power of the runtime
> > configuration but tool providers would have an easier time providing
> > alternative implementations (Groovy, XML, etc.). Backwards
>
> Is there anything preventing someone from writing another implementation
> of Configuration as an alternative to ConfigurationFile?  I though Van
> Simmons et al had done a Groovy version (haven't looked at it myself,
> but I thought I heard that during the Javaposse interview).

Yes, I was thinking of his work in mentioning it. I'm sure he's
already figured out the complexities (though I'd like to see his tool
provided as a separate download!) and maybe he proves it's not a big
deal. But I'm not saying other implementations aren't possible, only
that the requirement to USE an implementation is perhaps an indication
that there's more complexity than there need be.

> > compatibility is maintained but new options are opened up.
> > Configuration is a very visible point of difficulty for new users.
> >
> > Jeff
> Cheers,
>
> Greg.
> --
> Greg Trasuk, President
> StratusCom Manufacturing Systems Inc. - We use information technology to
> solve business problems on your plant floor.
> http://stratuscom.com

Jeff

Mime
View raw message