avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject RE: reduction ad unum
Date Sun, 24 Nov 2002 16:11:12 GMT
On Sun, 2002-11-24 at 13:26, Leo Sutic wrote:
> --------------------------
> (In the spirit of "if I keep repeating it, it will be true".)
> The Context can be seen as a set of operations or services
> that the container provides to the component.

I disagree. I think the Context should be seen as a set of
runtime/environmental data that the container provides to the component,
not as containing operations or services. get() is okay, set() or do()
is not.

I think having a container provide anything classified as "service" to a
hosted component is not a good idea; the scope of the container should
be as limited as possible. ie be rigorous about IoC and SoC.

> These services
> may be simple getters:
>    File getHomeDirectory ();

I wouldn't call a home directory a service ;)

> or performance information:
>    long getSystemUptime ();
>    long getSystemIdleTicks ();

system information is not a service either I think ;)

> or ways for the component to request actions of the container:
>    void requestShutdown ();

this I (still) don't like. Where's the IoC/SoC?


sample container pseudocode
  __init__( container, componentProfile ) {}

  lookup( key )
    if(key.equals(CONTAINER_CONTROLLER) &&
        return container.getController();

sample component pseudocode
MyComponentImpl {
  service( sm )
    controller = (ContainerController)sm.lookup(CONTAINER_CONTROLLER);
  forsomereasonperhapssocketcalloverthenetwork() {

> OK, so the problem now is:
>   1. How does the component specify R?
>   2. How does the container provide R?
> My solution is:
>   1. The component writer creates an interface that extends those
>      atomic interfaces (RequestShutdownable etc.) whose operations
>      it requires. Call this interface ComponentContext.
>      The component then declares that as its desired context
>      interface.
>      This guarantees the following:
>        +  The context object passed in to the contextualize
>           method can be casted to ComponentContext.

- well-known rather atomic interfaces (and hence quite a few) dealing
with container behaviour become part of the core framework (ie what is
shared between containers)
- lots of "extends" and "implements"
- a coding convention where a component with name MyFooBarComponent
provides MyFoorBarComponentContextInterface (or other mechanism for
defining desired component context interface)

in essence what you do is making the component writer define component
metadata by providing a (set of, perhaps ComponentConfiguration too)
interfaces (as opposed to making him define component metadata in a
configuration file).

The guarantee you get from this is just as good or bad as the one you
would get from defining the metadata in a config file (or dynamically
runtime-constructed metadata object).

>   2. The container needs to do two things: First, verify that
>      it can indeed provide all the operations. Second, provide
>      them via the required interface.
>      The container must have some implementation of a Context.
>      Each operation is basically defined by a method signature.
>      Thus, it should be trivial to confirm that R is a subset of
>      P,  or abort if it isn't.
>      The container can now create a dynamic proxy object that
>      implements the required context interface. Method calls
>      through the ComponentContext interface are routed as
>      needed to the methods of the context implementation.

I think there's "too much magic" here, and I furthermore cannot really
see the benefit of all that magic. I guess I'm missing the KISS and the
XP concepts.


- Leo

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