You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/11/12 21:52:03 UTC
XFC / Fortress integration
On Tue, 12 Nov 2002 14:05, Berin Loritsch wrote:
> > BTW one thing that someone has asked me to do (though I no
> > agree yet) is to
> > make a ECMContainer for Fortress. This container would
> > essentially provide an
> > interface identical to ECM (same config files and
> > autodiscover handlers). Any
> > comments on this? Good idea/bad idea/hard idea? It **looks**
> > like something
> > easy to do atm but ...
>
> It is easy to do. There is also the cross config package that
> should bridge the gaps dynamically. It is Excalibur XFC. If
> that solve the problem (i.e. can be used at runtime), then there
> really isn't a need for YAC (yet another container).
I agree - better to remove the need for the container. Marcus what do you
think would be best? I had a look at the code and it looks to be more general
than is really required in the container. It may be simpler to do the
transformation in fortress directly. XFC would still be required to migrate
applications properly but one way runtime transform could be done in
fortress.
Thoughts?
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XFC / Fortress integration
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>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.
>
Pete:
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;
>
>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.
>
>
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.
>(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
>
You should add to you list the excalibur/meta package as this directly
address aspects concerning environment establishment.
http://jakarta.apache.org/avalon/excalibur/meta/
>
>(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.
>
>
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).
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XFC / Fortress integration
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XFC / Fortress integration
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Peter,
On Wed, Nov 13, 2002 at 07:52:03AM +1100, Peter Donald wrote:
> On Tue, 12 Nov 2002 14:05, Berin Loritsch wrote:
> > It is easy to do. There is also the cross config package that
> > should bridge the gaps dynamically. It is Excalibur XFC. If
> > that solve the problem (i.e. can be used at runtime), then there
> > really isn't a need for YAC (yet another container).
>
> I agree - better to remove the need for the container. Marcus what do you
> think would be best? I had a look at the code and it looks to be more general
> than is really required in the container. It may be simpler to do the
> transformation in fortress directly. XFC would still be required to migrate
> applications properly but one way runtime transform could be done in
> fortress.
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.
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.
Stephen and I talked about this when I was in Paris recently,
and was part of the reason why he moved the Merlin model package out
into meta.
The idea is based on the assumption that all containers essentially
manage their components internally in a similar way. There are
differences w.r.t how (ie. async. event based in Fortress, sync.
linear based in ECM, .xfiles approach in Merlin, etc), but once
components are loaded into their respective containers they're
basically managed in some similar way, ie. hashmap with some
accessor methods.
So, with this being the case, we could extract the best parts from all
our existing containers into a 'model' package that any container
could use. This would free container implementations of that
effort and allow them to focus on other things (eg. hierarchical
support, kernel management, classloader issues, threading, etc, etc).
It would also mean that we could write different backend's for this
'model' package, allowing it to support the current and any future
style of configuration files, and providing backwards
compatibility for older style config files in the newer containers.
Something like this:
Config Model Container impl. Client code
|------------------------|
ECM| | |-------| Merlin| |
Fortress| -> | | Model | -> Fortress| | -> component access
Merlin | |-------| etc |
|------------------------|
The model:
|------------------------|
| |-----| |-----| |-----||
| |Fort.| |Merl.| |ECM. || Backends support current/future containers
| |-----| |-----| |-----||
| |
| Model | Internal model of configured components
|------------------------|
API Container oriented API
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 :)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>