> From: Paul Hammant [mailto:[EMAIL PROTECTED]]
>
> Berin,
>
> > There are two major differences. There is a new overall phase
> > (Transition),
>
> Transition. Neat. However, I'd like to see a another
> interface in that
> phase (not withstanding lifecyle extension), to think it was worth a
> name on its own.
All the phases are concepts. If you have a concept, you
need to describe it.
> > interface ServiceManager
> > {
> > Configuration getConfiguration();
> > void writeConfiguration(Configuration config)
> > throws ServiceUnavailableException;
> >
> > Object lookup( String urn ); // context and service combined
> >
> > Session getSession();
> > }
> >
> > interface Session
> > {
> > Object get( Object key );
> > void put( Object key, Object value );
> > }
> >
> > Any thoughts or inputs?
>
> I don't like, sorry.
The whole concept?
> When I look at a class and peer at its 'implements'
> declaration I learn
> a lot. If I see Startable I guess it probably has daemon
> functionality
> or some sort. When I see Contextualizable I reckon it has some
> configuration somewhere. Declared lifecycle methods tell me a lot.
What about merging Contextualizable, Configurable, and Parameterizable?
i.e.
interface ConfigurationManager
{
Logger getLogger(); // can be its own interface...
Context getContext();
Configuration getConfiguration();
Properties getProperties(); // replace the proprietary parameters.
}
interface ServiceManager
{
Object lookup( String role ) throws ServiceException;
boolean hasService( String role );
}
> Just because we can 'simplify' interfaces to a smaller set, does not
> mean we should.
I think we are leaning towards a fragmentation of concerns as opposed
to proper separation.
Consider Parameterizable and Configurable--they have the same function.
Even Contextualizable provides *global* information with any type of
Object (like File, URL, etc.). Arguably they can be moved into the
same space.
> Having said that you raise the issue of updating configuration again.
> Leo Sutic did a great definition of our stance on Context, that he
> might want to step up to a similar role for this?
That would be fine. Updating a configuration is very important, esp.
if you have hierarchical containers. Not everyone needs it, but we
need a standard mechanism so that the container can support it easily.
Using a separate object that is shared between the container and the
component works *much* better than having the component try to directly
save it.
> Also, Session as you have it here has clashing method namespace with
> Map. Not good. I'd prefer Sessionable passing in a Session
> (which has
> getters and setters). <duck>I'd also like to allow bespoke
> containers
> have castable Session interface.</duck>
You better duck! ;P
Castable sessions and castable contexts are bad. If we have a standard
extension mechanism, just pass in your application specific context.
> Lasty, Can we wind down for seasonal festivities please? No
> votes for
> the next 10 days?
I think in another thread you are not following your own advice ;P
My RTs and stuff are just that, random thoughts. I just want to get
it out there so that when we are ready to pick back up we have some
conversation pieces. I am not calling any votes--I haven't even
put up a proposal yet.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
