avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Context Entries
Date Tue, 22 Jul 2003 19:12:08 GMT


Berin Loritsch wrote:

> Since we are well underway with the AMTAGS proposal, I wanted to start my
> thoughts on context entries. Currently we have two basic approaches for
> context keys:
>
> * Using URNs
> * Using opaque strings
>
> Truth be told, there is no real advantage to using one over the other 
> from
> a purely technical standpoint. The only tangible advantage comes from the
> management perspective. In fact, the URN makes for much easier scoping of
> context entries. A Universal Resource Name helps us understand that the
> resource belongs to a namespace, and has a unique name within that 
> namespace.
> Whether that resource lives locally on the hard drive or on a remote 
> server
> does not matter, we can use the same name to access it. That is its 
> strength.
>
> A Resource has specific properties. A resource accessible from a specific
> name will always be the same exact resource. That means if the 
> resource is
> text, the return value will be text. If the resource is a URL, the value
> will always be a URL when accessed by that name. We can use two URNs to
> refer to the same logical thing, but if the logical thing is represented
> differently, they are separate resources. For example, a File 
> representing
> the application home directory and a URL representing the same thing are
> distinct resources.
>
> That said, I like the strength of URNs for management purposes. I 
> think that
> Merlin is on the right track with using URNs internally. I believe 
> that the
> @avalon.entry tag provides for the use of an alias, much the same way as
> the @avalon.dependency does the same thing when we refer to a type.
>
> A URN is composed of three elements:
>
> * The text "urn:" which identifies a string as a URN.
> * The namespace which precedes the following ":" and comes after the 
> above text
> * The actual name of the resource
>
> Examples would be:
>
> urn:avalon:name -- Avalon component name
> urn:application:home/file -- Application home as a File
>
> I think we need to be very strict on what we allow in a URN namespace. 
> For
> example things that help components with management such as the component
> name or logger category can go in the Avalon namespace. All other 
> things like
> application home/partition home/etc. should go in their own namespaces. 


I think this is not address the actual needs that are already 
identified. If we consider the James project, they has gone though a 
process of abstracting out context entry key lookups to a separate 
utility class as part of the process of establishing container 
neutrality. This extra code exist because we have not defining the very 
basic set of common context entries. I think this is well overdue. 
Getting in place a common core set of entries is real easy to do. I've 
already proposed the following:

urn:avalon.name
urn:avalon.partition.name
urn.avalon.home.dir
urn:avalon.temp.dir
urn:avalon.classloader

Are there really any problems mapping the above into any avalon 
container? I don’t think. I do know that the benefit to the end user 
will be immediate and tangible.

> That
> way we can specify them as we specify namespaces. I believe this 
> approach will
> provide the most flexible and sustainable method of managing the context
> functionality of Avalon.


The need for a core set of common context entries remains. Simply 
stating what the keys are that can be used consistently across 
containers does not conflict with different context management solutions 
provided by different containers. What is does do is set a minimal level 
of utility for a portable Avalon contextulizable interface.

>
> In fact we can identify this as an area that we need to provide for with
> container extensions. A container extension needs to provide the context
> entries that it provides from its namespace.


The existing spec for @avalon.context provides support for the 
declaration of context entry requirements independently of a containers 
context management solution. I don't definitely don’t think we should 
move this into the notion of extension - its well defined - meets 
immediate requirements - and is part of the core Avalon model.

> If the context entry is not
> volatile, then its value should be able to be overridden in the assembly
> stage--but that is a matter for another discussion.


It’s a container problem - all the meta-info has to do is declare the 
constraint. Meta-data (out of scope for the moment) deals with the 
problem of building/declaring how to create special context content.

>
> I also think that by employing this general solution, we can avoid a 
> bunch
> of unnecessary conflict between those trying to keep the Avalon namespace
> small and those trying to enable a set of functionality.


Can you qualify this a bit more - I got the impression your hinting at 
something but I don’t know exactly what you’re hinting at. Personally I 
can't think of anything I would want to modify in the current 
@avalon.context and @avalon.type (and corresponding XML) relative to the 
existing implementation. Do you see any issues?

>
> Phoenix and Fortress need to reconcile their commonalities and possibly
> define some context entries for the application namespace. That way we
> can specify common namespaces for extensions like the "lifecycle" 
> extension
> or the "management" extension.


Keep in mind that I think that an abstract extension framework at this 
stage is premature.

>
> Does this proposal make sense, and be easy enough to implement?


Not really - I think its makes things unnecessarily complex. We have a 
simple system that works well I think we should focus on closing the 
configuration schema declaration as part of the type definition - 
finalize the attribute spec details - and that's it. W can safely evolve 
the meta-info platform because it’s based on a version schema 
identifier. I really think we should keep things as simple as possible - 
get things in place across containers - go though a learning curve - and 
with experience come back to the entire subject of meta-info extension.

Cheers, Steve.


-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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


Mime
View raw message