avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Avalon4:PROPOSAL] Context Consensus
Date Wed, 11 Dec 2002 18:42:50 GMT


> From: Noel J. Bergman [mailto:noel@devtech.com] 
> 
> I really dislike the use of separately maintained meta-data 
> disjoint from code to describe a mandatory contract.  If the 
> meta-data isn't kept in synch with the source code, the 
> contract is corrupted.  In this case, the container doesn't 
> know what type of context is expected, and cannot be told by 
> the component.

The metadata has many other things that must be kept in synch:

 + The type of services expected in the ServiceManager.

 + The Logging channels.

 + Configuration schema.

 + etc...

Basically, you're stuck with separate metadata either way. I don't
consider it a major nuisance to add another (optional) element.

> Since there is no guarantee that the context is castable to a 
> T, the component probably should do something like:
> 
>       protected T myContext;
> 
>       public void contextualize (Context context)
>              throws ContextException
>       {
> 	    try
>           {
>               myContext = (T) context;
>           }
>           catch(ClassCastException cce)
>           {
>               log("I'm sorry, but the context I got isn't 
> what I need. Please check the meta-data.");
>               throw new ContextException(...);
>           }
>       }
> 
> in order to be safe.
> 
> Wrong?  Right?  Indifferent?  :-)

I prefer for the component to to the cast and explode if it fails.
The responsibility is on the container to catch and log the exception.

But there's nothing keeping you from doing what you describe above...

/LS


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message