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 Royal <pr...@apache.org> on 2002/08/18 15:51:10 UTC
DTD compat -- red herring?
On Sunday 18 August 2002 06:15 am, Stephen McConnell wrote:
> Consider the following three DTDs:
>
>
> type blockinfo containerkit
>
> name yes yes yes
> version yes yes yes
> component attributes yes no yes
> services yes yes yes
> service attributes yes no yes
> depedencies yes yes yes
> dependecy attributes yes no yes
> context criteria yes no yes
> context attributes yes no yes
> stage depedenciers yes no no
> stage attributes yes no no
> extension declarations yes no no
> extension attributes yes no no
>
>
> Using the Type DTD you can define a component what can be validated by
> any container. You can deploy that component in any container in the
> knowlege that you will get a validation failure if you try to load
> something that a container does not support. Support is a container
> issue - interoperability is a subject of the DTD. The DTD is not bound
> to the API.
I think I may see pdonald's object to type support in Phoenix... *MAY*...
Why support loading a DTD that is not fully utilized? If a component is
cross-container, shouldn't it have the lowest-common-denominator DTD to
enable full portability vs having a richer DTD and the possiblity of a
container rejecting the component due to unsupported features?
Ok, we modify Phoenix to read the Type DTD, but what good does that do us if
all components that have that DTD use the features that Phoenix does not
support? What benefit do those components get from the richer DTD if they do
not utilize its features?
Is the DTD compatibility a red herring?
imho, we need to resolve the 4 no's that exist between containerkit and type.
Steve: I'm unsure of what the "extensions" are. Stage's are the lifecycle
extensions, yes? If so how to extensions fit in?
Pete: You describe some "hairy" problems
(http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
can work through them, yes?
Collectively we are a very smart bunch and can figure anything out.
Any one final thought, PLUR
(http://www.hyperreal.org/raves/spirit/plur/PLUR.html, to show my roots :) ..
and it *is* apache related.. brian behlendorf started hyperreal..
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Mon, 19 Aug 2002 20:57, Leo Simons wrote:
> It has been shown that there is need for additional non-standard
> lifecycle stages to <insert requirment here> write some components. To
> keep these components portable across containers, the code that supports
> the extension should also be portable across containers. To make that
> happen we indeed need to make sacrifices, mainly feature flexibility.
So you believe that lowering of quality is good long term strategy.
Interesting ...
I remember also thinking that way when I stopped arguing about
ComponentSelector, Component marker interface or those
ThreadSafe/Poolable/Other marker interfaces. Now everyone generally thinks
they are blights. So you think it was great idea to do that?
> > ANd would you mandate that it be
> > added into all containers or that containers could not implement it using
> > alternative strategies?
>
> nah. It just seems to me that "the most simple solution that could
> possibly work, in 90% of cases" would be nice to have in the framework.
If we followed that rule, ECM would be in framework CVS. That would be great
would it not?
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Mon, 19 Aug 2002 19:39, Leo Simons wrote:
>
>
>>>I remember quite a few people remarking how Component marker interface
>>>was a good idea, or ComponentSelector was a great idea, or that all the
>>>Poolable, Threadsafe etc interfaces were good ideas. Is this idea good in
>>>the same way?
>>>
>>>
>>what is your argument? That because some people at some point about
>>something mentioned it was a good idea where it was not means me stating
>>something else is a good idea also means it is not?
>>
>>
>>
>>>I think a little wider testing is needed before you could adopt it.
>>>
>>>
>>I feel safe adopting the idea that a common pluggable facility
>>architecture is a good idea =)
>>
>>
>
>You are free to do whatever you want. If it as all good as you seem to believe
>I am sure people will flock to it. Personally I believe that in time you will
>find yourself needing to change the API for different demands.
>
>
>
>>>JEdit is a specific container, Axis is a specific container - have you
>>>got any examples apart from CORBA where there is a common API for
>>>extending servers?
>>>
>>>
>>nah. In fact, apart from CORBA, I can't think of a common API that
>>really facilitates clean reuse across servers...except avalon.
>>
>>
>
>Servlets?
>
>
>
>>So there is an ample supply of examples of projects with clean, similar,
>>pluggable architectures, yet you feel it is impossible to extract the
>>common ground between them?
>>
>>
>
>Because as soon as you start to define the interface to server plugins rather
>than client contracts you start making tradeoffs. Compare TC3 vs TC4s notion
>of pluggable interceptors - which is "better"? TC3 is better in some
>situations (easier to use, manage and develope, especially when there is
>large numbers of intersection points for a particular concern) and TC4 is
>better in other situations (potentially better performing, uses indirection
>to allow non-linear chains).
>
>So tell me? Which in your wisdom is better? ANd would you mandate that it be
>added into all containers or that containers could not implement it using
>alternative strategies?
>
>
>
Pete:
The tradeoff in the Avalon Meta Model and the implementation in Merlin
is that an extension is a component.
Do you see a problem with that?
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: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
> On Mon, 2002-08-19 at 13:19, Nicola Ken Barozzi wrote:
>
>>Leo Simons wrote:
>>...
>
> ...
>
>>>It has been shown that there is need for additional non-standard
>>>lifecycle stages to <insert requirment here> write some components. To
>>>keep these components portable across containers, the code that supports
>>>the extension should also be portable across containers. To make that
>>>happen we indeed need to make sacrifices, mainly feature flexibility.
>>
>>One note. The fact that there would be a common way to specify
>>extensions makes components portable.
>>This is very important, and as you have seen you cannot use Cocoon
>>components OOTB, because it extends lifecycle.
>>
>>BUT...
>>
>>Is it true that we want Components to be portable across containers?
>>
>>If we have nested Containers, it seems (naively maybe?) that if we want
>>to use ComponentX in our ContainerY we can just make ComponentX one of
>>the components of ContainerY, and access the Components from there...
>>
>>ie:
>>
>> ComponentX-(hosts)- |--- ComponentX1
>> |
>> |--- ComponentX2
>>
>> ComponentY-(hosts)- |--- ComponentY1
>>
>>
>>If I want to use ComponentX1 in ContainerY I do:
>>
>> ComponentY-(hosts)- |--- ComponentY1
>> |
>> |--- ComponentX-(hosts)- |--- ComponentX1
>>
>>
>>Which means that exery Component must be distributed with his Container.
>
>
> consider:
>
> Cocoon ---(hosts)--- Fortress -(hosts)--- Phoenix -(hosts)--- ComponentX
> |
> |-(hosts)--- ComponentY
> |-(hosts)--- ComponentZ
>
> ComponentX <---depends- ComponentZ
>
> minimal call stack:
> ComponentZ.compose()
> ComponentManager.lookup()
> Cocoon.lookup()
> Fortress.lookup()
> Phoenix.lookup()
>
> as opposed to:
>
> Cocoon --
> |
> |-(hosts)--- ComponentX
> |-(hosts)--- ComponentY
> |-(hosts)--- ComponentZ
>
> minimal call stack:
> ComponentZ.compose()
> ComponentManager.lookup()
> Cocoon.lookup()
Doesn't seem a big issue.
Lookup should never be long to do, and the stack isn't so deep... ever
seen Cocoon's in Tomcat?
>>Isn't it conceptually similar to what Berin proposed with the
>>****Manager stuff?
>>Doesn't Merlin advocate a hierarchical Container system?
>
> yup, but Avalon as a whole doesn't (imagine building a hierarchy of
> phoenix kernels...) nor is it always a good idea.
>
> "to use this component inside Cocoon you have to include Merlin; to use
> it inside Turbine you have to use it inside cocoon inside Merlin".
> Hmmm....
I don't think we'll have this.
Usually one writes a Component that runs in a Container, and that can
use Components from other containers. But nobody said that they have to
be nested.
Instead of
ContainerX-(hosts)- |--- ComponentX1
|--- ComponentY1
|--- ComponentZ1
|--- ComponentALPHA1
We'll have:
ContainerX-(hosts)- |--- ComponentX1
|--- ContainerY-(hosts)----- |--- ComponentY1
|--- ContainerZ-(hosts)----- |--- ComponentZ1
|--- ContainerALPHA-(hosts)- |--- ComponentALPHA1
Containers are basically "adapters".
If ComponentX1 needs ComponentY1, it gets ContainerY and then narrows to
ComponentY1. There is only one level of indirection.
>>>>ANd would you mandate that it be
>>>>added into all containers or that containers could not implement it using
>>>>alternative strategies?
>>>
>>>
>>>nah. It just seems to me that "the most simple solution that could
>>>possibly work, in 90% of cases" would be nice to have in the framework.
>>
>>Sorry, Leo, but it seems like the ComponentSelector, Excalibur ECM,
>>etc... compromise stuff.
>
>
> there is a clear choice to do it one way (an interface to be extended by
> an "lifecycle extension module" for each of the clearly identified
> "parts"/"phases"/"stages" of the lifecycle), which is thought to be
> best. The compromise is wrt to features (it is not possible to specify
> relationship between multiple modules in the standard system, for
> example, which was a sacrifice made for flexibility).
>
> The ComponentSelector/ECM was allowed in as a compromise to get a cocoon
> release dependent on avalon (or something like that), even when some
> developers felt it was bad design. That's a different kind of compromise
> to me.
Someone still thinks it's bad design ATM, so I don't se a difference.
Until there is real agreement, I will regard this case as an "ECM case".
>>If it works 90% of the time it's just an added feature, not part of the
>>framework.
>
> the framework itself also works only 90% of the time.
Please explain.
>>>The same arguments are mostly true for other potential parts of the
>>>framework (like a common metadata model): there will always be
>>>alternative strategies that have definite advantages in some use cases,
>>>but the benefit of common ground and reusability in 90% of cases
>>>outweighs the downside.
>>
>>The 90% stands now, in some months it may be 50% then 30%... who knows.
>
> yup. But if there is no common ground in these areas the use of avalon
> in general will go from 9% to 5% to 3%....as opposed to from 9% to 30%
> to 90%...
True. This is why I want a standard way of using Components in different
Containers. Maybe Container hierarchy can make this happen.
>>>It doesn't matter whether such a meta model or lifecycle extension
>>>support is dubbed part of avalon framework or if it is called
>>>"framework++", as long as we as a project choose as much of a common
>>>solution as is possible. It just doesn't seem "wise" to have competing
>>>"frameworks" inside the same project. But hey, apparantly that's just
>>>"me" =)
>>
>>We know that in Avalon Containers are Components, both in complexity and
>>featureset.
>>
>>This is why we have many Containers coming up, as we have many Components.
>>
>>I would like to use a container that manages extensions when I think
>>it's right.
>>I would like to write *my* container that does *not* supply extensions
>>where needed.
>
>
> +1. But I want one consistent approach *within* avalon. It really does
> not make sense to have one avalon container do it one way and then have
> another avalon container that does exactly the same thing in a slightly
> different way just because some developers have decided to consistently
> disagree.
If it does exactly the same thing, I also want one only approach.
If it doesn't, we must define rules for interoperability.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-08-19 at 13:19, Nicola Ken Barozzi wrote:
>
> Leo Simons wrote:
> ...
...
> > It has been shown that there is need for additional non-standard
> > lifecycle stages to <insert requirment here> write some components. To
> > keep these components portable across containers, the code that supports
> > the extension should also be portable across containers. To make that
> > happen we indeed need to make sacrifices, mainly feature flexibility.
>
> One note. The fact that there would be a common way to specify
> extensions makes components portable.
> This is very important, and as you have seen you cannot use Cocoon
> components OOTB, because it extends lifecycle.
>
> BUT...
>
> Is it true that we want Components to be portable across containers?
>
> If we have nested Containers, it seems (naively maybe?) that if we want
> to use ComponentX in our ContainerY we can just make ComponentX one of
> the components of ContainerY, and access the Components from there...
>
> ie:
>
> ComponentX-(hosts)- |--- ComponentX1
> |
> |--- ComponentX2
>
> ComponentY-(hosts)- |--- ComponentY1
>
>
> If I want to use ComponentX1 in ContainerY I do:
>
> ComponentY-(hosts)- |--- ComponentY1
> |
> |--- ComponentX-(hosts)- |--- ComponentX1
>
>
> Which means that exery Component must be distributed with his Container.
consider:
Cocoon ---(hosts)--- Fortress -(hosts)--- Phoenix -(hosts)--- ComponentX
|
|-(hosts)--- ComponentY
|-(hosts)--- ComponentZ
ComponentX <---depends- ComponentZ
minimal call stack:
ComponentZ.compose()
ComponentManager.lookup()
Cocoon.lookup()
Fortress.lookup()
Phoenix.lookup()
as opposed to:
Cocoon --
|
|-(hosts)--- ComponentX
|-(hosts)--- ComponentY
|-(hosts)--- ComponentZ
minimal call stack:
ComponentZ.compose()
ComponentManager.lookup()
Cocoon.lookup()
> Isn't it conceptually similar to what Berin proposed with the
> ****Manager stuff?
> Doesn't Merlin advocate a hierarchical Container system?
yup, but Avalon as a whole doesn't (imagine building a hierarchy of
phoenix kernels...) nor is it always a good idea.
"to use this component inside Cocoon you have to include Merlin; to use
it inside Turbine you have to use it inside cocoon inside Merlin".
Hmmm....
> >>ANd would you mandate that it be
> >>added into all containers or that containers could not implement it using
> >>alternative strategies?
> >
> >
> > nah. It just seems to me that "the most simple solution that could
> > possibly work, in 90% of cases" would be nice to have in the framework.
>
> Sorry, Leo, but it seems like the ComponentSelector, Excalibur ECM,
> etc... compromise stuff.
there is a clear choice to do it one way (an interface to be extended by
an "lifecycle extension module" for each of the clearly identified
"parts"/"phases"/"stages" of the lifecycle), which is thought to be
best. The compromise is wrt to features (it is not possible to specify
relationship between multiple modules in the standard system, for
example, which was a sacrifice made for flexibility).
The ComponentSelector/ECM was allowed in as a compromise to get a cocoon
release dependent on avalon (or something like that), even when some
developers felt it was bad design. That's a different kind of compromise
to me.
> If it works 90% of the time it's just an added feature, not part of the
> framework.
the framework itself also works only 90% of the time.
> > The same arguments are mostly true for other potential parts of the
> > framework (like a common metadata model): there will always be
> > alternative strategies that have definite advantages in some use cases,
> > but the benefit of common ground and reusability in 90% of cases
> > outweighs the downside.
>
> The 90% stands now, in some months it may be 50% then 30%... who knows.
yup. But if there is no common ground in these areas the use of avalon
in general will go from 9% to 5% to 3%....as opposed to from 9% to 30%
to 90%...
> > It doesn't matter whether such a meta model or lifecycle extension
> > support is dubbed part of avalon framework or if it is called
> > "framework++", as long as we as a project choose as much of a common
> > solution as is possible. It just doesn't seem "wise" to have competing
> > "frameworks" inside the same project. But hey, apparantly that's just
> > "me" =)
>
> We know that in Avalon Containers are Components, both in complexity and
> featureset.
>
> This is why we have many Containers coming up, as we have many Components.
>
> I would like to use a container that manages extensions when I think
> it's right.
> I would like to write *my* container that does *not* supply extensions
> where needed.
+1. But I want one consistent approach *within* avalon. It really does
not make sense to have one avalon container do it one way and then have
another avalon container that does exactly the same thing in a slightly
different way just because some developers have decided to consistently
disagree.
cheers,
Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Leo Simons wrote:
> ...
>
>> In "my wisdom", current proposals are approaching a point where the
>> feature set, complexity, etc, is similar to the one the avalon lifecycle
>> propagates.
>>
>> Sure, our lifecycle setup is not the fastest, nor is it the most
>> flexible, or manageable. The one killer feature of the avalon lifecycle
>> is that it is common ground (the other ones being that it is simple,
>> stable, documented, supported).
>>
>> It has been shown that there is need for additional non-standard
>> lifecycle stages to <insert requirment here> write some components. To
>> keep these components portable across containers, the code that supports
>> the extension should also be portable across containers. To make that
>> happen we indeed need to make sacrifices, mainly feature flexibility.
>
>
> One note. The fact that there would be a common way to specify
> extensions makes components portable.
> This is very important, and as you have seen you cannot use Cocoon
> components OOTB, because it extends lifecycle.
>
> BUT...
>
> Is it true that we want Components to be portable across containers?
>
> If we have nested Containers, it seems (naively maybe?) that if we
> want to use ComponentX in our ContainerY we can just make ComponentX
> one of the components of ContainerY, and access the Components from
> there...
>
> ie:
>
> ComponentX-(hosts)- |--- ComponentX1
> |
> |--- ComponentX2
>
> ComponentY-(hosts)- |--- ComponentY1
Works in Merlin today.
Plus Merlin provides container lelvel classloader seperation.
>
>
>
> If I want to use ComponentX1 in ContainerY I do:
>
> ComponentY-(hosts)- |--- ComponentY1
> |
> |--- ComponentX-(hosts)- |--- ComponentX1
>
Also work in Merlin today/.
>
> Which means that exery Component must be distributed with his Container.
> Isn't it conceptually similar to what Berin proposed with the
> ****Manager stuff?
> Doesn't Merlin advocate a hierarchical Container system?
Yes it does.
Part of my overriding object was to establish a viable way of seperating
different container semanitcis. For example a Phoneix style container
versus an ECM/Fortress style container - but preserve a single
deployment context.
<snip/>
>
>
> Why can't we just build a common set of execution environments
> (server-standalone ala Phoenix, commandline and Ant task ala Merlin1,
> servlet embeddable... etc) and then populate it with the required
> Containers (Fortress, Merlin2, Phoenix"Blocks", ECM)?
>
You can - it's called Merlin 2.0.
Populate it with the container you want, add components to the container
that provides the quality-of-service your component needs.
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: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
...
> In "my wisdom", current proposals are approaching a point where the
> feature set, complexity, etc, is similar to the one the avalon lifecycle
> propagates.
>
> Sure, our lifecycle setup is not the fastest, nor is it the most
> flexible, or manageable. The one killer feature of the avalon lifecycle
> is that it is common ground (the other ones being that it is simple,
> stable, documented, supported).
>
> It has been shown that there is need for additional non-standard
> lifecycle stages to <insert requirment here> write some components. To
> keep these components portable across containers, the code that supports
> the extension should also be portable across containers. To make that
> happen we indeed need to make sacrifices, mainly feature flexibility.
One note. The fact that there would be a common way to specify
extensions makes components portable.
This is very important, and as you have seen you cannot use Cocoon
components OOTB, because it extends lifecycle.
BUT...
Is it true that we want Components to be portable across containers?
If we have nested Containers, it seems (naively maybe?) that if we want
to use ComponentX in our ContainerY we can just make ComponentX one of
the components of ContainerY, and access the Components from there...
ie:
ComponentX-(hosts)- |--- ComponentX1
|
|--- ComponentX2
ComponentY-(hosts)- |--- ComponentY1
If I want to use ComponentX1 in ContainerY I do:
ComponentY-(hosts)- |--- ComponentY1
|
|--- ComponentX-(hosts)- |--- ComponentX1
Which means that exery Component must be distributed with his Container.
Isn't it conceptually similar to what Berin proposed with the
****Manager stuff?
Doesn't Merlin advocate a hierarchical Container system?
In this way, the only thing that we have to support is how Containers
expose themselves as Components, ie with the usual lifecycle methods.
>>ANd would you mandate that it be
>>added into all containers or that containers could not implement it using
>>alternative strategies?
>
>
> nah. It just seems to me that "the most simple solution that could
> possibly work, in 90% of cases" would be nice to have in the framework.
Sorry, Leo, but it seems like the ComponentSelector, Excalibur ECM,
etc... compromise stuff.
If it works 90% of the time it's just an added feature, not part of the
framework.
> The same arguments are mostly true for other potential parts of the
> framework (like a common metadata model): there will always be
> alternative strategies that have definite advantages in some use cases,
> but the benefit of common ground and reusability in 90% of cases
> outweighs the downside.
The 90% stands now, in some months it may be 50% then 30%... who knows.
> It doesn't matter whether such a meta model or lifecycle extension
> support is dubbed part of avalon framework or if it is called
> "framework++", as long as we as a project choose as much of a common
> solution as is possible. It just doesn't seem "wise" to have competing
> "frameworks" inside the same project. But hey, apparantly that's just
> "me" =)
We know that in Avalon Containers are Components, both in complexity and
featureset.
This is why we have many Containers coming up, as we have many Components.
I would like to use a container that manages extensions when I think
it's right.
I would like to write *my* container that does *not* supply extensions
where needed.
Why can't we just build a common set of execution environments
(server-standalone ala Phoenix, commandline and Ant task ala Merlin1,
servlet embeddable... etc) and then populate it with the required
Containers (Fortress, Merlin2, Phoenix"Blocks", ECM)?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Leo Simons <le...@apache.org>.
> > So there is an ample supply of examples of projects with clean, similar,
> > pluggable architectures, yet you feel it is impossible to extract the
> > common ground between them?
>
> Because as soon as you start to define the interface to server plugins rather
> than client contracts you start making tradeoffs.
true. The main tradoff is one of portability vs "feature flexibility".
What muddies the waters a bit is that the proposed server plugins are
part of the client contract: if a client can specify a component
requires support for lifecycle extension X, there must also be a way to
actually specify lifecycle extension X.
> Compare TC3 vs TC4s notion
> of pluggable interceptors - which is "better"? TC3 is better in some
> situations (easier to use, manage and develope, especially when there is
> large numbers of intersection points for a particular concern) and TC4 is
> better in other situations (potentially better performing, uses indirection
> to allow non-linear chains).
>
> So tell me? Which in your wisdom is better?
In "my wisdom", current proposals are approaching a point where the
feature set, complexity, etc, is similar to the one the avalon lifecycle
propagates.
Sure, our lifecycle setup is not the fastest, nor is it the most
flexible, or manageable. The one killer feature of the avalon lifecycle
is that it is common ground (the other ones being that it is simple,
stable, documented, supported).
It has been shown that there is need for additional non-standard
lifecycle stages to <insert requirment here> write some components. To
keep these components portable across containers, the code that supports
the extension should also be portable across containers. To make that
happen we indeed need to make sacrifices, mainly feature flexibility.
> ANd would you mandate that it be
> added into all containers or that containers could not implement it using
> alternative strategies?
nah. It just seems to me that "the most simple solution that could
possibly work, in 90% of cases" would be nice to have in the framework.
The same arguments are mostly true for other potential parts of the
framework (like a common metadata model): there will always be
alternative strategies that have definite advantages in some use cases,
but the benefit of common ground and reusability in 90% of cases
outweighs the downside.
It doesn't matter whether such a meta model or lifecycle extension
support is dubbed part of avalon framework or if it is called
"framework++", as long as we as a project choose as much of a common
solution as is possible. It just doesn't seem "wise" to have competing
"frameworks" inside the same project. But hey, apparantly that's just
"me" =)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Mon, 19 Aug 2002 19:39, Leo Simons wrote:
> > I remember quite a few people remarking how Component marker interface
> > was a good idea, or ComponentSelector was a great idea, or that all the
> > Poolable, Threadsafe etc interfaces were good ideas. Is this idea good in
> > the same way?
>
> what is your argument? That because some people at some point about
> something mentioned it was a good idea where it was not means me stating
> something else is a good idea also means it is not?
>
> > I think a little wider testing is needed before you could adopt it.
>
> I feel safe adopting the idea that a common pluggable facility
> architecture is a good idea =)
You are free to do whatever you want. If it as all good as you seem to believe
I am sure people will flock to it. Personally I believe that in time you will
find yourself needing to change the API for different demands.
> > JEdit is a specific container, Axis is a specific container - have you
> > got any examples apart from CORBA where there is a common API for
> > extending servers?
>
> nah. In fact, apart from CORBA, I can't think of a common API that
> really facilitates clean reuse across servers...except avalon.
Servlets?
> So there is an ample supply of examples of projects with clean, similar,
> pluggable architectures, yet you feel it is impossible to extract the
> common ground between them?
Because as soon as you start to define the interface to server plugins rather
than client contracts you start making tradeoffs. Compare TC3 vs TC4s notion
of pluggable interceptors - which is "better"? TC3 is better in some
situations (easier to use, manage and develope, especially when there is
large numbers of intersection points for a particular concern) and TC4 is
better in other situations (potentially better performing, uses indirection
to allow non-linear chains).
So tell me? Which in your wisdom is better? ANd would you mandate that it be
added into all containers or that containers could not implement it using
alternative strategies?
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Mon, 19 Aug 2002 18:35, Leo Simons wrote:
>
>
>>agreed. However, defining a container API that allows plugging of any
>>facility using an event- or pipeline- like architecture seems a nice
>>idea, and the current work to enable this is definately moving in the
>>right direction.
>>
>>
<snip>
>>Similarly, systems that completely expose their pipeline like Axis,
>>JEdit, to me show that it *is* possible to provide a common pluggability
>>architecture.
>>
>>
>
>As does cocoon, almost all enterprise/distributed servers (be they plain
>rmi-like servers to EJB/CORBA servers). Even TC3 and TC4 has the notion of
>interceptors. Now how many of them are actually compatible ...
>
>JEdit is a specific container, Axis is a specific container - have you got any
>examples apart from CORBA where there is a common API for extending servers?
>
>
>
>>conceptually, that would be okay. However, it is impossible to
>>anticipate in advance all the lifecycle phases important enough to
>>support.
>>
>>
>
>bingo!
>
I think you missing Leo's point. The need for extensions is brought
about by differences across domains, and the need to facilitate
adaption. This leads to more future-proof systems with better support
for variations in requirements across our user community. It's a point
that has been well and truly validated in the CORBA community.
--
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: DTD compat -- red herring?
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-08-19 at 11:29, Peter Donald wrote:
> On Mon, 19 Aug 2002 18:35, Leo Simons wrote:
> > agreed. However, defining a container API that allows plugging of any
> > facility using an event- or pipeline- like architecture seems a nice
> > idea, and the current work to enable this is definately moving in the
> > right direction.
>
> I remember quite a few people remarking how Component marker interface was a
> good idea, or ComponentSelector was a great idea, or that all the Poolable,
> Threadsafe etc interfaces were good ideas. Is this idea good in the same way?
what is your argument? That because some people at some point about
something mentioned it was a good idea where it was not means me stating
something else is a good idea also means it is not?
> I think a little wider testing is needed before you could adopt it.
I feel safe adopting the idea that a common pluggable facility
architecture is a good idea =)
> > Similarly, systems that completely expose their pipeline like Axis,
> > JEdit, to me show that it *is* possible to provide a common pluggability
> > architecture.
>
> As does cocoon, almost all enterprise/distributed servers (be they plain
> rmi-like servers to EJB/CORBA servers). Even TC3 and TC4 has the notion of
> interceptors. Now how many of them are actually compatible ...
none. That is why we have avalon: to make that happen. There are many
pluggability architectures, most are remarkably similar, yet there is no
reuse. Avalon to the rescue!
> JEdit is a specific container, Axis is a specific container - have you got any
> examples apart from CORBA where there is a common API for extending servers?
nah. In fact, apart from CORBA, I can't think of a common API that
really facilitates clean reuse across servers...except avalon.
> > > We could standardize on an component attribute name that lists a set of
> > > required phases that the container must implement to run component
> >
> > I hope you don't mean
> >
<snip>
> nope.
<snip>
> > > but other
> > > than that I really don't see the need for any changes to existing
> > > ContainerKit model.
> >
> > one issue I see is decreased reusability of the container. If changes by
> > the client to the internals of a container are neccessary for the client
> > to get support for their custom lifecycle needs, that is a big minus.
> >
> > The other option is to allow (for example) classes to be added to the
> > container by putting a jar file in the container lib directory (or added
> > through some other mechanism like JMX) and modifying an XML
> > configuration file. Again, Axis shows it can be done cleanly.
>
> JBoss does it fairly nice aswell, as does TC4 as does X ...
So there is an ample supply of examples of projects with clean, similar,
pluggable architectures, yet you feel it is impossible to extract the
common ground between them?
why? Seems to me Avalon is halfway already.
cheers,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Tue, 20 Aug 2002 00:26, Nicola Ken Barozzi wrote:
>
>
>>Peter Donald wrote:
>>
>>
>>>On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>>>
>>>
>>>>We want to get an agreement on what to do for the present and future
>>>>with regards to unified Component Model, Merlin, Fortress, Phoenix, et
>>>>all.
>>>>
>>>>"Discussions get forgotten, just code remains."
>>>>
>>>>I will strongly oppose and veto any "compromise".
>>>>I want the *solution*.
>>>>
>>>>
>>>The only real solution is to use the ContainerKit model. With it you get
>>>will compatability between all the containers. Phoenix will use it
>>>directly while Merlin will load it through its own Type loader. If you
>>>choose to use Merlin specific xml format then you will be bound to
>>>Merlin.
>>>
>>>What is the problem with that?
>>>
>>>
>>IIUC Merlin has features that Phoenix doesn't have (and viceversa).
>>If I write a component that uses these "features", it will not run in
>>other containers.
>>
>>
>
>The ContainerKit model does not state anything about these "features". It
>gives a mechanism to define metadata and extend that metadata with
>attributes.
>
And does not provide a framework for extension.
>A container can decide to add "features" by handling specific attributes and
>components can declare those attributes. The conatiner can also decide to
>handle specific types of components. ie if object is Persistent then call
>Persistent.persist()
>
And how is a container goping to know that it has an obligation to do
this. An attribute is just an attribute unless recvigized by all
containers. The argument of saying "you
-can-express-it-as-an-attribute" is false. The container needs to kno0w
what that attribute implies. Decalraring an attribute is not differnce
from declaring a wel formulated set of criteria in the type XML - the
container still has to sdeal with it - or, declare itself as brain dead.
>
>Some of these features are required by container and we would need to
>standardize an attribute name to indicate required "features". However as
>soon as you require such a feature you loose strict compatability (though
>other containers that support feature can still run component).
>
>
I agree that the bnotion of validation is the target. To achieve this
you need information that you can manage to determin that a component
can be deployed. This is called the validation process. Phoenix and
Merlin and Fortress need to respect similar validation criteria - the
notions of extensions as an example. All we are talking about if the
ability for Phoeix to upgrade to the level that it understands the
conocept of a compoennt declaring a stage depedency and the concept of a
component declaring its ability to servie that stage dependecy. This is
distincly defferent for the requirement for Phoenix to actually support
this deployment- and somewhat academic - Merlin will provide these
deplyment abilities so simply adding a component inside a Merlin
comtainer inside Phoeinix solves the problem.
>
>
>>We would all like Components that run in *all* Containers
>>But we still have and want to have different Containers that have
>>proprietary semantics. And this creates problems in portability, since
>>it has happened that some James Components are tied to Phoenix specific
>>things, and they didn't even realize it.
>>
>>- How can I run Merlin-specific components in Phoenix?
>>- How can I run Phoenix-specific components in Merlin?
>>- How can I be *aware* that I'm using Container specific stuff versus
>>Avalon baseline?
>>
>>
>>IMHO it would seem that the first two points can be done using a correct
>>Container hierarchy.
>>
>>
>
>possibly.
>
It already done!
Check out Merlin.
>We need to figure out a way to dynamically compose services for that
>to work but thats certainly possible (actually I just posted something about
>this onphoenix list).
>
It's already done.
Checkout Merlin.
>>And that the last one by defining a standard way of *describing*
>>extensions (ie in what "context" they are made and what they need) and
>>keeping this description physically separate from the standard
>>containerkit descriptor.
>>
>>
>
>Thats sorta what I was saying. Except that I am not sure I would want to
>standardize the format of the extension descriptor (ie a Foo-persistent.xml
>is gonna look much different from Foo-instrument.xml). However a standard way
>of defining that the component supports or requires a "feature" seems
>possible. However the exact semantics of the "feature" is left up to
>container/feature writer. They should feel free to do it however the hell
>they like.
>
In the Avalon Meta Model an extension is a component. You do not need
to be concerned with extension specifics. This is a very big difference
between Merlin and Phoenix. Merlin deals with extensions as components
- as such an extension may have depedencies, my have lifestyle
extensions of its own, my have context dependecies, etc. Merlin does
not differentiate facilities in the way that Phoeinix does which changes
dramtically the way you go abut providing new functionality.
Chers, 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: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>>>> This is possible without including any reference or depedency on
>>>>> Merlin providing we settle the.xinfo DTD. I would like at add
>>>>> another couple of points:
>>>>>
>>>>> 5) utilities enabling component migration
>>>>>
>>>>> One of the problems I have had to deal with concerning existing
>>>>> components are references to things like BlockContext. Merlin can
>>>>> work around this through its context management system. A container
>>>>> indepedent solution called GenericBlockContext was added to the
>>>>> Phoneix CVS. This seemed the correct thing to do as opposed to
>>>>> creating a Phoenix depedency in the Merlin CVS.
>>>>>
>>>>> The original contribution is under the Phoenix CVS (Attic).
>>>>> org/apache/avalon/phoenix/tools/export/GenericBlockContext.
>>>>>
>>>>> Are there any objections/issues to bringing this class back into
>>>>> action?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> As nobody has objected to this I'll go ahead an re-commit
>>>> GenericBlockContext.
>>>
>>>
>>>
>>>
>>> I for one would like more time to consider this. Please tread
>>> carefully dude given recent events.
>>
>>
>>
>>
>> No problem. I'll continue the work on Merlin in the meantime - more
>> to be done on documentation, demos, etc.
>
>
> Could you give us a an overview of these changes and their expected
> usage, please Stephen?
> I'm having trouble seeing the immediate need.....
If you look at components like those found in Cornerstone, they have
been written with the assumption that will be running inside Phoenix.
Several of these components include specific Phoenix dependencies - for
example, references to BlockContext. Looking closer you will find that
Phoenix dependencies are almost 95% related to a component needed a
reference to the application directory. As such you end up with frequent
imports of BlockContext into components. Cornerstone is one example.
Merlin can deal with this providing the component declares the context
criteria in a .xinfo or .xtype file (the .xinfo and .xtype can be
considered as equivalent - .xtype exists only as a workaround to the
existing Phoenix generate blockinfo descriptors that don't include
context criteria). For example, I can write a .xtype file that declares
that the component needs an instance implementing the BlockContext
interface. With that in place, I can execute a cornerstone or James
component by declaring context directives in the deployment file.
Lets look at a real cornerstone example:
DefaultSocketManager takes a context object and applies the object to
factories declared in its configuration. One of these factories is the
TLSServerSocketFactory which narrows the context object to BlockContext
without checking if the supplied context is a BlockContext - bingo -
ClassCastException.
By adding a .xtype directive, Merlin can told that the DefaultSocketManager
needs to be supplied with a context instance that implements the
BlockContext interface.
Within Merlin, when declaring the socket component, the assembler can
declare context creation directives. For example, an implementation of
block context only needs to be supplied with the block name and working
the directory.
Here is an example of a Merlin component declaration for
DefaultSocketManager:
<component name="sockets"
class="org.apache.avalon.cornerstone.blocks.sockets.DefaultSocketManager"
activation="false">
<context class="org.apache.avalon.phoenix.tools.export.GenericBlockContext">
<import key="app.home" name="avalon:home"/>
<entry key="block.name" value="store"/>
</context>
<configuration>
<server-sockets>
<factory name="plain"
class="org.apache.avalon.cornerstone.blocks.sockets.DefaultServerSocketFactory"/>
</server-sockets>
<client-sockets>
<factory name="plain"
class="org.apache.avalon.cornerstone.blocks.sockets.DefaultSocketFactory"/>
</client-sockets>
</configuration>
</component>
The above component declaration results in the definition of a
component profile - i.e. a component type together with
it's instantiation criteria. The context element declares to
Merlin how to build the context object. First of all, a context
implementation class (in this case a class implementing BlockContext)
together with directives that populate the context object with
keyed values.
When Merlin handles the establishment of the DefaultSocketManager
it creates a new instance of the context class (in this example an
instance of GenericBlockContext and populates a map with a
combination of explicit entry declarations and/or values imported
from the kernel.
The GenericBlockContext is independent of Merlin - in fact it's only
dependencies are to Phoneix (for BlockContext) and the Avalon
Framework (for Context). It follows the same pattern as the
framework DefaultContext (a map and a parent context
argument). In effect, GenericBlockContext enables other containers
to simulated the behavior of Phoenix for components that have
BlockContext dependencies.
The approach to handling this is either every container provides a
Phoenix workaround, or, Phoenix provides a utility class. The
intention was to approach this in a collaborative manner - Phoenix
providing the utility inside phoenix-client, Merlin providing the
mechanisms to handle context directives. If on the other-hand we
make it an obligation for every container to provide their own
Phoenix workaround, we will significantly escalate the number of
utilities and the approaches taken. It seems to me
that something like GenericBlockContext should reside in the phoenix
project because any component referencing BlockContext is dependent
on the phoenix-client.jar. If Merlin were to include this, then
a standard Merlin build becomes dependent on Phoenix. This increases
the overall size of Merlin with no benefit unless someone is running
a Phoenix dependent component (in which case they have already
declared phoenix-client.jar in their classpath).
There is another approach that I have discussed with some of the
people over on James - namely the usage of standard Avalon context
keys.
For example:
public void contextualize( Context context ) throws ContextException
{
File file = (File) context.get("avalon:home");
}
This would negate the necessity for inclusion of a container
dependency. But it does require that Avalon containers respect a set
of common context keys.
The common attribute approach would simply require that both Merlin
and Phoenix made sure that "avalon:"... context keys were made
available. E.g. DefaultBlockContext could be easily updated to
return the working directory in response to a "avalon:home" key.
This would eliminate the majority of container dependencies that exist
today. Complimenting this, a GenericBlockContext would provide an
elegant solution when dealing with components that include hard coded
dependencies on the Phoenix container.
I hope that provides a clear and complete picture.
Cheers, Steve.
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
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: DTD compat -- red herring?
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>>> This is possible without including any reference or depedency on
>>>> Merlin providing we settle the.xinfo DTD. I would like at add
>>>> another couple of points:
>>>>
>>>> 5) utilities enabling component migration
>>>>
>>>> One of the problems I have had to deal with concerning existing
>>>> components are references to things like BlockContext. Merlin can
>>>> work around this through its context management system. A
>>>> container
>>>> indepedent solution called GenericBlockContext was added to the
>>>> Phoneix CVS. This seemed the correct thing to do as opposed to
>>>> creating a Phoenix depedency in the Merlin CVS.
>>>>
>>>> The original contribution is under the Phoenix CVS (Attic).
>>>> org/apache/avalon/phoenix/tools/export/GenericBlockContext.
>>>>
>>>> Are there any objections/issues to bringing this class back into
>>>> action?
>>>
>>>
>>>
>>>
>>>
>>> As nobody has objected to this I'll go ahead an re-commit
>>> GenericBlockContext.
>>
>>
>>
>> I for one would like more time to consider this. Please tread
>> carefully dude given recent events.
>
>
>
> No problem.
> I'll continue the work on Merlin in the meantime - more to be done on
> documentation, demos, etc.
Could you give us a an overview of these changes and their expected
usage, please Stephen?
I'm having trouble seeing the immediate need.....
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen
>
>>> This is possible without including any reference or depedency on
>>> Merlin providing we settle the.xinfo DTD. I would like at add
>>> another couple of points:
>>>
>>> 5) utilities enabling component migration
>>>
>>> One of the problems I have had to deal with concerning existing
>>> components are references to things like BlockContext. Merlin can
>>> work around this through its context management system. A
>>> container
>>> indepedent solution called GenericBlockContext was added to the
>>> Phoneix CVS. This seemed the correct thing to do as opposed to
>>> creating a Phoenix depedency in the Merlin CVS.
>>>
>>> The original contribution is under the Phoenix CVS (Attic).
>>> org/apache/avalon/phoenix/tools/export/GenericBlockContext.
>>>
>>> Are there any objections/issues to bringing this class back into
>>> action?
>>
>>
>>
>>
>> As nobody has objected to this I'll go ahead an re-commit
>> GenericBlockContext.
>
>
> I for one would like more time to consider this. Please tread
> carefully dude given recent events.
No problem.
I'll continue the work on Merlin in the meantime - more to be done on
documentation, demos, etc.
Cheers, Steve.
>
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
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: DTD compat -- red herring?
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen
>> This is possible without including any reference or depedency on
>> Merlin providing we settle the.xinfo DTD. I would like at add another
>> couple of points:
>>
>> 5) utilities enabling component migration
>>
>> One of the problems I have had to deal with concerning existing
>> components are references to things like BlockContext. Merlin can
>> work around this through its context management system. A
>> container
>> indepedent solution called GenericBlockContext was added to the
>> Phoneix CVS. This seemed the correct thing to do as opposed to
>> creating a Phoenix depedency in the Merlin CVS.
>>
>> The original contribution is under the Phoenix CVS (Attic).
>> org/apache/avalon/phoenix/tools/export/GenericBlockContext.
>>
>> Are there any objections/issues to bringing this class back into
>> action?
>
>
>
> As nobody has objected to this I'll go ahead an re-commit
> GenericBlockContext.
I for one would like more time to consider this. Please tread carefully
dude given recent events.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Paul Hammant wrote:
>
>> Stephen,
>>
>>>> Hmmm...
>>>
>>>
>>>
>>>
>>>
>>> The only issue is for Phoenix to throw the exception
>>>
>>> try
>>> {
>>> // do classic Phoenix stuff
>>> }
>>> catch( ValidationException ve )
>>> {
>>> final String error =
>>> "Sorry, Phoenix isn't as advanced as some other Avalon
>>> containers."
>>> + "Phoenix does not support"
>>> + " * extensions"
>>> + " * dynamic context"
>>> + " * default configuration"
>>> + " * auto assembly";
>>>
>>> throw new ValidationFailure( error );
>>> }
>>
>>
>>
>> OK, ignoring for the time being that this is a little rude to Phoenix
>> and its authors,
>
>
>
> True - please accept my appologies as no offense was intended.
>
>> there is something positive here. Especially as you have in another
>> mail said that Merlin can (or will be soon) be run inside Phoenix.
>>
>> Given some basic assumptions:
>>
>> 1) From the laymans point of view, Merlin is apparently an alternate
>> container to Phoenix providing extensions, dynamic xontext, default
>> configuration and auto assembly beyong the abilities of Phoenix
>>
>> 2) Phoenix is likely not to support directly those features.
>>
>> Perhaps we have some positive things to do here:
>>
>> 1) DTD unified, for Merlin specific elements, basic Phoenix refuses
>> to run with a polite message.
>
>
>
> The same thing applies to Merlin.
> Merlin does not currently provide support for management access point
> declarations and should fail validation gracefully. The management
> entry point declarations are supported in the Type DTD in order to
> ensure compatability across both containers.
>
>>
>> 2) Compatibility elements added .xinfo files and assembly.xml.
>> A euphamism like <avalon-container-compatability> might be good.
>
>
>
> I have thought about this but ran into lots of IOC issues. Basically
> its the container that should be handling the poblem - it knows what
> it is capable of suppporting and the level of support my be dynamic.
>
>>
>> 3) Merlin coded to have distributions for all of these:
>> i) standalone
>> ii) in Phoenix,
>> iii) replacement Phoenix kernel components (refer kernel.conf).
>>
>> 4) basic Phoenix coded to exlicitly not handle Merlin specific
>> features.
>
>
>
> This is possible without including any reference or depedency on
> Merlin providing we settle the.xinfo DTD.
> I would like at add another couple of points:
>
> 5) utilities enabling component migration
>
> One of the problems I have had to deal with concerning existing
> components are references to things like BlockContext. Merlin can
> work around this through its context management system. A container
> indepedent solution called GenericBlockContext was added to the
> Phoneix CVS. This seemed the correct thing to do as opposed to
> creating a Phoenix depedency in the Merlin CVS.
>
> The original contribution is under the Phoenix CVS (Attic).
> org/apache/avalon/phoenix/tools/export/GenericBlockContext.
>
> Are there any objections/issues to bringing this class back into
> action?
As nobody has objected to this I'll go ahead an re-commit
GenericBlockContext.
Steve.
>
>
> 6) management of components that assume block-listener and application
> listener support - my impression is that this could be managed as a
> lifestyle extension but I would really need to think more about it
> (any thoughts appreciated)
>
>
>>
>>
>> We have a way to placate steve's quest for a new generation, Peter
>> feeling that phoenix itself should be stable. Please folks if we are
>> going to shoot this idea/compromise down, could we do so without
>> heated emotion. Could we also try to do so in a summarial way, with
>> accompanying detailed explanation: "This will not work because
>> Phoenix is a bird that rises from the ashes; Refer to mythalogical
>> blah blah blah blah." Some of us demi-management types want to see a
>> managerial summary and trust that we don't have to wade through pages
>> of justification. If the managerial summary is concisely put, and
>> fairly represents the accompanying explanation, then it is a good
>> point of reference. This whole Merlin/Phoenix thing has been clouded
>> by too much detail, that kinda precludes the involvement of those of
>> us who have not written one of the two or swallowed the "Software
>> architecture for geniuses". Please -> short, fair and concilliatory
>> chatter from now on?
>
>
>
> Sounds good.
>
> Steve.
>
>>
>>
>> - Paul
>>
>> - Paul
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>
--
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: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>> Hmmm...
>>
>>
>>
>>
>> The only issue is for Phoenix to throw the exception
>>
>> try
>> {
>> // do classic Phoenix stuff
>> }
>> catch( ValidationException ve )
>> {
>> final String error =
>> "Sorry, Phoenix isn't as advanced as some other Avalon
>> containers."
>> + "Phoenix does not support"
>> + " * extensions"
>> + " * dynamic context"
>> + " * default configuration"
>> + " * auto assembly";
>>
>> throw new ValidationFailure( error );
>> }
>
>
> OK, ignoring for the time being that this is a little rude to Phoenix
> and its authors,
True - please accept my appologies as no offense was intended.
> there is something positive here. Especially as you have in another
> mail said that Merlin can (or will be soon) be run inside Phoenix.
>
> Given some basic assumptions:
>
> 1) From the laymans point of view, Merlin is apparently an alternate
> container to Phoenix providing extensions, dynamic xontext, default
> configuration and auto assembly beyong the abilities of Phoenix
>
> 2) Phoenix is likely not to support directly those features.
>
> Perhaps we have some positive things to do here:
>
> 1) DTD unified, for Merlin specific elements, basic Phoenix refuses
> to run with a polite message.
The same thing applies to Merlin.
Merlin does not currently provide support for management access point
declarations and should fail validation gracefully. The management
entry point declarations are supported in the Type DTD in order to
ensure compatability across both containers.
>
> 2) Compatibility elements added .xinfo files and assembly.xml.
> A euphamism like <avalon-container-compatability> might be good.
I have thought about this but ran into lots of IOC issues. Basically
its the container that should be handling the poblem - it knows what it
is capable of suppporting and the level of support my be dynamic.
>
> 3) Merlin coded to have distributions for all of these:
> i) standalone
> ii) in Phoenix,
> iii) replacement Phoenix kernel components (refer kernel.conf).
>
> 4) basic Phoenix coded to exlicitly not handle Merlin specific features.
This is possible without including any reference or depedency on Merlin
providing we settle the.xinfo DTD.
I would like at add another couple of points:
5) utilities enabling component migration
One of the problems I have had to deal with concerning existing
components are references to things like BlockContext. Merlin can
work around this through its context management system. A container
indepedent solution called GenericBlockContext was added to the
Phoneix CVS. This seemed the correct thing to do as opposed to
creating a Phoenix depedency in the Merlin CVS.
The original contribution is under the Phoenix CVS (Attic).
org/apache/avalon/phoenix/tools/export/GenericBlockContext.
Are there any objections/issues to bringing this class back into
action?
6) management of components that assume block-listener and application
listener support - my impression is that this could be managed as a
lifestyle extension but I would really need to think more about it
(any thoughts appreciated)
>
>
> We have a way to placate steve's quest for a new generation, Peter
> feeling that phoenix itself should be stable. Please folks if we are
> going to shoot this idea/compromise down, could we do so without
> heated emotion. Could we also try to do so in a summarial way, with
> accompanying detailed explanation: "This will not work because
> Phoenix is a bird that rises from the ashes; Refer to mythalogical
> blah blah blah blah." Some of us demi-management types want to see a
> managerial summary and trust that we don't have to wade through pages
> of justification. If the managerial summary is concisely put, and
> fairly represents the accompanying explanation, then it is a good
> point of reference. This whole Merlin/Phoenix thing has been clouded
> by too much detail, that kinda precludes the involvement of those of
> us who have not written one of the two or swallowed the "Software
> architecture for geniuses". Please -> short, fair and concilliatory
> chatter from now on?
Sounds good.
Steve.
>
>
> - Paul
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
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: DTD compat -- red herring?
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>> Hmmm...
>
>
>
> The only issue is for Phoenix to throw the exception
>
> try
> {
> // do classic Phoenix stuff
> }
> catch( ValidationException ve )
> {
> final String error =
> "Sorry, Phoenix isn't as advanced as some other Avalon
> containers."
> + "Phoenix does not support"
> + " * extensions"
> + " * dynamic context"
> + " * default configuration"
> + " * auto assembly";
>
> throw new ValidationFailure( error );
> }
OK, ignoring for the time being that this is a little rude to Phoenix
and its authors, there is something positive here. Especially as you
have in another mail said that Merlin can (or will be soon) be run
inside Phoenix.
Given some basic assumptions:
1) From the laymans point of view, Merlin is apparently an alternate
container to Phoenix providing extensions, dynamic xontext, default
configuration and auto assembly beyong the abilities of Phoenix
2) Phoenix is likely not to support directly those features.
Perhaps we have some positive things to do here:
1) DTD unified, for Merlin specific elements, basic Phoenix refuses
to run with a polite message.
2) Compatibility elements added .xinfo files and assembly.xml.
A euphamism like <avalon-container-compatability> might be good.
3) Merlin coded to have distributions for all of these:
i) standalone
ii) in Phoenix,
iii) replacement Phoenix kernel components (refer kernel.conf).
4) basic Phoenix coded to exlicitly not handle Merlin specific features.
We have a way to placate steve's quest for a new generation, Peter
feeling that phoenix itself should be stable. Please folks if we are
going to shoot this idea/compromise down, could we do so without heated
emotion. Could we also try to do so in a summarial way, with
accompanying detailed explanation: "This will not work because Phoenix
is a bird that rises from the ashes; Refer to mythalogical blah blah
blah blah." Some of us demi-management types want to see a managerial
summary and trust that we don't have to wade through pages of
justification. If the managerial summary is concisely put, and fairly
represents the accompanying explanation, then it is a good point of
reference. This whole Merlin/Phoenix thing has been clouded by too much
detail, that kinda precludes the involvement of those of us who have not
written one of the two or swallowed the "Software architecture for
geniuses". Please -> short, fair and concilliatory chatter from now on?
- Paul
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Tue, 20 Aug 2002 00:26, Nicola Ken Barozzi wrote:
>>
>>> Peter Donald wrote:
>>>
>>>> On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>>>>
>>>>> We want to get an agreement on what to do for the present and future
>>>>> with regards to unified Component Model, Merlin, Fortress,
>>>>> Phoenix, et
>>>>> all.
>>>>>
>>>>> "Discussions get forgotten, just code remains."
>>>>>
>>>>> I will strongly oppose and veto any "compromise".
>>>>> I want the *solution*.
>>>>
>>>>
>>>> The only real solution is to use the ContainerKit model. With it
>>>> you get
>>>> will compatability between all the containers. Phoenix will use it
>>>> directly while Merlin will load it through its own Type loader. If you
>>>> choose to use Merlin specific xml format then you will be bound to
>>>> Merlin.
>>>>
>>>> What is the problem with that?
>>>
>>>
>>> IIUC Merlin has features that Phoenix doesn't have (and viceversa).
>>> If I write a component that uses these "features", it will not run in
>>> other containers.
>>
>>
>>
>> The ContainerKit model does not state anything about these
>> "features". It gives a mechanism to define metadata and extend that
>> metadata with attributes.
>> A container can decide to add "features" by handling specific
>> attributes and components can declare those attributes. The conatiner
>> can also decide to handle specific types of components. ie if object
>> is Persistent then call Persistent.persist()
>>
>> Some of these features are required by container and we would need to
>> standardize an attribute name to indicate required "features".
>> However as soon as you require such a feature you loose strict
>> compatability (though other containers that support feature can still
>> run component).
>
>
> Yes, I understand.
Not in the case of Merlin.
Merlin handles extensiuons as components. As such the restrictions are
simply limited to the obligation for the extension compoent to declare
the lifestyle stage it handles.
>
>
>>> We would all like Components that run in *all* Containers
>>> But we still have and want to have different Containers that have
>>> proprietary semantics. And this creates problems in portability, since
>>> it has happened that some James Components are tied to Phoenix specific
>>> things, and they didn't even realize it.
>>>
>>> - How can I run Merlin-specific components in Phoenix?
>>> - How can I run Phoenix-specific components in Merlin?
>>> - How can I be *aware* that I'm using Container specific stuff versus
>>> Avalon baseline?
>>>
>>>
>>> IMHO it would seem that the first two points can be done using a
>>> correct
>>> Container hierarchy.
>>
>>
>>
>> possibly. We need to figure out a way to dynamically compose services
>> for that to work but thats certainly possible (actually I just posted
>> something about this onphoenix list).
>
>
> IIUC Merlin gets around doing this, am I correct Stephen?
Yes.
Merlin has a complete servie assembly sub-system.
>>> And that the last one by defining a standard way of *describing*
>>> extensions (ie in what "context" they are made and what they need) and
>>> keeping this description physically separate from the standard
>>> containerkit descriptor.
>>
>>
>>
>> Thats sorta what I was saying.
>
>
> In fact I'm trying to see the good in all the proposed ideas :-)
>
>> Except that I am not sure I would want to standardize the format of
>> the extension descriptor (ie a Foo-persistent.xml is gonna look much
>> different from Foo-instrument.xml).
>
>
> Hmmm...
The only issue is for Phoenix to throw the exception
try
{
// do classic Phoenix stuff
}
catch( ValidationException ve )
{
final String error =
"Sorry, Phoenix isn't as advanced as some other Avalon
containers."
+ "Phoenix does not support"
+ " * extensions"
+ " * dynamic context"
+ " * default configuration"
+ " * auto assembly";
throw new ValidationFailure( error );
}
>
>
>> However a standard way of defining that the component supports or
>> requires a "feature" seems possible. However the exact semantics of
>> the "feature" is left up to container/feature writer. They should
>> feel free to do it however the hell they like.
>
>
> Generally speaking, yes, I agree.
> But Avalon has core concepts like lifecycle, roles, etc.
>
> Since these are concepts common to all Containers, we can still find a
> common way of telling the Container that the Component wants to have a
> certain lifecycle handled and certain roles given.
>
> Again, IIUC this is what Merlin tries to do.
Not only "tries" but "does".
The Merlin architecture cleanly deals with the complete set of
depedencies for components based on the case requirments from a spectrum
of external projects.
>
> It makes the contract between Components and Containers more solid.
Exactly!
>
> I do agree that this is not all there is to it.
> But I think that there are extensions to the core Avalon concepts that
> can be supported by generic Containers.
At least validated.
Implemetation support should be considered as something seperate.
>
>
> So we would have in the contract three descriptors
> - descriptor
> - standard extension descriptor
> - component-specific container descriptor
This will work providing the standard descitor includes the fundimentats
- and that includes extension.
>
> -- This makes it clear to the writes of the Component, that in the
> first case his component is safe to work in all the containers.
> -- If he uses a standard extension descriptor he must supply the
> extension classes to the Container that supports them.
> -- In the last case, he necessarily has to write his own container.
>
> So we can also have an upgrade path.
> A feature can pass from being a standard extension to part of the core
> if it's deemed good enough.
>
>>> Also the standard containerkit stuff would become part of the
>>> framework,
>>> since it would become mandatory.
>>
>>
>> Thats largely where I am going. In a month or two I hope to have
>> tested it thouroughly enough that it can be put up to vote.
>
>
> I was quite ignorant on what you were doing, maybe because I missed
> the thread about this plan.
*cough*, *cough*
>
>
> I would like to hear from the Merlin2 author why he thinks that the
> current descriptor format is not good enough for extensibility, thing
> that Peter denies.
In Avalon land we are relatively familir with the notions that a
componet may have depedencies and that abnother componet may declare
that it provides services to match these dependecies. As far as
meta-level management is concerned, the original solution was Phoenix -
a linear service management architecture. In more recent times, Merlin
- a hierachical container based service management system has been
introduced. The Merlin system specifically address the user
requirements from several projects - including Cocoon, Fortress/ECM,
James, and a number of projects outside of the Avalon community.
Firstly, these requirements called for a much more flexible solution
that possible under Phoenix - for example, the ability to
programatically create and deploy a kernel - the ability to deal with
componet extensions, the ability to deal with context criteria.
The developent of Merlin 2.0 has carefully and continusly seprated the
core meta-info model fro the Merlin framework. This seperation has been
driven by the collabopration with the Fortress effort and the desire to
establish container idepenet intoperability (including integration of
Phoinix into the suite of inteoperable container candidates).
The result of this process is:
- A container independent meta-info model that supports
the requirements of the Fortress project, Phoenix and
Merlin.
- The Merlin system, a simple kernel supporting a container
hierachy - a hierachy enabling the dynakmic integration of
specialized containters such a Fortress, a comtainer model
that support the dynamic mangement of new omponent types.
As outline in an ealier email - the containerkit descriptor format is
inadequete with respect to the user requirements on which Merlin is based.
http://marc.theaimsgroup.com/?l=avalon-dev&m=102979805431045&w=2
Most imprtantly, Merlin and the Avalon Meta Modle is a collaborative,
user driven iniative.
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: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Tue, 20 Aug 2002 00:26, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>>>
>>>>We want to get an agreement on what to do for the present and future
>>>>with regards to unified Component Model, Merlin, Fortress, Phoenix, et
>>>>all.
>>>>
>>>>"Discussions get forgotten, just code remains."
>>>>
>>>>I will strongly oppose and veto any "compromise".
>>>>I want the *solution*.
>>>
>>>The only real solution is to use the ContainerKit model. With it you get
>>>will compatability between all the containers. Phoenix will use it
>>>directly while Merlin will load it through its own Type loader. If you
>>>choose to use Merlin specific xml format then you will be bound to
>>>Merlin.
>>>
>>>What is the problem with that?
>>
>>IIUC Merlin has features that Phoenix doesn't have (and viceversa).
>>If I write a component that uses these "features", it will not run in
>>other containers.
>
>
> The ContainerKit model does not state anything about these "features". It
> gives a mechanism to define metadata and extend that metadata with
> attributes.
>
> A container can decide to add "features" by handling specific attributes and
> components can declare those attributes. The conatiner can also decide to
> handle specific types of components. ie if object is Persistent then call
> Persistent.persist()
>
> Some of these features are required by container and we would need to
> standardize an attribute name to indicate required "features". However as
> soon as you require such a feature you loose strict compatability (though
> other containers that support feature can still run component).
Yes, I understand.
>>We would all like Components that run in *all* Containers
>>But we still have and want to have different Containers that have
>>proprietary semantics. And this creates problems in portability, since
>>it has happened that some James Components are tied to Phoenix specific
>>things, and they didn't even realize it.
>>
>>- How can I run Merlin-specific components in Phoenix?
>>- How can I run Phoenix-specific components in Merlin?
>>- How can I be *aware* that I'm using Container specific stuff versus
>>Avalon baseline?
>>
>>
>>IMHO it would seem that the first two points can be done using a correct
>>Container hierarchy.
>
>
> possibly. We need to figure out a way to dynamically compose services for that
> to work but thats certainly possible (actually I just posted something about
> this onphoenix list).
IIUC Merlin gets around doing this, am I correct Stephen?
>>And that the last one by defining a standard way of *describing*
>>extensions (ie in what "context" they are made and what they need) and
>>keeping this description physically separate from the standard
>>containerkit descriptor.
>
>
> Thats sorta what I was saying.
In fact I'm trying to see the good in all the proposed ideas :-)
> Except that I am not sure I would want to
> standardize the format of the extension descriptor (ie a Foo-persistent.xml
> is gonna look much different from Foo-instrument.xml).
Hmmm...
> However a standard way
> of defining that the component supports or requires a "feature" seems
> possible. However the exact semantics of the "feature" is left up to
> container/feature writer. They should feel free to do it however the hell
> they like.
Generally speaking, yes, I agree.
But Avalon has core concepts like lifecycle, roles, etc.
Since these are concepts common to all Containers, we can still find a
common way of telling the Container that the Component wants to have a
certain lifecycle handled and certain roles given.
Again, IIUC this is what Merlin tries to do.
It makes the contract between Components and Containers more solid.
I do agree that this is not all there is to it.
But I think that there are extensions to the core Avalon conceptsthat
can be supported by generic Containers.
So we would have in the contract three descriptors
- descriptor
- standard extension descriptor
- component-specific container descriptor
-- This makes it clear to the writes of the Component, that in the first
case his component is safe to work in all the containers.
-- If he uses a standard extension descriptor he must supply the
extension classes to the Container that supports them.
-- In the last case, he necessarily has to write his own container.
So we can also have an upgrade path.
A feature can pass from being a standard extension to part of the core
if it's deemed good enough.
>>Also the standard containerkit stuff would become part of the framework,
>>since it would become mandatory.
>
> Thats largely where I am going. In a month or two I hope to have tested it
> thouroughly enough that it can be put up to vote.
I was quite ignorant on what you were doing, maybe because I missed
the thread about this plan.
I would like to hear from the Merlin2 author why he thinks that the
current descriptor format is not good enough for extensibility, thing
that Peter denies.
Also, what Merlin brings in tearms of dynamic resolution, and what
impact it has on systems using Merlin.
Please do it with some code, so that we can see where the issues lie.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 20 Aug 2002 00:26, Nicola Ken Barozzi wrote:
> Peter Donald wrote:
> > On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
> >>We want to get an agreement on what to do for the present and future
> >>with regards to unified Component Model, Merlin, Fortress, Phoenix, et
> >> all.
> >>
> >>"Discussions get forgotten, just code remains."
> >>
> >>I will strongly oppose and veto any "compromise".
> >>I want the *solution*.
> >
> > The only real solution is to use the ContainerKit model. With it you get
> > will compatability between all the containers. Phoenix will use it
> > directly while Merlin will load it through its own Type loader. If you
> > choose to use Merlin specific xml format then you will be bound to
> > Merlin.
> >
> > What is the problem with that?
>
> IIUC Merlin has features that Phoenix doesn't have (and viceversa).
> If I write a component that uses these "features", it will not run in
> other containers.
The ContainerKit model does not state anything about these "features". It
gives a mechanism to define metadata and extend that metadata with
attributes.
A container can decide to add "features" by handling specific attributes and
components can declare those attributes. The conatiner can also decide to
handle specific types of components. ie if object is Persistent then call
Persistent.persist()
Some of these features are required by container and we would need to
standardize an attribute name to indicate required "features". However as
soon as you require such a feature you loose strict compatability (though
other containers that support feature can still run component).
> We would all like Components that run in *all* Containers
> But we still have and want to have different Containers that have
> proprietary semantics. And this creates problems in portability, since
> it has happened that some James Components are tied to Phoenix specific
> things, and they didn't even realize it.
>
> - How can I run Merlin-specific components in Phoenix?
> - How can I run Phoenix-specific components in Merlin?
> - How can I be *aware* that I'm using Container specific stuff versus
> Avalon baseline?
>
>
> IMHO it would seem that the first two points can be done using a correct
> Container hierarchy.
possibly. We need to figure out a way to dynamically compose services for that
to work but thats certainly possible (actually I just posted something about
this onphoenix list).
> And that the last one by defining a standard way of *describing*
> extensions (ie in what "context" they are made and what they need) and
> keeping this description physically separate from the standard
> containerkit descriptor.
Thats sorta what I was saying. Except that I am not sure I would want to
standardize the format of the extension descriptor (ie a Foo-persistent.xml
is gonna look much different from Foo-instrument.xml). However a standard way
of defining that the component supports or requires a "feature" seems
possible. However the exact semantics of the "feature" is left up to
container/feature writer. They should feel free to do it however the hell
they like.
> Also the standard containerkit stuff would become part of the framework,
> since it would become mandatory.
Thats largely where I am going. In a month or two I hope to have tested it
thouroughly enough that it can be put up to vote.
--
Cheers,
Peter Donald
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>>
>>> We want to get an agreement on what to do for the present and future
>>> with regards to unified Component Model, Merlin, Fortress, Phoenix,
>>> et all.
>>>
>>> "Discussions get forgotten, just code remains."
>>>
>>> I will strongly oppose and veto any "compromise".
>>> I want the *solution*.
>>
>>
>>
>> The only real solution is to use the ContainerKit model. With it you
>> get will compatability between all the containers. Phoenix will use
>> it directly while Merlin will load it through its own Type loader. If
>> you choose to use Merlin specific xml format then you will be bound
>> to Merlin.
>> What is the problem with that?
>
>
> IIUC Merlin has features that Phoenix doesn't have (and viceversa).
Correct - Merlin is second generation container.
It's design leverages the strengths and and elimiates the limitations of
the Phoenix system.
Merlin reolves the facility management issue that has plaugesd Phoenix.
Merlin eliminates the very complex assembly declaration procedures in
Phoinix that limit adoption.
Merlin embrasses user requirements from across the Avalon sprctrum.
Merlin delivers a complete context management solution.
Merlin delivers a complete extension platform.
>
> If I write a component that uses these "features", it will not run in
> other containers.
Correct.
A component that includes extension depedencies currently requires the
Merlin/Fortress container model. Phoenix does not provide a validation
framework so it cannot tell you if a component will run or not - you
simply wait for the runtime exception.
>
> Thus, there is no full compatibility between containers.
I belive there are two levels:
* validation - the ability of a ALL containers to pass a validation
stage on the componet type they are supplied with and from that
information, fail gracefully, or, find another component solution. In
the Merlin case this ois possible because Merlin executes validation opf
compoennts in the creation of an assembly graph. In Phoneix there is no
equivalent process.
* deployment - deployment concerns the execution of a valid component.
Cross container deployment requires that there is concensus on things
like lifestyle policies. Merlin povides the complete lifestyle policies
based on the Fortress model. Phoneix is much more limited in this
respect - in fact, based on my kbnowege of Phoeix it's lifestylesupport
is limited to thread-safe components.
>
>
> On one hand, it seems that specifying how to extend the Container
> could solve the problems.
> But as you correctly point out, it's a too big commitment ATM. And a
> similar approach has already failed IIUC.
>
> We would all like Components that run in *all* Containers
> But we still have and want to have different Containers that have
> proprietary semantics. And this creates problems in portability, since
> it has happened that some James Components are tied to Phoenix
> specific things, and they didn't even realize it.
>
> - How can I run Merlin-specific components in Phoenix?
Merlin will be executable inside Phoeix in the very near future.
You will see Merlin as a SAR application managing the complete component
deployment solution. You will also be able to include the Merlin Kernel
as a componet within another application. Both solutions will allow the
embededing of a Foresss container inside Merlin and the managemnt of the
late binding approach used in ECM style compoents and Cocoon.
>
> - How can I run Phoenix-specific components in Merlin?
It's already possible.
I'm running several of the Corbnerstone components inside Merlin on a
day-to-day basis.
I have not provided support for Phoenix specifics such as BlckListener
or ApplicationListener on the grounds of (a) zero demand, and (b) that
the extension mechansisms provide the functionality neeed i a container
independent manner.
>
> - How can I be *aware* that I'm using Container specific stuff versus
> Avalon baseline?
The ONLY solution is to establish concensus on features that a container
needs to recognize.
Recognition of a feature is fundimentation to validation.
Validation is the criteria for Avalon wide container
minimal-quality-of-service.
>
>
> IMHO it would seem that the first two points can be done using a
> correct Container hierarchy.
>
> And that the last one by defining a standard way of *describing*
> extensions (ie in what "context" they are made and what they need) and
> keeping this description physically separate from the standard
> containerkit descriptor.
You still need containers to take responsibility about validation.
Introducing the obligation into Phoenix to validate that a component
does not expose extension or stage dependencies is something trivial to
implement. In fact it wa done in a couple hours by myself but deleted
by Pete. There is no rocket science here - just recognition of a common
set of fesatures and predictable behaiour from a container.
>
> Also the standard containerkit stuff would become part of the
> framework, since it would become mandatory.
It's probably a terminology thing - but "standard containerkit"is a
definate -1.
Containekit mixes into one package meta-info, meta-data and container
utilities that are not workable in a general envioronmenmt. If you mean
a standard meta-info model (which is what I think you mean), then I'm
totally in agreement.
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: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>
>>We want to get an agreement on what to do for the present and future
>>with regards to unified Component Model, Merlin, Fortress, Phoenix, et all.
>>
>>"Discussions get forgotten, just code remains."
>>
>>I will strongly oppose and veto any "compromise".
>>I want the *solution*.
>
>
> The only real solution is to use the ContainerKit model. With it you get will
> compatability between all the containers. Phoenix will use it directly while
> Merlin will load it through its own Type loader. If you choose to use Merlin
> specific xml format then you will be bound to Merlin.
>
> What is the problem with that?
IIUC Merlin has features that Phoenix doesn't have (and viceversa).
If I write a component that uses these "features", it will not run in
other containers.
Thus, there is no full compatibility between containers.
On one hand, it seems that specifying how to extend the Container could
solve the problems.
But as you correctly point out, it's a too big commitment ATM. And a
similar approach has already failed IIUC.
We would all like Components that run in *all* Containers
But we still have and want to have different Containers that have
proprietary semantics. And this creates problems in portability, since
it has happened that some James Components are tied to Phoenix specific
things, and they didn't even realize it.
- How can I run Merlin-specific components in Phoenix?
- How can I run Phoenix-specific components in Merlin?
- How can I be *aware* that I'm using Container specific stuff versus
Avalon baseline?
IMHO it would seem that the first two points can be done using a correct
Container hierarchy.
And that the last one by defining a standard way of *describing*
extensions (ie in what "context" they are made and what they need) and
keeping this description physically separate from the standard
containerkit descriptor.
Also the standard containerkit stuff would become part of the framework,
since it would become mandatory.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
>
>
>>We want to get an agreement on what to do for the present and future
>>with regards to unified Component Model, Merlin, Fortress, Phoenix, et all.
>>
>>"Discussions get forgotten, just code remains."
>>
>>I will strongly oppose and veto any "compromise".
>>I want the *solution*.
>>
>>
>
>The only real solution is to use the ContainerKit model.
>
<snip missleading contet/>
>What is the problem with that?
>
>
Lots.
* no suport for the management of lifestyle extensions
* no support for the management of dynamic context
* not support for type based default configurations
* impossible to use in dynamic assembly scenarios
* does not incorporate requires from other projects
* is controlled by Pete
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: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
...
> Actually just rejoined the xdoclet team and gonna try to get them to do a
> stable release soonish. If worse comes to worse we can grab velocity and whip
> up a lightweight xdoclet clone that is stable enough for our purposes.
You might want to take a look at
http://sourceforge.net/projects/vdoclet/ , it has also a BSD license.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
XDoclet containerkit failure
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Tue, 20 Aug 2002 00:19, Berin Loritsch wrote:
>
>
>>I would like to detail the differences between ContainerKit and
>>Merlin's Type model. What are the benefits, and what are the
>>bad points?
>>
>>
>
>The differences essentially amount to CK not supporting stages or extensions.
>It does not do this as there has not been sufficient testing or real life
>usage for such additions to be standardized upon.
>
>
>
>>BTW, is the XDoclet support for the *.info files going to move
>>to Excalibur? I would really like to see that in ContainerKit
>>or something so that we don't have to write all kinds of XINFO
>>files.
>>
>>
>
>Already there. Have a look at
>
>containerkit/src/java/org/apache/avalon/excalibur/containerkit/kernel/sample/Component1.java
>
Try running the containerkit xdoclet target.
BUILD FAILED
file:F:/dev/jakarta-avalon-excalibur/containerkit/build.xml:284:
java.lang.NullPointerException
--
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: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Tue, 20 Aug 2002 00:19, Berin Loritsch wrote:
> I would like to detail the differences between ContainerKit and
> Merlin's Type model. What are the benefits, and what are the
> bad points?
The differences essentially amount to CK not supporting stages or extensions.
It does not do this as there has not been sufficient testing or real life
usage for such additions to be standardized upon.
> BTW, is the XDoclet support for the *.info files going to move
> to Excalibur? I would really like to see that in ContainerKit
> or something so that we don't have to write all kinds of XINFO
> files.
Already there. Have a look at
containerkit/src/java/org/apache/avalon/excalibur/containerkit/kernel/sample/Component1.java
for an annotated file.
> For instance, I see stuff like this in Cornerstone:
>
> /**
> * @phoenix:block
> * @phoenix:service
> org.apache.avalon.cornerstone.services.connect.ConnectionManager
> */
> class DefaultConnectionManager implements ConnectionManager //, ....
> {/* ... */}
>
>
> But to me it would be more intuitive to have the interface marked
> with an "@avalon:service" and the implementation marked with an
> "@avalon:component".
I tried that originally but there is a few problems with xdoclet. The main
issue is that if we were to do that we woul need to load all the services via
xdoclet, and potentially all super classes of service. However marking all
metadata for one component on that component makes the xdoclet processing
much faster (in the order of 20-30 times faster) and also means we punt (at
the moment) for trying to figure out inheritance basis for metadata.
Actually just rejoined the xdoclet team and gonna try to get them to do a
stable release soonish. If worse comes to worse we can grab velocity and whip
up a lightweight xdoclet clone that is stable enough for our purposes.
> These things will also allow us to update the Excalibur components
> so that they use the metainfo additions in the javadocs--and make it
> easier to migrate Cocoon to a proper container system.
I have already done the xmlutil and sourceresolve ones but not yet committed
em. I wanted to evolve ContainerKit to its resting place before we started
effecting other components. So if you do do it then skip those.
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
XDoclet status
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>BTW, is the XDoclet support for the *.info files going to move
>to Excalibur? I would really like to see that in ContainerKit
>or something so that we don't have to write all kinds of XINFO
>files.
>
The XDoclet project is in the process of moving from the Sun javadoc API
to something else called xjavadoc. The code suppporting the XDoclet
generation for containerkit and Phoenix uses an out-of-date CVS version
of the XDoclet project (really out-of-out). Any work on a solution for
avalon xinfo files using XDoclet in its current status is in my opinion
premature. As soon as the XDoclet team produce a release I'll either
put something in place in the Avalon Meta Model package or I'll adapt
from something that Pete comits.
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>
Differences between the Avalon Meta Model and containerkit
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>I would like to detail the differences between ContainerKit and
>Merlin's Type model. What are the benefits, and what are the
>bad points?
>
A comparison between containerkit and the Avalon Meta Models
============================================================
There are two meta models being discussed here. One is the
containerkit, the second is the Avalon Meta Info Model that
was created as fork of the containerkit model and is used
within the Merlin container.
Differences:
------------
The Avalon Meta Model is strictly concerning with a
component type and does not include any meta-data. The
containerkit package contains meta-info, meta-data and
several utilities the artificially constrain a container
implementation.
As such, one has to ignore the majority of containerkit
before a comparison can be made. The comparable structures
concern the meta-info layer. The differences between the
the two are described below.
Meta-Info Model:
----------------
Both containerkit and the Avalon Meta Model define a set
of immutable classes that collectively define a type of
component. The containerkit primary class is the
ComponentInfo class. The equivalent in the Avalon Meta
Model is the Type class.
The following features are provided under the Avalon
Meta Model. No equivalent support exists within
containerkit.
* The Avalon Meta Model includes support for a component
type to declare a dependency towards an lifestyle stage
extension. This is very similar to the classic notion
of a component declaring a dependency on a service.
However, unlike a service dependency, a stage dependency
is a dependency that must be dealt with by a container at
a different time to service dependencies (hence the
separation).
* The Avalon Meta Model includes support for a component
to declare itself as a lifestyle stage handler - often
referred to as an extension, or extension handler. The
notion of an extension is very similar to the classic
notion of a component's ability to provide a service (i.e.
it's services declaration). As the application of
extensions is a separate concern to the resolution of
component dependency providers, the declaration of a
component's ability to provide extension stage handling
is declared separately.
* The Avalon Meta Model includes the support for default
information associated with a component type.
Avalon Meta Model lifestyle attribute:
--------------------------------------
Lifestyle attributes are declared within the scope of the
component info attributes block. The ability to declare
such attributes is equivalent between containerkit and the
Avalon Meta Model, however, interpretation of some
attributes is required for component type portability.
There attributes are listed here:
Key Value
avalon:lifestyle singleton|thread|pooled|transient
The above summary provides the breakdown of the functional
differences between the Avalon Meta Model and the comparable
sub-set of containerkit. Aside from functional differences, the
processes associated with the two initiatives are different. The
existence of the Avalon Meta Model was brought into existence as
a result of a necessary fork of containerkit. Since that time,
the Avalon Meta Model has evolved primarily as a result of the
user requirements introduced by the Cocoon project, the Merlin
project, and the Fortress project.
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: DTD compat -- red herring?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
> > We want to get an agreement on what to do for the present
> and future
> > with regards to unified Component Model, Merlin, Fortress,
> Phoenix, et
> > all.
> >
> > "Discussions get forgotten, just code remains."
> >
> > I will strongly oppose and veto any "compromise".
> > I want the *solution*.
>
> The only real solution is to use the ContainerKit model. With
> it you get will
> compatability between all the containers. Phoenix will use it
> directly while
> Merlin will load it through its own Type loader. If you
> choose to use Merlin
> specific xml format then you will be bound to Merlin.
>
> What is the problem with that?
I would like to detail the differences between ContainerKit and
Merlin's Type model. What are the benefits, and what are the
bad points?
BTW, is the XDoclet support for the *.info files going to move
to Excalibur? I would really like to see that in ContainerKit
or something so that we don't have to write all kinds of XINFO
files.
I also would like to know how to best apply the javadoc additions.
For instance, I see stuff like this in Cornerstone:
/**
* @phoenix:block
* @phoenix:service
org.apache.avalon.cornerstone.services.connect.ConnectionManager
*/
class DefaultConnectionManager implements ConnectionManager //, ....
{/* ... */}
But to me it would be more intuitive to have the interface marked
with an "@avalon:service" and the implementation marked with an
"@avalon:component".
That way, any component that extends a service interface will have
its entry added in the <services/> element automatically. It makes
sense to me--much more than seeing it on one block's javadoc but not
on another.
These things will also allow us to update the Excalibur components
so that they use the metainfo additions in the javadocs--and make it
easier to migrate Cocoon to a proper container system.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Mon, 19 Aug 2002 23:44, Nicola Ken Barozzi wrote:
> We want to get an agreement on what to do for the present and future
> with regards to unified Component Model, Merlin, Fortress, Phoenix, et all.
>
> "Discussions get forgotten, just code remains."
>
> I will strongly oppose and veto any "compromise".
> I want the *solution*.
The only real solution is to use the ContainerKit model. With it you get will
compatability between all the containers. Phoenix will use it directly while
Merlin will load it through its own Type loader. If you choose to use Merlin
specific xml format then you will be bound to Merlin.
What is the problem with that?
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Mon, 19 Aug 2002 23:26, Berin Loritsch wrote:
...
>>I personally
>>didn't care one way or the other until it caused problems and I
>>had to create my own pooling code.
>
> What are you talking about?! I had to argue for weeks with you to remove it
> from framework. The compromise was that you could keep the ThreadSafe in
> framework.
Most of us don't give a *damn* about what happened in the past with the
code.
We want to get an agreement on what to do for the present and future
with regards to unified Component Model, Merlin, Fortress, Phoenix, et all.
"Discussions get forgotten, just code remains."
I will strongly oppose and veto any "compromise".
I want the *solution*.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: DTD compat -- red herring?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Mon, 19 Aug 2002 23:26, Berin Loritsch wrote:
> > > From: Peter Donald [mailto:peter@apache.org]
> > >
> > > On Mon, 19 Aug 2002 18:35, Leo Simons wrote:
> > > > agreed. However, defining a container API that allows
> > >
> > > plugging of any
> > >
> > > > facility using an event- or pipeline- like architecture
> > >
> > > seems a nice
> > >
> > > > idea, and the current work to enable this is definately
> > >
> > > moving in the
> > >
> > > > right direction.
> > >
> > > I remember quite a few people remarking how Component marker
> > > interface was a good idea, or ComponentSelector was a
> great idea, or
> > > that all the Poolable,
> > > Threadsafe etc interfaces were good ideas. Is this idea good
> > > in the same way?
> > > I think a little wider testing is needed before you could
> adopt it.
> >
> > Uh, Component was legacy, from before either of us started using
> > Avalon.
>
> And I wanted it removed before we went beta but that was vetoed.
>
> > Poolable was your interface if I am not mistaken?
>
> Maybe or possibly Stefanos.
>
> > I personally
> > didn't care one way or the other until it caused problems
> and I had to
> > create my own pooling code.
>
> What are you talking about?! I had to argue for weeks with
> you to remove it
> from framework. The compromise was that you could keep the
> ThreadSafe in
> framework.
I was talking about Poolable. I know Giacomo and other
Cocooner's wanted to get the "lifestyle" for the components
nailed down. I supported getting something done sooner than
later.
Bottom line is that we have learned our lesson, and we are coming
along with the solution--but it is slow in coming.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Mon, 19 Aug 2002 23:26, Berin Loritsch wrote:
> > From: Peter Donald [mailto:peter@apache.org]
> >
> > On Mon, 19 Aug 2002 18:35, Leo Simons wrote:
> > > agreed. However, defining a container API that allows
> >
> > plugging of any
> >
> > > facility using an event- or pipeline- like architecture
> >
> > seems a nice
> >
> > > idea, and the current work to enable this is definately
> >
> > moving in the
> >
> > > right direction.
> >
> > I remember quite a few people remarking how Component marker
> > interface was a
> > good idea, or ComponentSelector was a great idea, or that all
> > the Poolable,
> > Threadsafe etc interfaces were good ideas. Is this idea good
> > in the same way?
> > I think a little wider testing is needed before you could adopt it.
>
> Uh, Component was legacy, from before either of us started using
> Avalon.
And I wanted it removed before we went beta but that was vetoed.
> Poolable was your interface if I am not mistaken?
Maybe or possibly Stefanos.
> I personally
> didn't care one way or the other until it caused problems and I
> had to create my own pooling code.
What are you talking about?! I had to argue for weeks with you to remove it
from framework. The compromise was that you could keep the ThreadSafe in
framework.
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: DTD compat -- red herring?
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Mon, 19 Aug 2002 18:35, Leo Simons wrote:
> > agreed. However, defining a container API that allows
> plugging of any
> > facility using an event- or pipeline- like architecture
> seems a nice
> > idea, and the current work to enable this is definately
> moving in the
> > right direction.
>
> I remember quite a few people remarking how Component marker
> interface was a
> good idea, or ComponentSelector was a great idea, or that all
> the Poolable,
> Threadsafe etc interfaces were good ideas. Is this idea good
> in the same way?
> I think a little wider testing is needed before you could adopt it.
Uh, Component was legacy, from before either of us started using
Avalon.
Poolable was your interface if I am not mistaken? I personally
didn't care one way or the other until it caused problems and I
had to create my own pooling code.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Mon, 19 Aug 2002 18:35, Leo Simons wrote:
> agreed. However, defining a container API that allows plugging of any
> facility using an event- or pipeline- like architecture seems a nice
> idea, and the current work to enable this is definately moving in the
> right direction.
I remember quite a few people remarking how Component marker interface was a
good idea, or ComponentSelector was a great idea, or that all the Poolable,
Threadsafe etc interfaces were good ideas. Is this idea good in the same way?
I think a little wider testing is needed before you could adopt it.
> Similarly, systems that completely expose their pipeline like Axis,
> JEdit, to me show that it *is* possible to provide a common pluggability
> architecture.
As does cocoon, almost all enterprise/distributed servers (be they plain
rmi-like servers to EJB/CORBA servers). Even TC3 and TC4 has the notion of
interceptors. Now how many of them are actually compatible ...
JEdit is a specific container, Axis is a specific container - have you got any
examples apart from CORBA where there is a common API for extending servers?
> conceptually, that would be okay. However, it is impossible to
> anticipate in advance all the lifecycle phases important enough to
> support.
bingo!
> > We could standardize on an component attribute name that lists a set of
> > required phases that the container must implement to run component
>
> I hope you don't mean
>
> class MyComponent
> {
> public static final String CUSTOM_LIFECYCLE_REQUIREMENTS =
> "Persistence,Transaction,Command";
>
> // ...
> }
nope. In the ComponentInfo.getComponentDescriptor().getAttribute( "somekey" );
> > but other
> > than that I really don't see the need for any changes to existing
> > ContainerKit model.
>
> one issue I see is decreased reusability of the container. If changes by
> the client to the internals of a container are neccessary for the client
> to get support for their custom lifecycle needs, that is a big minus.
>
> The other option is to allow (for example) classes to be added to the
> container by putting a jar file in the container lib directory (or added
> through some other mechanism like JMX) and modifying an XML
> configuration file. Again, Axis shows it can be done cleanly.
JBoss does it fairly nice aswell, as does TC4 as does X ...
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Leo Simons <le...@apache.org>.
On Sun, 2002-08-18 at 23:00, Peter Donald wrote:
> On Sun, 18 Aug 2002 23:51, Peter Royal wrote:
> > Pete: You describe some "hairy" problems
> > (http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
> > can work through them, yes?
>
> The problems can be worked through and have been many times in the past. It
> basically comes down to different tradeoffs. Much like Context
> implementations it becomes relatively container specific as soon as you add
> any useful features to it.
>
> You can develope API layers to abstract these things in the container and
> allow container plugins. However even if this is done we would need a lot of
> testing before it became something we could promote to framework CVS.
true. Still, I do feel controlled plugin support for well-defined
problem spaces with low container impact is something we can do in the
4.x series of framework. The lifecycle extension setup as recently
discussed by Marcus et al is, IMO, approaching a point where it could be
moved to framework.
> Consider the case of EJB model. The client API to concerns (say persistence)
> is relatively stable and works across containers. However the Persistent
> manager/engine/facility API is different for every different container.
>
> ie I suspect it would be impossible to directly move a persistence manager (or
> Transaction Manager or whatever) from JBoss to Weblogic, Websphere, OpenEJB
> or Jonas. You would need container specific abstraction layers in each case.
>
> We could define a container API for each of those facilities but I think it
> would be a mistake as it unecessarily constrains evolution.
agreed. However, defining a container API that allows plugging of any
facility using an event- or pipeline- like architecture seems a nice
idea, and the current work to enable this is definately moving in the
right direction.
Similarly, systems that completely expose their pipeline like Axis,
JEdit, to me show that it *is* possible to provide a common pluggability
architecture.
> We should defining the client interface and allow the container writer the
> freedom of how they implement it. This is how most of the successful specs
> evolve so I don't see a problem with this approach.
+1
> So if a Persistence phase is needed then we can define its client API and see
> how it works. If it ends up working brilliantly in a wide enough range of
> situations then we can import the API into framework
conceptually, that would be okay. However, it is impossible to
anticipate in advance all the lifecycle phases important enough to
support. Initial work on the lifecycle definition took years and years,
and yet there is valid need for extension.
Thus, I would rather see a mechanism that would allow the client to plug
in their specific lifecycle extension needs into any avalon container.
<snip explanation of ComponentInfo support for extensions/>
> We could standardize on an component attribute name that lists a set of
> required phases that the container must implement to run component
I hope you don't mean
class MyComponent
{
public static final String CUSTOM_LIFECYCLE_REQUIREMENTS =
"Persistence,Transaction,Command";
// ...
}
...as it seems to me that is storing metadata inside java sources....?
> but other
> than that I really don't see the need for any changes to existing
> ContainerKit model.
one issue I see is decreased reusability of the container. If changes by
the client to the internals of a container are neccessary for the client
to get support for their custom lifecycle needs, that is a big minus.
The other option is to allow (for example) classes to be added to the
container by putting a jar file in the container lib directory (or added
through some other mechanism like JMX) and modifying an XML
configuration file. Again, Axis shows it can be done cleanly.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Sun, 18 Aug 2002 23:51, Peter Royal wrote:
>
>>Pete: You describe some "hairy" problems
>>(http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
>>can work through them, yes?
>
>
> The problems can be worked through and have been many times in the past. It
> basically comes down to different tradeoffs. Much like Context
> implementations it becomes relatively container specific as soon as you add
> any useful features to it.
>
> You can develope API layers to abstract these things in the container and
> allow container plugins. However even if this is done we would need a lot of
> testing before it became something we could promote to framework CVS.
>
> Consider the case of EJB model. The client API to concerns (say persistence)
> is relatively stable and works across containers. However the Persistent
> manager/engine/facility API is different for every different container.
>
> ie I suspect it would be impossible to directly move a persistence manager (or
> Transaction Manager or whatever) from JBoss to Weblogic, Websphere, OpenEJB
> or Jonas. You would need container specific abstraction layers in each case.
>
> We could define a container API for each of those facilities but I think it
> would be a mistake as it unecessarily constrains evolution.
Has this to do with the discussion we had about "make your container"
versus "use existing containers"?
If it is, I think I understand.
ECM was used by Cocoon as a CM, but I think that in many cases if Cocoon
created his own container, things would have been much better.
Conceptually, it would seem neat to have a "generic" container with
pluggable stages-phases, but you say IIUC that it's too complicated and
making an ad-hoc one is much easier and more efficient?
Hmmm...
The problem is that if we want Components that are reusable across
Containers, we must tell the Container what to expect, and how to treat
the Component.
Granted, some containers might not work, but we have a standard way of
telling the container about the handling of the Component.
We would standardize the *contract*, which seems a good thing...
> We should defining the client interface and allow the container writer the
> freedom of how they implement it. This is how most of the successful specs
> evolve so I don't see a problem with this approach.
>
> So if a Persistence phase is needed then we can define its client API and see
> how it works. If it ends up working brilliantly in a wide enough range of
> situations then we can import the API into framework and support for it in
> ComponentInfo. Until then we can just store extra data in a file side-by-side
> class file or have an attribute of component define its location. ie We could
> define
>
> com/biz/MyPersistent.java
> com/biz/MyPersistent-persist.xml
>
> If we want transaction orientated extensions then we can add that, if we want
> instrument extensions then we can add that, if we want remoting extensions
> then we can add that (and so on and so forth).
Ah, ok. Well, it's basically the same thing, you still define a
contract, but in this case, you clearly separate the "endorsed"
contracts and the "extension" contracts.
This is interesting, since it makes it much more easy to track
evolution... but we end up with different versions of the "standard"
contract... which would be the case anyway, I guess today's uber DTD
will still have to be changed down the road...
But...
The main point is that with Merlin you can not only tell the Container
what it has to do, but also *how* to do it, ie what special provider can
be used to make the Container handle the extension.
This is quite neat it seems.
> The ComponentInfo structure was design to allow extensions to sit side-by-side
> while they evolve or to be integrated directly into ComponentInfo class in
> the future.
>
> We could standardize on an component attribute name that lists a set of
> required phases that the container must implement to run component but other
> than that I really don't see the need for any changes to existing
> ContainerKit model.
I think that as for the "contract" definition goes, this is not
equivalent to what Merlin provides.
Let's say that we put extensions in a different file, ok, no big deal,
it can give advantages as said above... but it still hampers the ability
to make Components work across Containers.
If we add to this "extension" the ability to specify *how* to extend, we
gain in compatibility.
And once the feature passes from "extension" to "standard", it can be
done by the Container itself, maybe also better.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 18 Aug 2002 23:51, Peter Royal wrote:
>
>>Pete: You describe some "hairy" problems
>>(http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
>>can work through them, yes?
>>
>
>The problems can be worked through and have been many times in the past. It
>basically comes down to different tradeoffs. Much like Context
>implementations it becomes relatively container specific as soon as you add
>any useful features to it.
>
>You can develope API layers to abstract these things in the container and
>allow container plugins. However even if this is done we would need a lot of
>testing before it became something we could promote to framework CVS.
>
Based on the work undertake on the Fortress/Merlin combined lifestyle
management - the actual implact is very minimal - two container
independent interfaces.
F:\content\doc\merlin\api\assembly\org\apache\excalibur\container\lifecycle\package-summary.html
Implemetation of these interrfaces are in place.
Demonstrations are available.
>
>Consider the case of EJB model. The client API to concerns (say persistence)
>is relatively stable and works across containers. However the Persistent
>manager/engine/facility API is different for every different container.
>
>ie I suspect it would be impossible to directly move a persistence manager (or
>Transaction Manager or whatever) from JBoss to Weblogic, Websphere, OpenEJB
>or Jonas. You would need container specific abstraction layers in each case.
>
>We could define a container API for each of those facilities but I think it
>would be a mistake as it unecessarily constrains evolution.
>
I agreee.
>
>We should defining the client interface and allow the container writer the
>freedom of how they implement it. This is how most of the successful specs
>evolve so I don't see a problem with this approach.
>
This is equivalent to the Merlin/Fortress solution.
An implementation and container indepents interface specfication.
>
>So if a Persistence phase is needed then we can define its client API and see
>how it works. If it ends up working brilliantly in a wide enough range of
>situations then we can import the API into framework and support for it in
>ComponentInfo.
>
Don't follow.
The requirement is to provide customer extension of the Avalon component
lifecycle in a manner that is well structured and consitent with the
current approach to component creation and access. It's not about
providing a Persistence phase one day and addreessing a Security phase
another day. It's about providing the abstraction of a pluggable phase/s.
>Until then we can just store extra data in a file side-by-side
>class file or have an attribute of component define its location. ie We could
>define
>
>com/biz/MyPersistent.java
>com/biz/MyPersistent-persist.xml
>
This would require the container to know about specific extension types.
The basically what we have been working hard to avoid.
>
>
>If we want transaction orientated extensions then we can add that, if we want
>instrument extensions then we can add that, if we want remoting extensions
>then we can add that (and so on and so forth).
>
>The ComponentInfo structure was design to allow extensions to sit side-by-side
>while they evolve or to be integrated directly into ComponentInfo class in
>the future.
>
The Type structure was designed to allow the natural incorporation of
lifestyle extensions but considering an extension as something
equivilent to the more familiar notions of component services and
component dependecies. In Merlin, extension providers are components
and are handled iun the same way a s service providers. Just as a
component may have service dependecies, a component may also have stage
depedencies. The container is responsible to assembly (i.e. the same
sort of thing you do in Phoenix today - but applied to lifestyles).
>
>We could standardize on an component attribute name that lists a set of
>required phases that the container must implement to run component but other
>than that I really don't see the need for any changes to existing
>ContainerKit model.
>
Attribute names are insufficient - you need a model that is relativly
parrallel with the notion fo service provision/dependency.
For the component providing an extension it needs to be able to publish
this ability. I.e. you need a reference to the lifestyle interface it
handles. This is just the same as the <services> concept in blockinfo
or containerkit - except is concerns the lifecycle. A component may
provide support for multilpe extensions. On the opposite side of the
equation you need to be able to express the stage interfaces that a
component is depednent on. This is just the same as the notion of
dependency declarations but applied to lifestyle extensions.
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: DTD compat -- red herring?
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 23:51, Peter Royal wrote:
> Pete: You describe some "hairy" problems
> (http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
> can work through them, yes?
The problems can be worked through and have been many times in the past. It
basically comes down to different tradeoffs. Much like Context
implementations it becomes relatively container specific as soon as you add
any useful features to it.
You can develope API layers to abstract these things in the container and
allow container plugins. However even if this is done we would need a lot of
testing before it became something we could promote to framework CVS.
Consider the case of EJB model. The client API to concerns (say persistence)
is relatively stable and works across containers. However the Persistent
manager/engine/facility API is different for every different container.
ie I suspect it would be impossible to directly move a persistence manager (or
Transaction Manager or whatever) from JBoss to Weblogic, Websphere, OpenEJB
or Jonas. You would need container specific abstraction layers in each case.
We could define a container API for each of those facilities but I think it
would be a mistake as it unecessarily constrains evolution.
We should defining the client interface and allow the container writer the
freedom of how they implement it. This is how most of the successful specs
evolve so I don't see a problem with this approach.
So if a Persistence phase is needed then we can define its client API and see
how it works. If it ends up working brilliantly in a wide enough range of
situations then we can import the API into framework and support for it in
ComponentInfo. Until then we can just store extra data in a file side-by-side
class file or have an attribute of component define its location. ie We could
define
com/biz/MyPersistent.java
com/biz/MyPersistent-persist.xml
If we want transaction orientated extensions then we can add that, if we want
instrument extensions then we can add that, if we want remoting extensions
then we can add that (and so on and so forth).
The ComponentInfo structure was design to allow extensions to sit side-by-side
while they evolve or to be integrated directly into ComponentInfo class in
the future.
We could standardize on an component attribute name that lists a set of
required phases that the container must implement to run component but other
than that I really don't see the need for any changes to existing
ContainerKit model.
--
Cheers,
Peter Donald
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
> Here is my proposed action plan.
>
> 1) Merlin/Fortress people do not commit code to the Phoenix CVS that
> is about Merlin/Fortress stuff. Phoenix is in beta IIRC, and things
> are already fixed. Let's get on with a release.
>
> 2) With the help of Paul Hammant, Peter Royal & friends we start a
> *profitable* discussion about what Merlin has to give Avalon, what the
> proposed new DTD gives, and get an agreement to a common DTD.
> Since we already have now two Containers (Merlin/Fortress in dev and
> Phoenix stable) that can use Cornerstone, and since Peter Donald seems
> to be going in the same direction of deprecating Blockinfo, we finally
> can lay out the one and only Avalon Component Spec.
>
> 3) We write documentation on how to use Merlin/Fortress in Phoenix.
> I want to be able to run a Merlin/Fortress App in Phoenix, and I think
> it's really possible.
> What the Merlin/Fortress integration is showing is that instead of
> three containers we can simply a layered container: Phoenix contains
> Merlin contains Fortress.
> With Fortress and Merlin there is overlap that is being overcome.
> We'd have to do it with Merlin/Phoenix too.
>
+1
This is a practical and workable plan.
Let's do it!
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: DTD compat -- red herring?
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>> I'd like to know one other thing. Somthing I thank may be part of
>> the bad karma here, have significant changes been submitted prior to
>> a decent discussion and a vote.
>
>
> This was hard to do.
> You can see that Fortress and Merlin are merging, due also to good
> communication.
> But communication is a two way thing... you can't open the door from
> the outside...
>
>> If yes, then we have a real simple way of ensuring accord in the
>> future....
>
>
> Getting people to discuss more extensively instead of vetoing with
> laconic statements?
> Getting people to participate to other containers?
>
> Peter Donald wrote:
> "No you summed it up well. All the containers I will work on will have
> a common model.
> "
>
> *I* will work on?
> Shouldn't it be "we"?
A small faux pas.
> "Currently this is evolving but getting closer to set and is basically
> defined in containerkit project. It would be great to see other
> containers reusing the shared components and this will happen in time.
>
> My initial
> motivation was to enable myrmidon, and cocoon sharing with Phoenix
> sharing as a fringe benefit.
>
> Hence in the future BlockInfo will probably be deprecated and replaced
> with the more comprehensive ComponentInfo. At that point there will be
> one recomended description format and tools will be made to transform
> BlockInfo files into ComponentInfo files and to make generation of
> info easy.
> "
>
> Ok, I agree.
>
> Then, since we are *all* of the same idea, let's define and vote this
> together.
>
> Here is my proposed action plan.
>
> 1) Merlin/Fortress people do not commit code to the Phoenix CVS that
> is about Merlin/Fortress stuff. Phoenix is in beta IIRC, and things
> are already fixed. Let's get on with a release.
>
> 2) With the help of Paul Hammant, Peter Royal & friends we start a
> *profitable* discussion about what Merlin has to give Avalon, what the
> proposed new DTD gives, and get an agreement to a common DTD.
> Since we already have now two Containers (Merlin/Fortress in dev and
> Phoenix stable) that can use Cornerstone, and since Peter Donald seems
> to be going in the same direction of deprecating Blockinfo, we finally
> can lay out the one and only Avalon Component Spec.
>
> 3) We write documentation on how to use Merlin/Fortress in Phoenix.
> I want to be able to run a Merlin/Fortress App in Phoenix, and I think
> it's really possible.
> What the Merlin/Fortress integration is showing is that instead of
> three containers we can simply a layered container: Phoenix contains
> Merlin contains Fortress.
> With Fortress and Merlin there is overlap that is being overcome.
> We'd have to do it with Merlin/Phoenix too.
A good plan. No, a great plan. It would defuse the situation currently
and allow us to push forward with a careful common direction for all
containers, but spec first, rather than code.
XP allows us to refactor at will. In the idea project, all can change
at will as long as it is a step nearer our end goal and that the pair
(and by implication the team) agree it is right.
By contrast, API developers (is not service/block with its XML an API?)
must move more slowly. Speed can be faster if nothing has been
released. We all know that is a critisism levelled at all Avalon
sub-projects in the past. Anyway, Phoenix being stable (and hopefully
going FCS soon) artificially slows down Merlin/Fortress as it has a
compatability baseline and a user community. Sad for Fortress/Merlin
but true. Just an observation.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
...
> I'd like to know one other thing. Somthing I thank may be part of the
> bad karma here, have significant changes been submitted prior to a
> decent discussion and a vote.
This was hard to do.
You can see that Fortress and Merlin are merging, due also to good
communication.
But communication is a two way thing... you can't open the door from the
outside...
> If yes, then we have a real simple way of
> ensuring accord in the future....
Getting people to discuss more extensively instead of vetoing with
laconic statements?
Getting people to participate to other containers?
Peter Donald wrote:
"No you summed it up well. All the containers I will work on will have a
common model.
"
*I* will work on?
Shouldn't it be "we"?
"Currently this is evolving but getting closer to set and is basically
defined in containerkit project. It would be great to see other
containers reusing the shared components and this will happen in time.
My initial
motivation was to enable myrmidon, and cocoon sharing with Phoenix
sharing as a fringe benefit.
Hence in the future BlockInfo will probably be deprecated and replaced
with the more comprehensive ComponentInfo. At that point there will be
one recomended description format and tools will be made to transform
BlockInfo files into ComponentInfo files and to make generation of info
easy.
"
Ok, I agree.
Then, since we are *all* of the same idea, let's define and vote this
together.
Here is my proposed action plan.
1) Merlin/Fortress people do not commit code to the Phoenix CVS that is
about Merlin/Fortress stuff. Phoenix is in beta IIRC, and things are
already fixed. Let's get on with a release.
2) With the help of Paul Hammant, Peter Royal & friends we start a
*profitable* discussion about what Merlin has to give Avalon, what the
proposed new DTD gives, and get an agreement to a common DTD.
Since we already have now two Containers (Merlin/Fortress in dev and
Phoenix stable) that can use Cornerstone, and since Peter Donald seems
to be going in the same direction of deprecating Blockinfo, we finally
can lay out the one and only Avalon Component Spec.
3) We write documentation on how to use Merlin/Fortress in Phoenix.
I want to be able to run a Merlin/Fortress App in Phoenix, and I think
it's really possible.
What the Merlin/Fortress integration is showing is that instead of three
containers we can simply a layered container: Phoenix contains Merlin
contains Fortress.
With Fortress and Merlin there is overlap that is being overcome.
We'd have to do it with Merlin/Phoenix too.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>Ok, we modify Phoenix to read the Type DTD, but what good does that do us if
>all components that have that DTD use the features that Phoenix does not
>support? What benefit do those components get from the richer DTD if they do
>not utilize its features?
>
>
Thus the DTD is part of the API? I think so.
>Is the DTD compatibility a red herring?
>
>
>imho, we need to resolve the 4 no's that exist between containerkit and type.
>
>Steve: I'm unsure of what the "extensions" are. Stage's are the lifecycle
>extensions, yes? If so how to extensions fit in?
>
>Pete: You describe some "hairy" problems
>(http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
>can work through them, yes?
>
Yes....
>Collectively we are a very smart bunch and can figure anything out.
>
>
>Any one final thought, PLUR
>(http://www.hyperreal.org/raves/spirit/plur/PLUR.html, to show my roots :) ..
>and it *is* apache related.. brian behlendorf started hyperreal..
>
>
But only with the Respect, noted as missing in Brian's doc.
I'd like to know one other thing. Somthing I thank may be part of the
bad karma here, have significant changes been submitted prior to a
decent discussion and a vote. If yes, then we have a real simple way of
ensuring accord in the future....
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: DTD compat -- red herring?
Posted by Stephen McConnell <mc...@apache.org>.
Peter Royal wrote:
>On Sunday 18 August 2002 06:15 am, Stephen McConnell wrote:
>
>
>>Consider the following three DTDs:
>>
>>
>> type blockinfo containerkit
>>
>> name yes yes yes
>> version yes yes yes
>> component attributes yes no yes
>> services yes yes yes
>> service attributes yes no yes
>> depedencies yes yes yes
>> dependecy attributes yes no yes
>> context criteria yes no yes
>> context attributes yes no yes
>> stage depedenciers yes no no
>> stage attributes yes no no
>> extension declarations yes no no
>> extension attributes yes no no
>>
>>
>>Using the Type DTD you can define a component what can be validated by
>>any container. You can deploy that component in any container in the
>>knowlege that you will get a validation failure if you try to load
>>something that a container does not support. Support is a container
>>issue - interoperability is a subject of the DTD. The DTD is not bound
>>to the API.
>>
>>
>
>I think I may see pdonald's object to type support in Phoenix... *MAY*...
>
>Why support loading a DTD that is not fully utilized?
>
Support is a subject for a container.
The DTD emnabled the harmosizxation of teminaology, data descriptyion
formats, and supporting tools.
>If a component is
>cross-container, shouldn't it have the lowest-common-denominator DTD to
>enable full portability vs having a richer DTD and the possiblity of a
>container rejecting the component due to unsupported features?
>
If you take the lowest comon denominator approach, then each container
will end up defining digffernet extensions to the base DTD. This means
that you end up with containers puting in place maps between different
concepts - and basically hinders the development of interoperable
components. With the one DTD approach, there are elements that fall
into two categories: (a) quality-of-service (e.g. logging catagory
declarations), and (b) functional constraints (e.g. a service, context
or phase depedency). In the case of functional constraints, a container
does not need to provide implemetation support but as a minimum, it
should be recognizing what it cannot support.
>
>Ok, we modify Phoenix to read the Type DTD, but what good does that do us if
>all components that have that DTD use the features that Phoenix does not
>support?
>
It provides you with incentive to do something about it. Phoenix isn't
the benchmark - the benchmark is what the user wants to do.
>What benefit do those components get from the richer DTD if they do
>not utilize its features?
>
Benefits:
* The ability to use common developent tools.
* A consitent terminology
* Component validation in all containers.
>
>
>Is the DTD compatibility a red herring?
>
>
>imho, we need to resolve the 4 no's that exist between containerkit and type.
>
>Steve: I'm unsure of what the "extensions" are. Stage's are the lifecycle
>extensions, yes? If so how to extensions fit in?
>
The <stage/> element defines a dependency the component has on a
lifestyle stage extension.
The <extension/> element is the declaration that a component can provide
extension handling.
I.e. this is similar to the paired notion of dependencies and services.
See Merlin documentation on this:
http://home.osm.net/doc/merlin/extensions.html
>
>Pete: You describe some "hairy" problems
>(http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
>can work through them, yes?
>
>Collectively we are a very smart bunch and can figure anything out.
>
>
>Any one final thought, PLUR
>(http://www.hyperreal.org/raves/spirit/plur/PLUR.html, to show my roots :) ..
>and it *is* apache related.. brian behlendorf started hyperreal..
>-pete
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>