You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2002/12/08 14:16:36 UTC
Re: Locators
Leo Sutic wrote:
> Stephen,
>
> OK, now I get it. I thought that the lookup operation would be
> replaced by casting, so that if I had a component that had a
> dependency on, say, StoreService and ConnectionPool, I would do this:
>
> public void service (Locator locator) {
> StoreService ss = (StoreService) locator;
> ConnectionPool cp = (ConnectionPool) locator;
> }
>
> That was the root of my "but method names will conflict" post.
Ok, understand.
The casting I was refering to was the "type of locator" - which simply
brings your to a sugar-coated locator. The inclusion of the <service>
element only provides a keyed entry - it did not (or was not intended to
imply) casting to a service interface. But looking back at my email -
that wasn't so clear!
>
> I think your proposal and mine are very similar.
That's may impression as well.
>
> We both allow the component to declare a context with any key-value
> mappings, and you extend it to allow even services to be accessed via
> a context. Where you have the component cast the context interface to
> multiple locator interfaces:
>
> That is,
>
> <context>
> <locator type="org.a.a.f.context.SystemLocator" version="4.1.2"/>
> <locator type="org.a.j.MailetLocator" version="2"/>
> </context>
>
> means that:
>
> public void contextualize( Locator locator ) throws
> LocatorException {
> SystemLocator system = (SystemLocator) locator;
> MailetLocator mailet = (MailetLocator) locator;
> }
>
> is valid.
>
> I would aggregate the two interfaces like this:
>
> interface MyLocator extends SystemLocator, MailetLocator {}
Me too.
However, keep in mind that the meta model should support this. In other
words, a locator service meta (as distinct from a locator implementation
meta) should be declaring the keys it provides, and the super type
service meta is is derived from. Given that - it will be possible to
establish key conflicts during build time.
>
> declare it like this:
>
> <context>
> <locator type="MyLocator" version="4"/>
> </context>
>
> and then do this:
>
> public void contextualize( Locator locator ) throws
> LocatorException {
> MyLocator myLocator = (MyLocator) locator;
> }
>
> Is the above a correct understanding of your Locators?
Yep.
I'm also thinking that it is reasonable to break out the single locator
verus locator aggregation. If locator service interfaces use
inheritance and that inheritance is backed be equivalent meta, then, in
the first instance I don't think we need to worry about delivering
aggregation of multiple locator instances just yet. The key thing is
the delivery of the ability of component writters to write their own
locators and have these as a standard mechanisms across different
containers. In effect, the locator becomes an important part of the
container-side customization of a system.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen,
>
>
>
>>Yep - the thinking I have concerning Locator is that it represents a
>>single context domain.
>>
>>
>
>I think I see the issue, perhaps. To translate terms, your locator seems to
>be a context domain, not a context. In my model, a context knows only about
>context domains, not other objects. Client code never sees a context domain
>directly; they are opaque inside the context.
>
>The role of context is to figure out which context domain handles the URI.
>It delegates everything else to the context domain.
>
>Therefore, I don't want a consuming component to see what you call a locator
>when it is looking for something. I am asking for that outer wrapper.
>
OK, let me back-track a little.
Take the following scenario:
public void contextualize( Context context )
{
File file = (File) context.get( "urn:avalon:work" );
}
The implementation of Context in the above example could be:
public Object get( String key ) throws ContextException
{
return m_locator.locate( key );
}
In this scenario, the locator managed by the context implementation is
simply implementing the notion of key based lookup. This is independent
of any issues concerning context domain - i.e. the value proposition is
a standard interface (Locator) that can be implemeted by components that
act as the provider of the service of locating objects based on requests
when embedded inside things like Context, ServiceManager or
ComponentManager instances.
This specifically addresses the ability for the introduction of custom
locator implementation within a containement environment - where
implementation differentiate themselves in terms of (a) the context keys
they support, and (b) syntatic sugar that thay can provide.
But lets take a step forward in complexity and consider a Locator that
is acting as a locator of other Locator instances (which is getting very
close to you notion of context implemetation as the access to a context
domain).
public void contextualize( Context context )
{
// classic context
File file = context.get( "urn:avalon:work" );
// narrowed to a context domain
StandardContext standard =
(StandardContext) context.get( "urn:avalon.standard.context" );
// using context domain
File work = standard.getWorkDirectory();
}
When we look the above example we are seeing two types of usage. First
- context as a context domain lookup, and secondly, degenerative lookup
in the case of "urn:avalon:work" which is presumably redirectred to the
"urn:avalon.standard.context" context domain. The aspect of casting can
be handled via a proxy that simply presents the m_locator interface as
an instance of Context and StandardContext (based on info associated
with the locator service defintion).
So far we are looking at examples where there is one locator object that
is handling the implementation of the Context instance. Based on your
emails together with Leo's summary, there is also the potential subject
of the management of multiple context domains.
public void contextualize( Context context )
{
// narrowed to a context domain
StandardContext standard =
(StandardContext) context.get( "urn:avalon.standard.context" );
// narrowed to a context domain
EnterpriseContext enterprise =
(EnterpriseContext) context.get( "urn:avalon.enterprise.context" );
}
In the above example, while we may be accessing different context
domains, this is for all intensive purposes transparent to the client.
To more completely present this scenario, lets include the root context
as context domain:
public void contextualize( Context context )
{
SystemContext system = (SystemContext) context;
StandardContext standard = getStandardContext();
EnterpriseContext enterprise = getEnterpriseContext();
}
In terms of implementation, we have a locator that implements
SystemContext that is being proxied under the Context interface. It
provides values based on keys and support for convinience operations as
show above. These convinience operations happen in this example to be
returning different context domain objects - but as far as the locator
service is concernined, its simply providing a sealable, proxiable
lookup mechanism.
>
>>What your describing is almost one-to-one with what I have in mind with
>>the locator abstraction.
>>
>>
>
>I think we are agreeing.
>
>
:-)
I keeping my fingures crossed and hoping that after readying the above
you will still be agreeing!
>
>
>>The only difference is that I'm seperating out the
>>context domain as a meta-based service within
>>supplimentary information concerning keys.
>>
>>
>
>That feels like implementation, not architecture.
>
OK - let me rephrase this - I'm seperating the notion of resource
location from the notion of what is context. I am also also stating the
an implementation strategy for a locator solution can be container
dependent, and finally, that the defintion of thigns like keys are part
of the locator service definition - not part of the component.
>
>>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.
>>
>>
>
>
>
>>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.
>>
>>
>
>We had previously agreed that everything that could be expressed via XML
>would be supported via API, so I didn't feel it was necessary to reiterate.
>
>
>
>>>I'd like to suggest that things be kept simple, clean, and
>>>flexible.
>>>
>>>
>
>
>
>>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.
>>
>>
>
>My belief is that we need the context / context domain separation I raised
>in order to achieve "the pluggable context domains / service domain" that
>you are stating as a priority.
>
You will have probably noticed that I'm not making a computation
distinction between context domains - the descriptions provided above
deal with a root contex domain (established by a locator and typically
proxied into a interface object). Access to alternative context domains
is assumed to be via classic context access mechanism (i.e. basic object
lookup). If I understand correctly, what I'm proposing would meet the
seperation requiremets your outlining without the need to take that
abstraction into the implementation. Does that sound reasonable (and
it's my turn to say that at 3:30 in the morning is possible that it's
unreasonable).
:-)
>
>I'll make a further claim. The interface to Context will be more stable
>than the interface to context domains, especially during early development.
>That is OK because my components don't see the context domain interface.
>
This is my thinking too - if the Context object is associated with
exactly one interface type (Context or an interface derived from
Context), and that interface defintion includes key specifications, we a
rather solid platform.
Cheers, Steve.
>
>
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Locators
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
> Yep - the thinking I have concerning Locator is that it represents a
> single context domain.
I think I see the issue, perhaps. To translate terms, your locator seems to
be a context domain, not a context. In my model, a context knows only about
context domains, not other objects. Client code never sees a context domain
directly; they are opaque inside the context.
The role of context is to figure out which context domain handles the URI.
It delegates everything else to the context domain.
Therefore, I don't want a consuming component to see what you call a locator
when it is looking for something. I am asking for that outer wrapper.
> What your describing is almost one-to-one with what I have in mind with
> the locator abstraction.
I think we are agreeing.
> The only difference is that I'm seperating out the
> context domain as a meta-based service within
> supplimentary information concerning keys.
That feels like implementation, not architecture.
> 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.
> 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.
We had previously agreed that everything that could be expressed via XML
would be supported via API, so I didn't feel it was necessary to reiterate.
> > I'd like to suggest that things be kept simple, clean, and
> > flexible.
> 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.
My belief is that we need the context / context domain separation I raised
in order to achieve "the pluggable context domains / service domain" that
you are stating as a priority.
I'll make a further claim. The interface to Context will be more stable
than the interface to context domains, especially during early development.
That is OK because my components don't see the context domain interface.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators
Posted by Stephen McConnell <mc...@apache.org>.
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 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.
>
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.
>
>Objects are registered with the context domain into which they go, not with
>contexts.
>
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
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.
>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.
>
Yep.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Locators
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
Well, I don't think that we're quite agreeing, yet, but we'll get there.
:-)
Personally, I think you are too focused on static assembly, and how things
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?
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.
Objects are registered with the context domain into which they go, not with
contexts. 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.
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.
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.
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.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Just a note - IS-A can define the HAS-A contact (providing meta is
>>provided against the IS-A interface declaring the set of entries).
>>
>>
>
>The issue is that IS-A is an inherently coupled relationship. As a TYPE,
>you do not want to cast contexts. You do not want to couple the client code
>with any inherited implementation.
>
>
>
>>I'm convergin on the same opinion - one locator is sufficient.
>>
>>
>
>That will please me greatly, especially if the Community follows suit.
>
>I do assume from the context of our other discussions that you mean one
>object exposed to the client. Possibly multiple internal "sub-contexts"
>that provide the service as required for a given lookup.
>
>
>
>> <type>
>> <context locator="o.a.a.p.BlockContext" version="2.1"/>
>> </type>
>>
>>
>
>How literally am I to take that? You aren't really proposing BlockContext
>as the actual iterface, are you? I don't expect that you are, but
>clarification won't hurt.
>
Nope.
:-)
I'm applying the same logic that is used to find and deploy lifecycle
extension handlers.
The locator attribute tag declares:
(a) that the container has to locate a component exposing
meta that declares itself as a locator (basically a meta
type that extends "Type" with the attition of one or more
interfaces it can be proxied as, and the set of lookup
tags that it supports
and the locator attribute value declares:
(b) that the locator component must provide or implement the
interface class - which the container resolves through
the additional meta information
The container treats the locator as a classic component, assembles and
establishes the Locator instance and plugs this in as the source of
context or service management requests behind the respective Context or
ServiceManager. An actual Context object can be created as a proxy by
the container wrapping the Locator instance. In addition, would also be
possible to provide a common locate operation on both Context and
ServiceManager so that the same samantics can be used for both
contextualize and service (and in a way that does not break backward
compatibility).
This means that something like BlockContext can be implememntated as a
classic component (with depedencies, its own context criteria,
configuration, etc.) and dynamically plugged into a target component.
Cheers, Steve.
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Locators
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Just a note - IS-A can define the HAS-A contact (providing meta is
> provided against the IS-A interface declaring the set of entries).
The issue is that IS-A is an inherently coupled relationship. As a TYPE,
you do not want to cast contexts. You do not want to couple the client code
with any inherited implementation.
> I'm convergin on the same opinion - one locator is sufficient.
That will please me greatly, especially if the Community follows suit.
I do assume from the context of our other discussions that you mean one
object exposed to the client. Possibly multiple internal "sub-contexts"
that provide the service as required for a given lookup.
> <type>
> <context locator="o.a.a.p.BlockContext" version="2.1"/>
> </type>
How literally am I to take that? You aren't really proposing BlockContext
as the actual iterface, are you? I don't expect that you are, but
clarification won't hurt.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Locators
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>The casting I was refering to was the "type of locator"
>>
>
>Why do we need more than one TYPE (interface)? Define a consistent,
>uniform, SINGLE, interface. Aggregate by reference and naming space, as we
>discussed previously with respect to URNs.
>
>
>>>I would aggregate the two interfaces like this:
>>> interface MyLocator extends SystemLocator, MailetLocator {}
>>>
>>Me too.
>>
>
>Oiy ... please don't make me do it. Please don't make me explain about IS-A
>and HAS-A again.
>
Just a note - IS-A can define the HAS-A contact (providing meta is
provided against the IS-A interface declaring the set of entries).
>
>A Component should see a single "locator" object that provides access to
>other objects.
>
As your reading though this stuff you will see that I'm convergin on the
same opinion - one locator is sufficient.
I.e. the current:
<type>
<context type="o.a.a.p.BlockContext">
<entry key="apps.dir" type="java.io.File"/>
<!-- etc. -->
</context>
</type>
Can be replaced by:
<type>
<context locator="o.a.a.p.BlockContext" version="2.1"/>
</type>
>
>The "meta-model" should provide the information necessary to register what
>is in the context. And there should be APIs for dynamic registation.
>
Agreed.
>
>IMO, a Context should be a provider of objects within a given, well,
>"context." Those objects provide data and/or services. Some of those
>objects are well-defined and provided by the Container profiles. Other
>objects are defined by third parties, and usable primarily by others
>expecting those third party entries. The preceeding does not mean that a
>third party can't replace a profile defined object, given the correct
>administrative rights.
>
Yep.
Cheers, Steve.
>
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Locators
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The casting I was refering to was the "type of locator"
Why do we need more than one TYPE (interface)? Define a consistent,
uniform, SINGLE, interface. Aggregate by reference and naming space, as we
discussed previously with respect to URNs.
> > I would aggregate the two interfaces like this:
> > interface MyLocator extends SystemLocator, MailetLocator {}
> Me too.
Oiy ... please don't make me do it. Please don't make me explain about IS-A
and HAS-A again.
A Component should see a single "locator" object that provides access to
other objects.
The "meta-model" should provide the information necessary to register what
is in the context. And there should be APIs for dynamic registation.
IMO, a Context should be a provider of objects within a given, well,
"context." Those objects provide data and/or services. Some of those
objects are well-defined and provided by the Container profiles. Other
objects are defined by third parties, and usable primarily by others
expecting those third party entries. The preceeding does not mean that a
third party can't replace a profile defined object, given the correct
administrative rights.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>