Here is Stefano's reply to my query
-----Original Message-----
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 3:23 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Can I get your oppinion on something?
Berin Loritsch wrote:
>
> The Avalon team is once again rehashing/revisiting the
> ComponentManager/ ComponentSelector relationship. Several developers
> are of the opinion that the ComponentSelector is inherently evil, and
> generally regard it as a hack.
I have to admit I find myself resonating with this vision.
> Esp. since the container has to set up the ComponentSelector the same
> way, or components written to look for a ComponentSelector will break
> if it doen't
> exist.
>
> Opinions range everywhere from create a "Factory" Component like JAXP
> to create the instances we need (like a specific Generator) to
> somewhere close to the current ECM. (ECM is not held in high regard
> at the moment, with a proposed replacement that many folks are happy
> with the direction).
>
> The question I have is what would your oppinion be on creating a
> nextgen ComponentManager interface.
Oh, gosh, let's see.
> I came up with this interface (and associated class):
>
> /**
> * Avalon 5 interface, so I can reuse the component manager name. */
> public interface ComponentManager {
> /**
> * These methods create a Request object for the CM. It will
> * return <code>null</code> if the component does not exist.
> */
> Request createRequest( String role );
> Request createRequest( String role, Object hint );
>
> /**
> * No need for exceptions because the Request object originates
> * from the ComponentManager. The only issue that might come up
> * is a Request object from a different CM--in that case a
> * RuntimeException is accpetable.
> */
> Object lookup( Request role );
>
> /**
> * Still can't be convinced that this isn't necessary as long as
> * we have pooled components.
> */
> void release(Object component );
> }
First thing that comes to mind is that Request is a bad name for this. I
would call it "Prototype" or something like that implying the fact that
it is not an instance but a bridge to obtain that instance.
> public final class Request
> {
> public final Object origination;
> public final long key;
>
> public Request( Object parent, long key )
> {
> origination = parent;
> this.key = key;
> }
>
> public long hashCode()
> {
> return key;
> }
>
> public boolean equals( Object other )
> {
> if ( ! other instanceOf Request ) return false;
>
> Request test = (Request) other;
>
> if ( other.key != key ) return false;
> if ( other.origination != origination) return false;
>
> return true;
> }
> }
>
> 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.
Ok, just one (maybe stupid) question: what's wrong in something like
this:
interface ComponentManager {
Component getComponent(String role);
Component getComponent(String role, Object hint);
...
}
> An example component using it would look like this:
>
> /**
> * Component Impl.
> */
> public final class MyComponent implements Composable
> {
> Request m_required = null;
> Request m_optional = null;
> ComponentManager m_manager = null;
>
> public void compose( ComponentManager manager )
> throws ComponentException;
> {
> m_manager = manager;
> m_required = manager.createRequest( EchoComponent.ROLE );
> m_optional = manager.createRequest( I18nComponent.ROLE,
> "XML-bundle" );
>
> if ( null == m_required ) throw new
> ComponentException("Missing component");
> }
>
> public return processRequest( String message )
> {
> EchoComponent echo = (EchoComponent)m_manager.lookup(
> m_required );
> String newMessage = echo.echoMessage( message );
>
> if ( null != m_optional )
> {
> I18nComponent trans = (I18nComponent)m_manager.lookup(
> m_optional );
> newMessage = trans.translateMessage( newMessage );
> m_manager.release( trans );
> }
>
> m_manager.release( echo );
> return newMessage;
> }
> }
>
> Does this look like something you would prefer using to the current
> state of affairs in Cocoon code?
I currently disklike the abuse of (non-runtime) exceptions that Avalon
throw to indicate things that are not found. A try/catch requires the
JVM to save the state of the execution (sort-of an internal
continuation) and this is a very expensive process.
The code above is much more performant and friendly in that respect,
even if I still don't understand the need for those 'request' stubs.
> Remember, this is for a next
> generation
> approach, not anything that we will force on the world real soon now.
Look like Avalon 5 will need to be *really* better than Avalon 4 or
nobody will ever switch :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
