The Context object (Contexualizable) is one of those things that is necessarily very flexible. It means different things in different systems. As long as it is used consistently, everything is fine. It is when there is inconsistency in a system that we have problems.
There have been many concepts and ideas tossed around, but we need to unify them. In this case that means we need to start talking the same language and working with the same concerns. We should leave the container aspect wide open for implementation details, but the user (i.e. the component writer) is the primary concern for this discussion.
For that reason, I would like us to focus on how the *user* identifies context entries and how the *user* accesses them. The container can do what it wants to as long as the user does not have to adapt for different containers.
Right now, Fortress and Phoenix share a couple common entries but that really isn't enough. I believe Stephen is on the right track in allowing the meta information to allow a container to validate that it can use a component. That is a good thing.
To that end, we would need a set of validation AMTAGS for the context entries. Looking at the problem from a 1000 foot view, we find that there are many different uses and ways of using the context. Each have their merrits, but we run into the problem of trying to identify what is the set of common context entries. Attempts in the past have stirred up the glass house and bike shed syndrome, and worse such contracts are not truly enforcable by code and subject to change over time.
I have a very radical solution for identifying common context entries. Don't. How can we have interroperable context entries then? I'm glad you asked, so here is the answer:
-oO Context Declaration and Definition 0o-
The user of a system has two separate concerns they have to worry about. The first concern has to do with declaration, much like we declare any required services that we need for our component. In fact, I propose we follow the same model that we have for services as we do for context entries. That model is that the component declares its requirements, and in assembly we identify how those requirements are fulfilled. That's right, the second concern which is defining the context entries and values belongs to application assembly.
This solution provides the maximum amount of flexibility for the application developer, while ensuring that the system can perform its validations and share information accross several components.
-oO Context Use Cases Oo-
Contexts are used in a variety of different manners. For example, one common use is to share global configuration information like the application context directory and the temp directory that a component can use. Even then there are discrepencies as to how that resource should be presented. In a Servlet environment you don't really want a "file" URL for the context directory as that is not portable, but in most cases it works quite well.
Contexts can also be used to supply runtime meta data to the component such as its "name", or some other info that might be accessible via the ServletContext object. Not to mention, some context information might be request specific, adjusted by Accessors and such.
All that says that we cannot assume that we can ensure that common names are expected to have static information. Some of that information may very well be dynamic. How do we enable dynamic context entries (like a session object)? It can be done, and we really have the technology to make that happen.
-oO Declaring our Context Requirements Oo-
In the spirit of the AMTAGS proposal, we need to simply declare our need, and not the implementation. For this reason, I would like to outline something like this:
/**
* @avalon.context ref="urn:component:name"
* @avalon.context key="classloader" ref="urn:avalon:classloader"
* @avalon.context key="app.home" ref="urn:avalon:app/home" type="URL"
* @avalon.context key="session" ref="urn:my-app:seccion" mutable="true"
*/
public void contextualize( Context context )
{
// ...
}The @avalon.context is the new AMTAGS name. The attributes' significance is outlined below:
Attribute Description
--------- -----------
key The lookup value, defaults to the "ref" entry.
ref The URN reference in the assembly file.
type The type that the component expects the value to be in,
defaults to the ref definition.
mutable True or false value letting the container know that the
component checks the value every time it is used--expecting
it to change. Defaults to false.That way we can enforce a common definition for all of these entries, or how to reference them from extensions. The lifecycle extensions or container extensions should be able to add and change values for the URN namespace that belongs to it. That means we can choose a set of context values for a namespace and work on that.
The core set of URNs would be under the namespace of "urn:avalon:", which would be easy enough to define if we know that a container extension might define another set of entries. For example I might have an application specific extension that populated values for "urn:my-app:". As long as that extension is in place, all is well.
Global context information would be set in the assembly file, which includes things like the "urn:avalon:" namespace. Also, by identifying the namespace that an extension is allowed to play with, we can easily put in security checks to ensure that the extension is well behaved. Attempts for MyAppExtension to change values in "urn:avalon:" namespace context values would allow the container to notify the administrator of a potential rogue extension.
It also allows us to set up an API where the context entries are set by URN and automatically converted to the lookup name (if it has changed). All in all, I think we will have a win/win situation.
As to the initial set of "urn:avalon:" namespace entries, let's leave that empty for the time being, and add to it as we have need. The "urn:avalon:" namespace would be reserved for truly global information, leaving component or partition specific information to the "urn:component:" and "urn:partition:" namespaces respectively.
How does this sound?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
