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