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