Hi, On Thu, 14 Nov 2002 00:42, Marcus Crafter wrote: > This would be fine. You could bundle the required XFC classes with > 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.
Kool ... volunteering to do it ? I would really like that capability prior to release :) > 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' > could use any other containers configurations, assuming there's a > backend written to support it. > > What do you think ? Am I dreaming :) 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. 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; 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 stuff * policy: policy stuff * ThreadContext: maintaining threadContext even when crossin boundaries * jprocess: attempt at bringing together ThreadProcess to isolate different parts of the environment (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, Peter Donald -------------------------------------------------- "An intellectual is someone who has been educated beyond their intelligence." -------------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
