Peter Donald wrote:
Hi,Pete:
On Thu, 14 Nov 2002 00:42, Marcus Crafter wrote:
This would be fine. You could bundle the required XFC classes withKool ... volunteering to do it ? I would really like that capability prior to release :)
Fortress and just set up the input/output modules to convert one
way ECM to Fortress. I don't see a problem there, and for Fortress
this would be nice.
Random thought coming......
On the long term and grand scale :) I had a few thoughts about
creating a common container 'model' that could be used across all
containers (if possible), that could support arbitrary backends.
The thought came to me while I was writing parts of XFC.
If we could nail this, then any container that uses the 'model'It is a thought that has occured before and was going to part of the containerkit model prior to the blow up. However that is a model that is much harder to achieve than metadata definition and as of now we don't even have that model in common.
could use any other containers configurations, assuming there's a
backend written to support it.
What do you think ? Am I dreaming :)
What are the functional requirements you see as necessary over an above the current excalibur/meta package?
Essentially there is 4 types of different information that would need to be able to be modelled for such an evolution to take place. Essentially these are;Generally yes - but this is also addressable through a declarive approach - for example, the excalibur/meta package include not only the low level type model, but also the declarative criteria on which the environment can be expressed as container depedencies (as distinct from component centric service dependecies), and descriptors that provide containers an open mechanisms for the creation of resources required by components to properly function.
1. component configuration
2. component assembly
3. component environment 4. component aspects (for lack of a better term)
Some would also separate out
5. Logging
(1) and (2) are relatively easy to model and are already in place. They just need to be brought together and homogenized. The other Peter is actually working towards that with (1) (whether he knows it or not ;]). (2) is simple. (5) is relatively simple - especially if we base it on existing work.
(3) and (4) are much much harder to model. The main reason being that they are implicitly defined with respect to a parent container.
(3)/Environment stuff such as classloader stuff, policy stuff, thread stuff, URLContentHandlers, System.io/out redirection are all things that are provided in the parent container and are things that are a lot harder to standardize on. You can see parts of the picture in various different excalibur projects. * loader: classloader stuffYou should add to you list the excalibur/meta package as this directly address aspects concerning environment establishment.
* policy: policy stuff
* ThreadContext: maintaining threadContext even when crossin boundaries
* jprocess: attempt at bringing together ThreadProcess to isolate different parts of the environment
http://jakarta.apache.org/avalon/excalibur/meta/
I have a differnet take on this. Based on looking at and playing with Fortress and ECM stuff - I don't see any obsticles to the creation of a meta model. In fact the recent work on excalibur/meta has been undertaken specifically to enable this. The objective is to be able (via XFC) to suck in ECM structured information and from that build programatically the meta model enabling those components to run without modification in other environments such as Merlin. This is also consistent with the Fortress meta container approach. Within a ECM/Merlin model in place we will have the complete story for Foress - combined with support for Phoneix meta (because Phoneix meta is already supported in the excalibur/meta package).
(4) also requires the notion of a parent container as the interceptors will need to aquire services from parent and possibly be workin in mixed "environments"
Interesting idea but something that is not really within our grasp atm.
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: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
