avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Date Thu, 21 Nov 2002 01:31:15 GMT
Peter,

>>Better to concentrate on our core product -> Avalon Framework's
>>interfaces.
>>
>>Embrace the multi-container world!!
>>    
>>
>
>The "interfaces define everything" mentality is something that some
>consumers of Avalon (myself included) find troubling.  Avalon Framework
>needs to (and in quite a few cases does) include conceptual
>documentation that goes beyond the interfaces.
>
>Interfaces do not define anything save interfaces.  It's the contracts
>behind those interfaces that matter.  Without the contracts, the
>interfaces are meaningless.
>
>Consider an Avalon Framework with all the lifecycle interfaces, but no
>lifecycle definition.  It would be useless - containers would be able to
>implement lifecycle methods in any order they desired.  You couldn't
>write a container-independent application using such an Avalon
>Framework.  It is the lifecycle contract that is fundamental.
>
We do have a definition :- 
http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html

I do accept that docs could be improved.

>In addition, by focusing on the contract it is most easy to see
>inadequacies in the framework.  For example, the Context interface is
>sufficient for the needs of consumer apps.  While it might be nice to
>have some syntactic sugar as in the Phoenix Block Context, it isn't
>strictly necessary.  However the contract is clearly incomplete -
>without some sort of definition of container-common context objects and
>their keys no one can use the Context in a container independent way.
>
It may be that there are some similarities between Phoenix and Merlin. 
But when coarse grained containers #3 thru #8 arrive, we will look 
pretty daft having such a constraining single design for component 
lacing.  People are going to surprise us with containers. We'll look 
short sighted if we fix abstractions for miriads of containers now.

>For example, James, which is a pretty simple app from an Avalon
>perspective, would not be able to run in any random Avalon container
>that implemented the current Avalon Framework.  That's because James
>needs the application home directory to resolve some of the file URLs.
>But since the key ("app.home") and the semantic meaning associated with
>the value returned (the application home as a File object) are not
>defined as part of the contract, a random container doesn't need to
>provide this.  As I understand it Phoenix and Merlin both provide this,
>but it is not laid out explicitly in the Framework.
>
This is because Context is a base for ServletContext (the A-F design not 
yet written), MailetContext, BeanContext (written for EOB), BlahContext. 
 Some of them may offer a 'get root dir' feature, some may not.  Do we 
encode all permutations for Servlets, Mailets, Beans, Blocks, MerlinApps 
in the same file?  I think not. Anyone can code a component that can 
implements one or all of the A-F interfaces, and is extended by say two 
subclasses (also comps).  e.g.

  abstract class FooDaemon implements Startable, Runnable, 
Contextualizable {
    Thread thread;
    File rootDir;
    // from A-F Startable
    void start() {
      thread = new Thread(this);
      thread.start();
    }
    // from A-F Startable
    void stop() {
      thread.stop();
    }
  }

  class PhoenixFooDaemon extends FooDaemon {
   // from A-F Contextualizable
    void contextualize(Context context) {
       rootDir = ((BlockContext) context).getRootDir();
    }
  }

  class EOBFooDaemon extends FooDaemon {
   // from A-F Contextualizable
    void contextualize(Context context) {
       rootDir = ((BeanContext) context).getRootDir();
    }
  }

With the above design, you interoperability with Phoenix and EOB (a .Net 
Remoting inspired app server I work on).  Replace the word 'EOB' with 
JAMES (one day?), or Merlin, or Catalina's internals (one day?). 
Containers are all different.  They use differnet cop-lacing, config and 
context.

The point is that Context is deliberately vague.  Either we define a 
massive hierarchy of Context interfaces in the A-F package (and curse 
ourselves at our liesure over the years), or we leave the context to the 
container in question.  Phoenix and Merlin are just two containers. 
 They are not going to be the last 'coarse grained application server' 
containers.

Apart from anything else, it was voted on before that Merlin include the 
tiny Phoenix-Client jar in it's client API classloader and honors 
BlockContext as is (if it wanted to be compatible with Phoenix).

>I'd argue that a standard, minimal set of keys/object should be part of
>the Context contract. Otherwise the Context interface is fairly useless
>as part of framework since every container would provide a purely custom
>set of keys/values.  Thus any code written that implemented
>Contextualizable would be implicitly container dependent.  
>
You can go for that if you like.  Code something that is adaptive and 
used the primitive get() mechanism.  

Maybe we should have a single additional context method called 
getContainer(). It returns "Phoenix 4.0.2" where that were true. Or 
maybe a method called isCompatibleWith("Phoenix 4.x")

The point is that deciding

>The only way to get a truly multi-container world is precisely to be
>crystal clear about what the Avalon Framework does and does not
>guarantee.  I very much support multiple containers - and the ability of
>Avalon Framework consumers to write functional, container-independent
>applications.
>
Sentence #1, I believe we are clear. We may not have commuicated it well :-)
Sentence #2, agree.

- Paul



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


Mime
View raw message