>
>
>>Static is the killer. I guess only beginners make that mistake. No
>>singletons needed for Avalon/phoenix.
>>
>
>Can you elaborate a little? In the Juggernaut framework (which I
>designed about 4-5 years ago) there is a single static instance of a
>kernel just by virtue of the VM only creating one in the main method,
>but the reference to the kernel is passed down to all child components
>in the object graph that support a kernel-accessible interface. Is the
>top-level object graph only available in Avalon/Phoenix via static
>methods?
>
You've beaten it already then I think. Start by having a look
HelloWorldServer or some of the others. Wehn starting new blocks, I
invariable clone one of these and make it what I want (iteratively).
"top-level object graph" Not sure what you mean here.
The only static in Avalon will be genuine factories.
>>>My one concern is the configuration system. Avalon's configuration
>>>
>>Yes, it's read only. One day it will be updatable. For now, perhaps
>>seperate logically into your own interal services (and one or more
>>blocks that deliver than service). What you could do in one
>>DbXmlConfiguration service (and it's DefaultDbXmlConfiguration block) is
>>copy stuff from the read only Configuration (from assembly.xml) and
>>write immediately to the persistence store. Charles' SimpleServer demo
>>uses the persistence store. When the writable configuration arrives,
>>you could change (hopefully) the block only. You et the functioanly you
>>require immediately though.
>>
>
>Worse case, we can use our existing configuration framework, which is
>almost identical to the Avalon framework (interface-wise) except that it
>supports writing and is implemented using concrete classes layered on
>top of a DOM.
>
You're saying what we've done (or not done) is the worst case scenarios
for you? Perhaps then suggest and interface that could touch on what
you need :-)
If you can mine this maillist you'll see Peter and Fede ++ discussing
things about six months ago. Configurable and Reconfigurable. Perhaps
you need a ConfigurationUpdate interface ..
interface ConfigurationUpdater {
void setConfigurationUpdateThing(ConfigurationUpdateThing cut);
}
interface ConfigurationUpdateThing {
void setConfiguration(XPath path, String value);
void setConfiguration(XPath path, int value);
...
}
Note - I am not sure what the best name for these interfaces are.
Especially the "Thing" bit.
The idea being that some blocks implement Configurable. Some blocks
implement Configurable and ConfigurationUpdater (does not extend the
former though).
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
