Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: RE: [proposal] avalon 5 ComponentManager interface
From: Leo Simons <leosimons@apache.org>
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
In-Reply-To: <000e01c2105d$7617f640$0801a8c0@Lagrange>
References: <000e01c2105d$7617f640$0801a8c0@Lagrange>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 10 Jun 2002 17:01:05 +0200
Message-Id: <1023721265.1613.225.camel@lsd.bdv51>
Mime-Version: 1.0

> > - proposal for component management in avalon 5:
> > 1) removal of ComponentSelector
> > 2) removal of release()
> 
> Without including in the proposal a replacement for CS when it
> operates on Objects (such as when selecting components based
> on a ServletRequest), and a replacement for release() that can
> handle switching between pooled and non-pooled components without
> any changes to the client code, I can not vote for this proposal.
> 
> ------------------------
> 
> All ComponentManagers should support hints, or none. We're not
> making the developers any favors by introducing yet another
> "this should work, but then again it might not".

I think it would be relatively simple to explain which Containers make
use of a ComponentManager that supports hints, and which do not. ie "if
you use hints, you can use fortress but not phoenix".

So what you say is "this works in this setup, but not in this one".

Note that if the contract for hints says that the CM can freely ignore
them (as Berin proposes), that is a lot more like "this should have an
effect, but then again it might not".

> Also, with just String hints, if you use a ServletRequest as
> hint, you end up with:
> 
>   lookup (role, stringifyRequest (request))

yes. Keeping the interface more simple/limited means that complex use of
the interface becomes more complex. This is a choice; I'm all for
keeping the CM simple. For complex uses, there's JNDI, DAP, etc etc.

> The 
> 
>   if (exists (role)) manager.lookup (role)
> 
> construct should only be required when the role you are looking
> up is optional.

agreed. Whether a role is optional is defined in the contract between
container and component (which may be configuration-dependent).

> I question the assertion
> that the use of exists() as you propose is common java practice.

java.lang.System returns null on a failed lookup

java.util.Collection defines contains()
java.awt.Container defines contains()
java.util.Map defines containsKey() and returns null on a failed lookup

java.lang.ClassLoader throws an exception on a failed lookup
java.rmi.Registry throws an exception on a failed lookup

javax.naming.Context defines no equavalent, but instead returns a new
instance of itself on a failed lookup (not desirable behaviour!)

Which of these is most desirable, when that which you are looking up is
_not_ guaranteed to exist?

// returning null on failure
if( null != (m_component = (MyComponent)cm.lookup( MyComponent.ROLE ))
	m_component.doStuff();
else
	whoops();

// use exists()
if( cm.exists( MyComponent.ROLE ) )
{
	m_component = (MyComponent) cm.lookup( MyComponent.ROLE );
	m_component.doStuff();
}
else
	whoops();

// use exception
try
{
	m_component = cm.lookup( MyComponent.ROLE );
}
catch( LookupException le )
{
	whoops();
}

Which of these is most desirable, when what you are looking up _is_
guaranteed to exist?

// returning null on failure
m_component = (MyComponent)cm.lookup( MyComponent.ROLE );
m_component.doStuff();

// use exists()
m_component = (MyComponent) cm.lookup( MyComponent.ROLE );
m_component.doStuff();


// use exception
try
{
	m_component = cm.lookup( MyComponent.ROLE );
}
catch( LookupException le )
{
	// will never happen
}

Which case is more common?

> I also question that it results in more performant code, as you
> do not pay for exceptions unless they are thrown (See
> http://java.sun.com/javaone/javaone2001/pdfs/2696.pdf , page 29
> for exception handling.)

so I thought originally. Stefano suggested differently though. Stefano?

However, as the CM is likely to use a Map of some sort internally, there
will still be a check against null to be able to throw the exception,
within the CM:

lookup( Key ) throws ComponentException {
// ...

final Object result = m_map.lookup( Key );
if (result == null)
	throw new ComponentException();
// ...
}

> - thus you have traded a lookup that 
> should not fail except in exceptional circumstances for a check 
> *and* a lookup. 

if the lookup should never fail, neither if(exists()) nor
try{}/catch{}/finally{} should be necessary at all. If a container
guarantees that either everything specified as needed by a component
exists, or that compose() will not be called on the component, that is
your case.

If it does not, you need to check against null (or a method that returns
boolean), or catch exceptions.

> Please justify these assumptions.

there you go =)

on the subject of release(): if a proposal for the CM needs to include a
proposal regarding resource management (as you state), then you disagree
with the statement that resource management is not of concern to the CM?

cheers,

- Leo


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