avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: FW: ContainerManager and Sub-containers
Date Wed, 05 Jun 2002 13:35:48 GMT
> From: Peter Donald [mailto:peter@apache.org] 
> 
> Put the key in a static at top of class (or cache it in some 
> other way) and 
> that would be a lil better. Though caching all strings would 
> be a much better 
> improvement IMHO.

And that is what my proposal would do.

> > This will perform better than strings will in high performance or 
> > throughput situations, and it is easy to use.  Let's say 
> the container 
> > stores the Components in an array (or an ArrayList) instead of a 
> > hashmap.  With this Request object, it is possible. A map would be 
> > used to find the Request object, done during 
> initialization.  The list 
> > would be used to serve the components.
> 
> I think that no matter how far you go down this path it is 
> never going to be 
> fast enough. IMHO the only way to do this is to lookup 
> resources during 
> initialization phase rather than at runtime and with a good 
> assembly system 
> you get all the bang of runtime lookup with little cost.

Explain?  Keep in mind I am thinking of a very dynamic system like
Cocoon where component resolution depends on the URI and any runtime
variables.

> 
> Can you give me one solid reason why it needs to be done at 
> runtime in 99% of 
> cases? I will grant you that runtime assembly may be necessary when 
> components looked up are determined by request data but in 
> other cases?

Not all systems are as simple (or complicated :)) as Phoenix.

If you want to resolve all your components at init time that's fine.
The new scheme doesn't remove that ability.  What it does is give you
a flexible query scheme (role/object) so that you can perform complex
queries for a component before you resolve it.  It solves the problem
of string concatenation and excessive try/catch/finally blocks.  It
also solves the question of the Selector/role appending debate.

Using the scheme I outlined, we don't need a Selector because we can
have the CM effectively resolve the ROLE/hint or Major ROLE/Minor ROLE
in the same interface.

Consider the case of the ConnectionManager:

Request ssl = manager.createRequest( ConnectionManager.ROLE, "TLS" );
Request normal = manager.createRequest( ConnectionManager.ROLE );

if ( ssl != null )
{
   ConnectionManager conn = (ConnectionManager)manager.lookup( ssl );
   // set up SSL based connection handlers, etc.
}

if ( normal != null )
{
   ConnectionManager conn = (ConnectionManager) manager.lookup( normal
);
   // set up regular based connection handlers, etc.
}

Compare with the current state of affairs:

ConnectionManager ssl = null;
ConnectionManager normal = null;

try
{
    ssl = (ConnectionManager)manager.lookup( ConnectionManager.ROLE +
"/TLS" );
    // set up SSL based connection handlers, etc.
}
catch (Exception e)
{
    // log or ignore we need to check for a different kind of connection
manager...
}

try
{
   normal = (ConnectionManager)manager.lookup( ConnectionManager.ROLE );
   // set up regular based connection handlers, etc.
}
catch (Exception e)
{
   // log or ignore
}


Both of the above examples do essentially the same thing.  If a
component
exists, it will use it--if not, it goes on to the next request.  We
can't
put both component resolutions in the same try/catch block or we won't
check
the normal connection manager if the ssl version doesn't exist.

I am looking at just making it easier all the way around.


--
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