Re: [RT:A5] What are the _real_ concern areas?

On Wed, 18 Dec 2002 01:18 pm, Berin Loritsch wrote:

> That's alot of stuff.  When you sit back and think about it, we can
> merge all the stages that pass in information.  We can think of it
> as a super-context, simple JNDI, or whatever you want.  The basic
> gist is that all of those pieces are associated with the same concern:
> getting information to the component.

Definitely an idea worth investigating.  I've always wondered why information 
delivery was split across multiple lifecycle methods.  It's always seemed a 
bit pointless, to be honest.

> We also have some interfaces defined that we don't have any contracts
> set up for, namely the re* interfaces.  We kept them for legacy
> purposes, but we never really supported them.  If the component is
> passed the super-context object, then if it wants to know when it
> has new information available all it has to do is implement a listener
> interface.

A listener approach is an excellent idea.  Gives the container a way of 
informing the component what has changed, which Re* doesn't.  This is going 
to become more important if we go with a combined data/services lookup 
mechanism.

> There are two major differences.  There is a new overall phase
> (Transition), which means the component can claim or release any
> runtime resources that it will need for processing.  

Do you mean that initialize() would not be able to look stuff up?  Or the 
component's business methods?  Or dispose()?

> It is also important to note that Initializable/Disposable can only be
> called once (each), and Startable can be called any number of times.
> Startable.start() brings the component from Transition to Active Use,
> and Startable.stop() brings the component from Active Use to Transition.
> Once the component has been disposed, can never be brought back to
> life.

Why is it useful for a component to be restarted?  It's a bunch of extra work 
for the component writer to make sure that the component can be safely 
restarted.  What benefit do they get out of it?

> Getting back to the Serviceable interface, we need to realize that now
> it is not just making other components available.  It is also making
> the configuration information available.  Below is only one possibility:
>
> interface ServiceManager
> {
>       Configuration getConfiguration();
>       void writeConfiguration(Configuration config)
>               throws ServiceUnavailableException;

An alternative to writeConfiguration() or bind( name, config ), would be to 
return a mutable Configuration.

>       Object lookup( String urn ); // context and service combined

Can we add boolean contains( String urn ) too?

>       Session getSession();
> }

What goes in the session?


-- 
Adam