Noel J. Bergman wrote:
Stephen,
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 thingsStatic? Don't thinks so. How things are done today ? Maybe.
are done in the code today.
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.
OK
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.
OK
2) Registration of objects with context domains.
OK
I maintain that those are two separate issues.
Agreed.
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.
Yep - the thinking I have concerning Locator is that it represents a single context domain.
Objects are registered with the context domain into which they go, not with
contexts.
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 theWhat 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.
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.
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 context
entry for a working directory, and a compoinet capable of providing a
service called DemoLocator which is defined in a seperate service meta
model.
-->
<type>
<info>
<name>source</name>
</info>
<import>
<context>
<entry key="urn:avalon:work" type="java.io.File"/>
</context>
<services>
<service key="urn:demo:basic"
type="org.apache.avalon.playground.DemoLocator"/>
</services>
</import>
<export>
<service type="org.apache.avalon.playground.DemoLocator" version="1.0"/>
</export>
</type>
<!--
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).
-->
<service>
<version>1.0</version>
<keys>
<entry key="urn:avalon:work" type="java.io.File"/>
<entry key="urn:demo:simple" type="org.apache.avalon.playground.BasicService"/>
</keys>
</service>
<!--
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).
ClientComponent.xinfo
-->
<type>
<info>
<name>client</name>
</info>
<import>
<context locator="org.apache.avalon.playground.DemoLocator"/>
</import>
</type>
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.
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.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.
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.
;-)
Yep.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 moment.
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
