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: ContainerManager and Sub-containers
Date Thu, 06 Jun 2002 08:06:00 GMT

> From: Leo Simons [mailto:leosimons@apache.org] 
> > > > However, for most people it is just quicker to do this:
> > > > 
> > > > manager.lookup (Generator.ROLE + "/fooo");
> > > 
> > > make sure you tell everyone you can influence not to! We
> > > really need that "best practices" stuff =)
> > 
> > It gets tiring.  Why not just not make it possible?
> why, to improve the world, of course!
> > Rewritten because all Requests were handled in the compose() method:
> here it is: a-hah! Make it a contract that Request can only 
> ever be created during compose() (pre-init()) and there you 
> go: no more misuse.

But then you can not create a Request based on (for example) the
HTTP request (as in Cocoon). Unless you prepopulate a HashMap or
with all possible requests.
I'm all for Berin's query object approach - the only thing lacking is
neatness of a 

           lookup( ISeeExactlyWhatInterfaceImGetting.ROLE );

I do not consider going from:

  MyComponent myComponent = null;
  try {
    myComponent = (MyComponent) manager.lookup (MyComponent.ROLE);
    // Do stuff that may throw Exception (which is the typical case in
my experience)
  } catch (ComponentException ce) {
    // Ugh.
  } catch (Exception e) {
    // Ugh.
  } finally {
    manager.release (myComponent);


  MyComponent myComponent = manager.lookup (myComponentRequest);
  try {
    // Do stuff that may throw exceptions (which is the typical case in
my experience)
  } catch (Exception ce) {
    // Awwww...
  } finally {
    manager.release (myComponent);

a killer feature, but getting those ComponentSelectors out of my code
makes it worth 
the extra instance variable and stuff.

What I do consider a

        --~~==¤¤**++:::::>>> KILLER FEATURE <<<:::::++**¤¤==~~--

would be the incorporation of Peter's Phoenix 

    <component ...>
        <provide .../>

way of linking components as described here:


into Fortress. Remember, in the ComponentManager spec., a component
should *only* be given those components it needs to work, not any other!

Having <provide/> would not only enable that, but also solve the initial


    Component A requires a component with role B. For example, a
    requires a DBConnectionPool.

    Now, we add component C that also requires a component with role B.
    Like, a Logger requires a DBConnectionPool to log into a database.

    Stuffing A and C into the same Container so that they get the same
    makes it necessary to have them either use the same implmentation of
    or use a ComponentSelector. But then they have to be written to use

which was described in a different way by Marc Scheier here:


                           (Killer Feature End)

As for the directory-should-not-do-pooling: If I put a DataSource in the
directory, I do:

    Connection conn = ((DataSource) manager.lookup
(DataSource.ROLE)).getConnection ();

Now since I'll always want the connection, why not just give me the
right away?

    Connection conn = (Connection) manager.lookup (Connection.ROLE);

I do not see the scalability problem here. With the DataSource approach
I just see
it as not quite as clear when reading the code just what is happening.
The lookup
should, IMO, be for "what I want to use" not "what I want in order to
get what I 
want to use". (This is my problem with exposing the ComponentSelector
interface - 
I want the component, and I want it in *one* lookup. Not some two-stage

A few notes on scalability - with the BucketMap the thread conflicts
inside the 
container are basically eliminated. Any threading issues will then be in
the pooling
code - making access via DataSource (which must have a pool) as
efficient as access
through a PoolableComponentHandler or equivalent (which has a pool).


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

View raw message