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
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
