On 1/10/2011 8:55 AM, 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<s...@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!

This is why I put together the startnow project and the PersistentJiniService and it's subclass, ConfigurableApplication. The idea being that a client would subclass ConfigurableApplication and PersistentJiniService would of course be the subclass of a service.

With PersistentJiniService, you just call super class constructor with args[] and then startService() and you have a running service with TCP endpoints.

With ConfigurableApplication, you call the super class constructor with args[] and you can use the 'conf' variable (or getConfiguration()) to access your configuration if provided. Otherwise, there are default things available to you with all of the getters in that class. The main thing that ConfigurableApplication is about, is to educate. It has a getter for every kind of thing that you might find referenced as needed in the main Jini classes and you can thus see "one way" to create such a "thing" so that you can find class names of implementations and thus chase down javadoc and other information you might need to better understand what is needed/possible.

"Zero Configuration" is never possible with River as it exists now, but "Default Configuration" (tcp vs ssl, proxy prep, , I feel is really what we should focus a lot more attention on.

Recall that I wrote this stuff almost a decade ago by now, and it is largely unchanged because it does okay, for me, at default behavior. But, not everyone things like I do, nor do I consider this code to be "best of class". It is just an example of what I feel is part of what we really have needed to address for a long time.

Gregg Wonderly

Gregg Wonderly

Reply via email to