avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Locators
Date Mon, 09 Dec 2002 10:17:31 GMT

Noel J. Bergman wrote:

>Well, I don't think that we're quite agreeing, yet, but we'll get there.

I have every confidence!

>Personally, I think you are too focused on static assembly, and how things
>are done in the code today.

Static? Don't thinks so.  
How things are done today ? Maybe.

>For one thing, I would be perfectly happy to discard backward compatibility
>to get a clean, forward-reaching, stable solution.  I'll change the code in
>James if we get value from it.  Heck, we've had to change it enough times
>already tracking changes to the interfaces.  What's one more if it finally
>gets us to a non-fragile interface?  We're not talking about everything;
>we're talking about a couple of very important areas that appear to need it.
>So why not start clean, and see what comes out?

1. Because I have a lot of 4.1 content.
2. Because I want to provide a seamless migration path.
3. Because I don;t see a conflict at this tiime.

>Hypothesize that a component sees a single Context.  


>>From that Context, it
>can request other objects.  OK, how do they get there?  Well, I would argue
>that there are two distinct issues:
>  1) Registration of top level context domains with the Context.


>  2) Registration of objects with context domains.


>I maintain that those are two separate issues.  


>The Context should only be
>concerned with registration of context domains.  I referred to them as top
>level with the idea that in theory a JNDI context domain *could* in theory
>have some further sub-domains, but that is it's problem, not the Context's.

Yep, agreed.

>Objects are registered with the context domain into which they go, not with

Yep - the thinking I have concerning Locator is that it represents a 
single context domain.

Emails yesterday from Leo Sutic and myself were digging into the 
multiple context domain issue.

>And although we would want to define a general common mechanism,
>there might be others.  For example, consider Chad Stansbury's comment that
>someday he expects to retrieve JINI services via a Context.  We wouldn't do
>ANY assembly within the domain!  The only thing that you can and should know
>is to associate that context domain with the Context.  The context domain
>will have to take care of itself.  In point of fact, the contents of that
>domain would change over time.

No problem.

>On the other hand, for the standard context domains that are defined by the
>container profiles, we will probably have a more typical model.  I might
>register a factory for a given implementation class, and associate that with
>a namespace specific key in a specified domain.  Perhaps something like:
>  <context-domain name="ns" factory="cdf">
>     <contents>
>       <object name="config-name" key="ns-key" />
>     </contents>
>  </context-domain>
>  <object name="config-name" factory="ojbf" >
>     <dependencies>
>       <object uri="URI" />
>     </dependencies>
>  </object>
>That is off-the-cuff, and intended only to convey a specific concept.  The
>first element declares a domain with some contents, the second one defines
>an object that happens to have some dependencies.  The domain is responsible
>for dealing with its own child elements.  In this case, there is a block
>telling it about some objects to populate itself with.  The domain is also
>free to declare other objects on its own.  The object is saying that it has
>dependencies that it would like enforced by the container.  Note that
>although we can use a namespace specific key within the context-domain
>definition, we use the full URI when defining a dependency because the
>contract is that only a domain knows about its contents.

What your describing is almost one-to-one with what I have in mind with 
the locator abstraction.  The only difference is that I'm seperating out 
the context domain as a meta-based service within supplimentary 
information concerning keys.

Consider the following:

  From the DemoComponent.xinfo file.
  This is a container-side component that handles the establishment of a
  DemoLocator service. It declares dependecies on the standard avalon 
  entry for a working directory, and a compoinet capable of providing a
  service called DemoLocator which is defined in a seperate service meta



        <entry key="urn:avalon:work" type="java.io.File"/>
        <service key="urn:demo:basic"

      <service type="org.apache.avalon.playground.DemoLocator" 


  From the DemoLocator.xservice file.
  This is the meta for the DemoLocator service defintion.  Unlike normal
  service definitions, it includes a bunch of entry declarations which
  define the lookup contract with respect to keys and returned classes.
  This defintion provides everything you need to build a context domain
  that can be access by key or by sugar coated interface (i.e. its a
  client decision).

      <entry key="urn:avalon:work" type="java.io.File"/>
      <entry key="urn:demo:simple" 

  In the client component type descriptor.
  Instead of defining a bunch of keys and types, we simply define the
  context service domain (in this case a service providing DemoLocator).



      <context locator="org.apache.avalon.playground.DemoLocator"/>


Keep in mind that none of thnis exists - its just what I have in my head 
at the moment in terms of a pragmatic approach to plug-in context 
domains.  On the other-hand, all of the above is within the spectrum of 
rapidly achievable.

>Earlier, I said that perhaps you are too focused on static assembly.  You
>can return the favor by pointing out that I am ignoring some issues.
>Possibly so (especially at 4AM :-)).  But hopefully everyone learns through
>the process, and we arrive at something mutually satisfactory.

Two ponts I should raise - and nothing to do with you not having read 
something or a 04:00 in the morning syndrone - it's stuff I know and 
havn't taked about much.  

1. Any time you see a <type> ... </type> - keep in mind that
   this can be build programatically and supplied to an assembly
   engine, and then pumped to a client. I.e. if your coding on
   the contaier-side, creation will be drop-dead-easy.

2. And, I am working (as we speak) on a dynamic component model -
   its a model in which the meta data is not derived from static
   information, but instead - its build and maintained at
   runtime.  This is basically work related to the notion of a
   component block - the block is itself is a component that
   encapsulated a container heierachy, imports services from
   other blocks, and exports a subset of the services if
   manages internally.

What does this mean to you - it means that you can transfor the entire 
James system into a single component, maybe a unique context domain, 
maybe a single service.  It means things like a mailet can be deployed 
as a single packaged unit (jar file) that is dynamically transformed 
into a functional top-level componet.

But item (2) is bleeding edge.


>As principles, I'd like to suggest that things be kept simple, clean, and
>flexible.  Nothing more complex than it needs to be, and complexity is
>layered and optional.


Which is why I'm thinking/focussing on single context domains for the 

Priority for me is to be able to deliver a single pluggable context 
domains / service domain.  With that in place, its a short walk to 
multiple domains - but that's a second step.

Cheers, Steve.

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


Stephen J. McConnell

digital products for a global economy

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