> From: Berin Loritsch [mailto:[EMAIL PROTECTED] 
>
> how do we improve on our current model?

I have been meaning to write an [RT] about this, but the
approach taken in PicoContainer, is, I believe, the future.

 1. To clarify that a bit - lifecycle extensions and all are good,
    but ***my God do they add complexity***. Anything that requires
    documentation to use phrases like "establishing a deployment
    context" is in dire need of simplification.

    I still use the ECM, because, frankly, I don't "get" the other
    containers. I understand them but it's just too much to
    comfortably keep inside my head. 

    I want simplification, and I think PicoContainer does that.

 2. I think there are some lingering issues with A4 that we should
    revisit, for example:

    + Poolable components
      This is the whole reason for the lookup()/release() in ECM and
      Fortress. I think we can come up with some other idiom, maybe
      
      component.beginTransaction ();
      try {
          ... do stuff ...
      } finally {
          component.endTransaction ().
      }

      That will allow us to actually do all the lookup() in the
equivalent
      of compose()/service(), instead of limiting that method to a
single
      this.myServiceManager = manager; line.

    + How do we provide components?
      PicoContainer passes them in the constructor. A4 requires a
      lookup()/release(). I'd like to just mark a public field with
      the dependency info and have that field set by reflection to 
      a reference. Like this:

      class MyComponent {
          /**
           * @avalon.dependency version="1.0"
           */
          public QueueManager queueManager = null;

          ...
      }
    
      This would have the queueManager field set by the container to
      a QueueManager with version 1.0. Yes, this means exposing public
      fields, but seriously, how many check that compose() isn't called
      more than once? It is the responsibility of the container to
      proxy components and protect them.


> Does this plan sound good?

If it means that all the meta info generators can finally be
dumped on the world's biggest scrap heap then I'm all for it.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to