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.
There will never be a problem with urn:avalon.name or urn:avalon.classloader. As to urn:avalon.partition.name, what does that map to if the container does not support partitions?
With the *.home.dir and *.temp.dir, not all environments map well to the way it is currently defined. The prime example is the *.home.dir and the Servlet environment. With servlets, the resources are supposed to be accessed via URL--because there is no guarantee that the resource is not part of a packed WAR file. There is a workaround--but it is not required for all servlet engines to allow for it (the findRealPath method in the ServletContext). Other times it is just simply the fact that the container is ultra-simple and does not offer access to the filesystem (which may be a requirement for sandboxed components).
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.
I understand that we still need a common set of context entries, but by using a namespace based approach, we can properly verify wether the container implements that set. The core entries that are component specific will always be available, but other entries may only be necessary in some environments. We can say that we support a set (a namespace) of entries, and the container can easily validate that the set is implemented.
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.
All I am saying is that by allowing it to be defined in a container extension (not the only method, but one of them), all containers can easily comply with the requirements for that extension. We don't have to manage a set of context entries separately from that. I imagine in most cases the only time a container extension would have to mess with context entries is to manage the lifecycle extensions.
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?
Ok. I am not looking at the meta-info at all in this thread. I am strictly speaking of the org.apache.avalon.framework.context.Context object passed in to the component. I think the standard tags for context validation should stand, and still apply. I am not looking to change them.
What I am looking at is providing room for the "Container Extension" concept by declaring a set namespace for a whole set of functionality. It is using the Container Extention to address an entire concern area. The container extension would specify everything it provides in its meta information/data--a topic that can be explored later on.
The core thing I am hinting at is that a namespace when it is used in an Avalon component refers to a concern area. For example, we may want to dynamically instrument components with measurements like accesses/sec or average time for a method to run. This concern area would be addressed by the hypothetical concern namespace "instrument". All meta information and context entries that are specific to the "instrument" namespace would be encapsulated in the container extension that supplies that concern area.
Using this approach, the container extensions provide a standard way for the container to ensure that the components comply with the requirements for the extension.
Keep in mind that I think that an abstract extension framework at this stage is premature.
Understood. We can lay down general concepts however that lay the foundation. We have identifies a number of concern areas that would best fit into the container extension concept:
* Instrumentation * Management Extensions * Remoting
(that's just the short list).
So I am keeping these things in mind, trying to simplify the core avalon namespace so that a container that does not choose to support container extensions can do the following:
1) detect if the extension is required 2) fail early if the component cannot be run without extensions 3) work with all the components in avalon-component
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.
I am hoping we were just crossing signals here. I may be having problems expressing what is rolling around in my head--its real clear to me ;).
--
"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]
