You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/08/17 10:46:11 UTC
All committers please read -> Bad Karma is happening.
Folks,
There appears to be a little discord present in the avalon-dev list, and
hence the Avalon Developer community. I'd like to propose that we seek
to achieve multiple things ...
1) calm things down.
2) arbitrate between opposing factions
3) consider what is best for individual sub-projects of Avalon
constantly.
4) define whether we should be voting in advance or in arrears
of significant contributions to common projects (nobody gives
stuff what I do to apps/db/** right?)
5) aim to be all lovey-dovey from a point of time none to distant in
the future.
I'd like to vote +1 for each of the above to kick things off.
I'd also like to add something from a personal agenda:
6) each and every committer should consider xdocs source to be
temporarily
more important than java source and got on with some additions.
Even if
compiling it is strangely beyond them, I will consent to fix
compilation
issues
+1 for that too.
Non committers could voice their solidarity to the process by with a
single comment persuading us go with peacemaking if they believe it is best.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>> I don't like that Peter Donald thinks that Phoenix is "his code".
>>>
>>
>> He wrote most of it. It is mostly code he wrote. So you could call it
>> "his code".
>>
>
> You could .. I don't - its Avalon community project code.
With respect, I get fairly tetchy whe other talk of changes to AltRMI.
I'd hope they consult me about the grand design before firing changes
in. I do the same for other sub-projects where the other people have
led or nearly soloed the development. Though we have a flat structure,
there are some 'keepers' of various areas who we should and do treat
with respect. For example I treaded carefully on 'Enterprise' files
when I did lots of work on build files for apps/ .
>> I'm not sure. I do know that he is right more often than it seems. You
>> will also read "I told you so"s in his posts, and he is sometimes right
>> where all others are wrong.
>>
>
> In reality we are all right most of the time. Pete is nothing special
> - just more opinionated than most.
I very strongly think we should hold all Avalon committer is high
regard, and be seen to do so. We have jobs in our real lives. Words
like the above may hamper someone ability to get a job and I might
remind you these are hard times - jobs do not grow on trees anymore.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>Not that I have time for this, but I do feel it is neccessary to throw
>in some copper pieces here, especially as pete probably doesn't feel
>much like it anymore =)
>
>
>>I think that Phoenix is an very good program.
>>I think that Fortress and Merlin have a very good potential.
>>I'm sure that the multiple avalon repositories are a serious problem for
>>Avalon, because they fracture the community instead of keeping it together.
>>
>> I don't like that Peter Donald thinks that Phoenix is "his code".
>>
>
>He wrote most of it. It is mostly code he wrote. So you could call it
>"his code".
>
You could .. I don't - its Avalon community project code.
>
>
>Phoenix has gone through a gazillion different permutiations. A lot has
>been tried. Sometimes new people propose something, and it has already
>been done and it has been found lacking, so a -1 follows.
>
>That's pete, I think.
>
>
>> I think that Peter Donald is a very good coder.
>>
>>Heck, he has done large chunks of Phoenix, redefined big parts of
>>Avalon, and is helping to make Ant2.
>>
>> I think that Peter Donald is not good at discussing
>> things with other people.
>>
>>How come everyone else on this list comes to an agreement at some point
>>while Peter lately is really hard on -1s and "the sky will fall"?
>>
>
>I'm not sure. I do know that he is right more often than it seems. You
>will also read "I told you so"s in his posts, and he is sometimes right
>where all others are wrong.
>
In reality we are all right most of the time.
Pete is nothing special - just more opinionated than most.
>
>
>Why all the -1s lately, I don't know. It seems Pete is suffering from
>the symptoms found in many OSS developers that have been around for a
>long time: They get tired of the discussion, the repeated explanations
>time and time again, and just do their own thing (often just write
>code). When the community complains a lot, they leave in the end.
>
>Or, he could just be very busy =)
>
On this occasion I have to disagree with you. Pete has the time to
address the issues being raised. He's demonstrated this fact by going
to the effort of deleting bug fixes needed to resolve James runtime
failures. These are not old issue - they are new isues - but Pete is
choosing to ignore them and play a political game.
Pete's recent actions appear inconsitent and unrelated to the technical
reality of what's going on. In this context one needs to balance the
credibility that Pete has established over the years against his
immediate personal agenda.
>>How come since Peter came to Avalon have important Avalon coders and
>>thinkers left the group after heated discussions with Peter Donald?
>>
>
>dunno. I'm sure there's many sides to that.
>
>A more general point to add: software full of compromise is usually not
>the best. There's many jokes about that, one goes something like:
>
>A management executive is harassing one of his programmers who is
>working on an experimental new operating system, because the OS is
>behind schedule. When pressed, the programmer simply states that it is
>impossible to meet the deadline and he says it will take 2 more months
>to complete the software.
>After raving like a madman for a while, the executive says: "Okay, I'll
>hire 2 more programmers so we can make the deadline." The programmer
>responds: "No, then it will take 4 more months". Very annoyed with this
>delay, the executive in the end hires 100 more developers to finish the
>project in time.
>Windows still needs to come out of beta stage.
>
>We made a compromise when we released excalibur (cocoon needed it),
>which was stupid in hindsight. We made a compromise with the
>ComponentSelector, which was also pretty stupid. There's more examples.
>Pete was, in hindsight, right on both.
>
We can go down that track and we can but if wew do then look at the
other side of story.
Pete -1'ed the release of the Avalon Framework and was quickly corrected
by the intervention of a member of the PMC. Pete changes his mind too -
just like we all do from time to time - look at marker interfaces, look
at ComponentManager. Yes, his opinions are valuable - but so are the
opinions of all of the committers on Avalon - no more, no less.
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: All committers please read -> Bad Karma is happening.
Posted by Leo Simons <le...@apache.org>.
Not that I have time for this, but I do feel it is neccessary to throw
in some copper pieces here, especially as pete probably doesn't feel
much like it anymore =)
> I think that Phoenix is an very good program.
> I think that Fortress and Merlin have a very good potential.
> I'm sure that the multiple avalon repositories are a serious problem for
> Avalon, because they fracture the community instead of keeping it together.
>
> I don't like that Peter Donald thinks that Phoenix is "his code".
He wrote most of it. It is mostly code he wrote. So you could call it
"his code".
Phoenix has gone through a gazillion different permutiations. A lot has
been tried. Sometimes new people propose something, and it has already
been done and it has been found lacking, so a -1 follows.
That's pete, I think.
> I think that Peter Donald is a very good coder.
>
> Heck, he has done large chunks of Phoenix, redefined big parts of
> Avalon, and is helping to make Ant2.
>
> I think that Peter Donald is not good at discussing
> things with other people.
>
> How come everyone else on this list comes to an agreement at some point
> while Peter lately is really hard on -1s and "the sky will fall"?
I'm not sure. I do know that he is right more often than it seems. You
will also read "I told you so"s in his posts, and he is sometimes right
where all others are wrong.
Why all the -1s lately, I don't know. It seems Pete is suffering from
the symptoms found in many OSS developers that have been around for a
long time: They get tired of the discussion, the repeated explanations
time and time again, and just do their own thing (often just write
code). When the community complains a lot, they leave in the end.
Or, he could just be very busy =)
> How come since Peter came to Avalon have important Avalon coders and
> thinkers left the group after heated discussions with Peter Donald?
dunno. I'm sure there's many sides to that.
A more general point to add: software full of compromise is usually not
the best. There's many jokes about that, one goes something like:
A management executive is harassing one of his programmers who is
working on an experimental new operating system, because the OS is
behind schedule. When pressed, the programmer simply states that it is
impossible to meet the deadline and he says it will take 2 more months
to complete the software.
After raving like a madman for a while, the executive says: "Okay, I'll
hire 2 more programmers so we can make the deadline." The programmer
responds: "No, then it will take 4 more months". Very annoyed with this
delay, the executive in the end hires 100 more developers to finish the
project in time.
Windows still needs to come out of beta stage.
We made a compromise when we released excalibur (cocoon needed it),
which was stupid in hindsight. We made a compromise with the
ComponentSelector, which was also pretty stupid. There's more examples.
Pete was, in hindsight, right on both.
back to ritual beer drinking parties,
Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Sat, Aug 17, 2002 at 03:22:31PM +0200, Nicola Ken Barozzi wrote:
>
>>Jeff Turner wrote:
>>
>>>+1 on peace, lurrve and understanding. But that's kinda hard to enforce..
>>>
>>>The definition of -1, from http://jakarta.apache.org/site/decisions.html,
>>>says that "no veto can be overruled", and that the vetoee's only recourse
>>>is to "lobby the person who cast the veto". Tough luck if they prove
>>>lobby-resistant.
>>
>>But also:
>>
>>"All vetos must contain an explanation of why the veto is appropriate.
>>Vetos with no explanation are void."
>
> No quality of explanation is required though. "A little green leprechaun
> told me to" is perfectly valid. Nor is it required that the explanation
> be defended. Sad but true :P
I don't agree.
>>This is an option to consider.
>>It's about the rules4revolutionaries thinking.
>>But it always brings to fractures in the community, see the Tomcat 3/4
>>story.
>
> And thank goodness that Tomcat 3 was not quashed, as many wanted it to
> be. I really enjoy using 3. It's about twice as fast on startup as 4.
Gee, you're right, now I know what a good server has to have fast
startup times. Hey, let's call it "starter" instead of "server"! :-P
>>I think that Phoenix is an very good program.
>>I think that Fortress and Merlin have a very good potential.
>>I'm sure that the multiple avalon repositories are a serious problem for
>>Avalon, because they fracture the community instead of keeping it together.
>>
>> I don't like that Peter Donald thinks that Phoenix is "his code".
>>
>>If Stefano taught me something, is that code in CVS is just of all, not
>>of the original committer.
>
> Well, if experience has taught me anything, it's that 5% of people do 95%
> of the work in OSS.
And the rest do the testing, proposals and bugfixes.
OS is also about free testers, not only coders.
> Bill Gates could wipe out OSS with relatively few
> well-chosen assasinations :)
I'm always a bit scared when there is the ApacheCon ;-S
> Consequently, I'm for solutions that do not
> hinder that 5%. So +1 for branching and bugger the community ;)
You mean that to not hinder that 5% everyone must code alone and branch
away? :-O
> <ducks, runs, heads off to bed>
... you'd better ;-P
--
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: All committers please read -> Bad Karma is happening.
Posted by Jeff Turner <je...@apache.org>.
On Sat, Aug 17, 2002 at 03:22:31PM +0200, Nicola Ken Barozzi wrote:
>
> Jeff Turner wrote:
> >+1 on peace, lurrve and understanding. But that's kinda hard to enforce..
> >
> >The definition of -1, from http://jakarta.apache.org/site/decisions.html,
> >says that "no veto can be overruled", and that the vetoee's only recourse
> >is to "lobby the person who cast the veto". Tough luck if they prove
> >lobby-resistant.
>
> But also:
>
> "All vetos must contain an explanation of why the veto is appropriate.
> Vetos with no explanation are void."
No quality of explanation is required though. "A little green leprechaun
told me to" is perfectly valid. Nor is it required that the explanation
be defended. Sad but true :P
> This is an option to consider.
> It's about the rules4revolutionaries thinking.
> But it always brings to fractures in the community, see the Tomcat 3/4
> story.
And thank goodness that Tomcat 3 was not quashed, as many wanted it to
be. I really enjoy using 3. It's about twice as fast on startup as 4.
> I think that Phoenix is an very good program.
> I think that Fortress and Merlin have a very good potential.
> I'm sure that the multiple avalon repositories are a serious problem for
> Avalon, because they fracture the community instead of keeping it together.
>
> I don't like that Peter Donald thinks that Phoenix is "his code".
>
> If Stefano taught me something, is that code in CVS is just of all, not
> of the original committer.
Well, if experience has taught me anything, it's that 5% of people do 95%
of the work in OSS. Bill Gates could wipe out OSS with relatively few
well-chosen assasinations :) Consequently, I'm for solutions that do not
hinder that 5%. So +1 for branching and bugger the community ;)
<ducks, runs, heads off to bed>
--Jeff
> --
> 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: All committers please read -> Bad Karma is happening.
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> +1 on peace, lurrve and understanding. But that's kinda hard to enforce..
>
> The definition of -1, from http://jakarta.apache.org/site/decisions.html,
> says that "no veto can be overruled", and that the vetoee's only recourse
> is to "lobby the person who cast the veto". Tough luck if they prove
> lobby-resistant.
But also:
"All vetos must contain an explanation of why the veto is appropriate.
Vetos with no explanation are void."
Vetos are made to block things that cause problems, their use as "I
don't really like the code, it could cause maybe problems" is misuse
IMHO of the spirit and the meaning of the rules.
"Voters intending to veto an action item should make their opinions
known to the group immediately so that the problem can be remedied as
early as possible. "
The one who vetos should IMO work with the other person to find a common
solution.
> If it were my changes being vetoed by some complete bastard ;) I'd route
> around the problem. Commit the changes to a branch, and bring up the
> issue at another time. Add a README.txt to the project root, saying "Hey,
> there's this FOO branch where I've been committing stuff that committer P
> doesn't agree with. Come play if you like". Imagine: if *everyone*
> agrees with you, eventually only the vetoer will be left on the CVS head,
> developing in isolation. And when the finally crack, it's only one CVS
> command to make another branch the head.
This is an option to consider.
It's about the rules4revolutionaries thinking.
But it always brings to fractures in the community, see the Tomcat 3/4
story.
> The HALF_BRANCHING.txt file in Excalibur CVS describes how to branch just
> a few files, and create a script that allows others to easily adopt your
> branch.
>
> As a solution, it's inferior to P,L & U, but better than simply
> disregarding the rules about vetos, or giving up and abandoning Avalon.
There is another point.
Let me tell you all what I think. I may be wrong, but I'm free to
express my opinions.
I think that Phoenix is an very good program.
I think that Fortress and Merlin have a very good potential.
I'm sure that the multiple avalon repositories are a serious problem for
Avalon, because they fracture the community instead of keeping it together.
I don't like that Peter Donald thinks that Phoenix is "his code".
If Stefano taught me something, is that code in CVS is just of all, not
of the original committer.
That a veto cannot be used indefinitely and systematically to block a
community, part of it, or the work of another coder.
That people on the list must work together to achieve a common goal.
I think that Peter Donald is a very good coder.
Heck, he has done large chunks of Phoenix, redefined big parts of
Avalon, and is helping to make Ant2.
I think that Peter Donald is not good at discussing
things with other people.
How come everyone else on this list comes to an agreement at some point
while Peter lately is really hard on -1s and "the sky will fall"?
How come since Peter came to Avalon have important Avalon coders and
thinkers left the group after heated discussions with Peter Donald?
I have read some of your mails from the archive, Peter, and at times you
have had the same feeling that others have with you in these moments
with others.
And that others have alienated code from you just "because it comes from
Peter Donald".
Don't do the same error.
Collaborate.
I know that this is a strange letter, it seems like a rant agains Peter
Donald.
Well, let me tell you that if I didn't like Peter, I would not have used
my time to write this letter.
I hope you understand, Peter.
--
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: All committers please read -> Bad Karma is happening.
Posted by Jeff Turner <je...@apache.org>.
+1 on peace, lurrve and understanding. But that's kinda hard to enforce..
The definition of -1, from http://jakarta.apache.org/site/decisions.html,
says that "no veto can be overruled", and that the vetoee's only recourse
is to "lobby the person who cast the veto". Tough luck if they prove
lobby-resistant.
If it were my changes being vetoed by some complete bastard ;) I'd route
around the problem. Commit the changes to a branch, and bring up the
issue at another time. Add a README.txt to the project root, saying "Hey,
there's this FOO branch where I've been committing stuff that committer P
doesn't agree with. Come play if you like". Imagine: if *everyone*
agrees with you, eventually only the vetoer will be left on the CVS head,
developing in isolation. And when the finally crack, it's only one CVS
command to make another branch the head.
The HALF_BRANCHING.txt file in Excalibur CVS describes how to branch just
a few files, and create a script that allows others to easily adopt your
branch.
As a solution, it's inferior to P,L & U, but better than simply
disregarding the rules about vetos, or giving up and abandoning Avalon.
--Jeff
On, Aug 17, 2002 at 09:46:11AM +0100, Paul Hammant wrote:
> Folks,
>
> There appears to be a little discord present in the avalon-dev list, and
> hence the Avalon Developer community. I'd like to propose that we seek
> to achieve multiple things ...
>
> 1) calm things down.
>
> 2) arbitrate between opposing factions
>
> 3) consider what is best for individual sub-projects of Avalon
> constantly.
>
> 4) define whether we should be voting in advance or in arrears
> of significant contributions to common projects (nobody gives
> stuff what I do to apps/db/** right?)
>
> 5) aim to be all lovey-dovey from a point of time none to distant in
> the future.
>
> I'd like to vote +1 for each of the above to kick things off.
>
> I'd also like to add something from a personal agenda:
>
> 6) each and every committer should consider xdocs source to be
> temporarily
> more important than java source and got on with some additions.
> Even if
> compiling it is strangely beyond them, I will consent to fix
> compilation
> issues
>
> +1 for that too.
>
> Non committers could voice their solidarity to the process by with a
> single comment persuading us go with peacemaking if they believe it is best.
>
> Regards,
>
> - Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>>> 1) calm things down.
>>
>>
>>
>>
>> +1
>>
>> The biggest contributing factory will be some rational discussion
>> about changes.
>>
>>>
>>>
>>> 2) arbitrate between opposing factions
>>
>>
>>
>>
>> Here is a summary of my view of the issues:
>>
>> 1. Cornerstone
>>
>> Conerstone is an Avalon poject that includes several
>> utility components. Several of these components are
>> used within the scope of external projects in the
>> context of service and component managers. While
>> attempting to use the cornerstone jar from the CVS
>> with James, I encounter class cast exception when
>> a ComponentManager was attempring to return a
>> cornerstone component as a Component instance.
>>
>> I corrected this issue by reincluding the Component
>> interface. Pete has -1'ed the revision without
>> supplying an explination. Cornerstone remains broken.
>
>
> Well that is probably nearer my fault. I upgraded in Phoenix inside
> JAMES CVS. I should have put back the previous cornerstone.jar that
> they were using as it was Component using. We have known for months
> that JAMES has a problem with the removal of Component. The problem
> is one of backwards-compatability given that maillets are handed a
> Context which has getComponentManager() method (v eryun IoC). I'm
> taking this on the chin not Peter. The whole of the Avalon community
> mulled how to get rid of Component months ago and I, as an un-official
> JAMES laison, failed to reslove the remaining issue.
Sorry - this doesn't explain Pete's actions of deleting bug fixes or his
inability to respond to issued raised. Pete is preventing the solution -
that's an issue. Please, if you feel responsible for this then make the
changes and deal with Pete's -1's. I'll be more than happy!
>
>> 2. Cornerstone components have for a long time been
>> considered as a set of Phoenix blocks. With the
>> introduction of Merlin, we have the potential for
>> Cornerstone blocks to be used not only within the
>> scope of Phoenix, but across any other container that
>> supports the Avalon Meta Model DTD. To enable
>> containers other than Phoenix to use the
>> Cornerstone components, I added a set of resources
>> (equivalent to the .xinfo named .xtype to avoid
>> conflict with Phoenix). A modification to the
>> build file was made to include
>> the resources into the jar file. This modification
>> was -1'ed by Pete on the grounds of introducing
>> meta-info dependecies and Pete's desire to reserve
>> ".xprofile" for Phoenix - both arguments have addressed,
>> showing (a) no implied meta-info - its a DTD question,
>> and (b) a description of how one .something file can be
>> used with different DTD. No response, objection or
>> disagreement was raised by Pete to any of these
>> messages.
>
>
> It appears that the need for .xprofile and .xtype is the issue.
> Laymen, such as myself migh ask 'why is not .xinfo not sufficient'?
Phoenix reads in an xinfo file and does not take into consideration the
DTD. It assumes everyting is the blockinfo DTD. The recent update to
Phoenix that Pete -1'ed updated Phoenix so that a BlockInfo could be
created from both a blockinfo DTD and a Type DTD. That would have
enabled the elimination of the .xtype resources. However, Pete's
deletion of these updates (with no justification or comment) means that
they will have to be re-asserted into the CVS (Pete's veto remains
invalid).
The necessity for the .xtype and .xprofile comes down to the fact that
the blockinfo is a primitate descriptor relative to the Type DTD.
Merlin can use much more information than that available in blockinfo
and in some cases requires additional information in order to work
around componets that include BlockContext references. In these
situations, Merlin needs a type declaration that contains the statement
of the contextualization phase criteria. In the profile.xml, a bundled
defintion is provided that Merlin can use to automatically create the
BlockInfo instance based on profile directives.
>
>
>> Some questions come out of this:
>>
>> 1. Are Cornerstone components intended to be exclusive to
>> Phoenix or are they intended to be re-usable across
>> Avalon containers?
>
>
> Multiple containers is what I have been telling people for years.
> Does each container have its own .x* files? Refer my point above.
> The conflict area is the xml manifests the developer (rather than the
> assembler) makes.
Multiple contains can either:
a) use a common DTD (the desitable scenario)
b) use seperate DTDs (a workable scenario assuming collaboration)
c) use seperate extensions (necessary to achieve a working solution
relative the the current players) but breaks oppotunity for re-use
of components across containers.
The situation isn't that difficult to understand:
1. a container reads a .xinfo into a configuration instance
(and can restrict itself to specific DTDs)
2. a container implementation checks the top level element to see
if it is something it can suport
3. a continer generates its own internal model based on the
configration as the source
>
>> 2. Should Cornerstone componets implement Component
>> interface or not (in particular taking into account there
>> existing usage with ComponentManager based systems in the
>> field)?
>
>
> I'd hope we can find a way where Component is finally shoved into
> obscurity. Part of this involves me publishing a new JAMES Maillet
> API (born from my work on Jesktop and EOB).
>
>> 3. Should resolution of the DTD question be solved first
>> (taking into account recent updates to the Type DTD to
>> fully support the Phoenix blockinfo requirements)?
>
>
> One would hope there is a healthy discussion that leads us to a DTD
> resolution, and then something that can be committed.
Me too!
The Type DTD has evolved such that is COMLETELY address all of the
requirements expressed by the Fortress, Merlin and Phoenix usage
scanarios. The same canot be said of any other meta-info DTD.
>
>> 3. Recent modifications were made to the way Phoenix creates a
>> BlockInfo class. These modifications simply checked the root
>> element type and build the Phoenix BlockInfo accordingly.
>> These changes have been -1'ed by Pete without justification.
>
>
> Perhaps we could seek a reason for this.
So far Pete has chosen to ignore this question.
I would really like to hear his reational as well - however, I suspect
he simply will not answer you request.
>
>> My only rationale explination I can see is that Pete is
>> simply attempting to oppose anything that would facilitate
>> component reuse outside of Phoenix. I believe that this an
>> attitude will simply result in the death of Phoenix. I don't
>> see that as too great a problem as the Merlin/Fortress work
>> is in many areas significantly ahead of Phoenix. However,
>> Pete's continued opposition to an open-container world is
>> damaging overall Avalon credibility and remains a very real
>> concern.
>
>
> My hope is that Peter is only making sure that the component contract
> changes are well thought out and carefully planned. I think Peter has
> no formal objections to other containers that can mount either a)
> existing blocks or b) entire SAR files. With respect to a) I am
> guessing Peter believes the contract with the .xinfo files (and
> .mxinfo for mgmt) is good enough. I am guessing that Peter has no
> opposition to those other containers not using assembly.xml and
> config.xml. I'm putting words in Peter's mouth here (my
> second-guessing gland quite often goes into overdrive), so perhaps
> Peter can clarify where the differences for alternate container should
> be apparent.
Pete has replied to this - however - he failed to address the question
you raised - "clarification where the differences for alternate
containers should be apparent". He has addressed his own agenda -
containerkit.
Let's not fall into the false impression that this repsent the community.
>
>
>>> 3) consider what is best for individual sub-projects of Avalon
>>> constantly.
>>
>>
>>
>>
>> I recently posted an email to the James list in feedback to critisism
>> about Avalon. That email request more specifics - things that could
>> be dealt with. I received a lot of off-list replies. Within these
>> the most significant issue was Avalon version management. I was a
>> little suprised until I realized that everyone out-there looks at
>> "Avalon" as:
>>
>> * Framework
>> * Excalibur everything
>> * Cornerstone components
>> * Phoenix
>> * and all of the Avalon Apps content
>
>
> It has taken me some time to publish the fact that there are
> sub-projects to Avalon. Some of the JAMESers had a principal
> objection to Phoenix but expressed it as "I hate Avalon". I felt my
> suggestion to think of things differntly would help our cause (Avalon
> is a project not a product).
With all of the "flack" email I received from James people - I'm
progressively moving towards thier point of view. Looking at Avalon
"the brand" there are big holes in out story due to our artifical
fragmentation. It doesn't matter is James people are right or wrong -
it matters that they represent an import part of our user community -
just as Cocoon does. These user's matter - there opions are the reality
of "what is Avalon".
>
>> When something is a component inside cornerstone breaks, the message
>> "Avalon is broken again". When Phoenix doesn't supply the row column
>> and source of a configuration exception - its "Avalon doesn't do
>> this...". Bottom line - they are right - looking at the Avalon
>> big-picture there are lots of inconsitencies. Lets's not focus on
>> what best for avalon sub-projects, but instead, lets focus on what's
>> best for the Avalon user community. Let's eliminate the artificial
>> segregation we have between projects and get on with the job of
>> delivering and properly maintaining great component solutions.
>>
>>>
>>> 4) define whether we should be voting in advance or in arrears
>>> of significant contributions to common projects (nobody gives
>>> stuff what I do to apps/db/** right?)
>>
>>
>>
>>
>> I think comes down to one of the issues raised by the James people.
>> Aside for the 4 CVS division (which is a real source of confusion),
>> we don't have a good framework fo seperating early development from
>> released projects.
>>
>> One suggestion from a James committer was to follow the commons
>> appraoch:
>>
>> * Merge Avalon Framework / Excalibur / Phoenix into a single CVS
>
>
> We un merged some time ago.
I know,.
In hindsight - was it a good move?
I don't think so. It's led to fragmentation instead of dealing with
issues - ECM land verus Phoenix land, etc. Lack of relase managemnt,
lack of control, brand corruption.
>
>> * composition of the cvs based on
>> - released projects
>> - Framework
>> - Excalibur released utilities
>> - Phoenix
>> - Individual cornerstone released components
>
>
> +1 to Cornerstone splitup.
>
>> - a scratchpad project (trial/experimentation/pre-release)
>> - Excalibur pre-release utilities
>> - Merlin
>> - Fortress
>> - Some of the cornerstone components
>> - a playground project
>> - Tweety
>> - demonstrations
>
>
> My feeling is that if our documentation is good enough (" This is
> Alpha quality and not intended for production deployment "), then it
> is good enough. WRT Commons-Scratchpad. You'll remember I ran from
> there with AltRMI.
I remember comming to Avalon in the beginning and wondering what the
status of everything was. The documentation does not detail this. I've
emailed Pete and Berin and other at different times - asking what's the
status of this, what's the status of that. I've implemeted my own
solutions in some cases simply because I didn't have a good idea of what
the status was. The overarching structure and organization at the
Avalon top-level is missing.
>
>> Escalation of a scratchpad project to an Avalon project should be
>> something properly managed and the notion of ownership should move
>> from the "initiator" to the "community". This would encourage
>> segregation between release verus development projects. For example I
>> would not be able to able to add content to Phoneix that depended on
>> a scratch project. User's would see one site - a consitent set of
>> documentation and with release status (Alpha, Beta, Final, etc.).
>> Properly packaged components and utilities with version management
>> not just on the framework, but on all of the released Avalon content.
>
>
> That is a good point. It would mean we lose some external comps, like
> MX4J which despite a 1.1 label is perhaps nearer a 0.99 release.
Yep.
>>> 5) aim to be all lovey-dovey from a point of time none to distant
>>> in the future.
>>
>>
>>
>>
>> I skip on this one - lovey-dovey isn't going to solve the problem.
>> Some good, detailed explinations from Pete would go a long way
>> towards resolving things. Cheers, Steve.
>
>
> Actually, I manages the perceptions of our user community. This is
> not a closed list. Every insulting, rude, sarcastic and derisory
> message on this list hampers the adpotion of any aspect of the Avalon
> project, and probably puts ammo in the guns of those actively dissing
> Avalon and its central patterns.
The notion of a community is central to the point you have raised. Go
back over the archives and look at the sustained opposition to community
based development by one individual. Solve that problem and you will
enable community development. Don't be misslead into thinking that
pretending that everything is ok will make everyting ok - it's not. What
is the cause of the type of messages you mentioned? It's the cause that
needs to be address - not the side-effects.
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 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>
DTD compat -- red herring?
Posted by Peter Royal <pr...@apache.org>.
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: All committers please read -> Bad Karma is happening.
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
>> [...] The API is not defined by the DTD. Please - let's focus on
>> one layer at a time and keep the discussion cleanly focussed on the
>> issues at hand.
>>
>> The objective is one DTD that address all of the requirements - not
>> just yours.
>
>
> With respect, if the DTD allows elements and attributes that Phoenix
> cannot use, then there is a possibility that the block developer might
> avail of those features and thus, yes it is part of the API.
> - Paul
Correction.
If you go back over the Phoenix sources (CVS history) - you will find
examples of code that enables the creation of a BlockInfo class for
multiple DTD. The same thing exists inside Merlin - Merlin can read in a
blockinfo, containerkit or type DTD and generate its own internal Type
meta-info instance. The DTD is simply an external form - it does not
define the API - it defines data elements.
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.
Merlin and Fortress componets use extensions. These extensions need to
be declare either programatically or through a .xinfo descriptor.
* should a componet be defined relative to a specific container ?
- NO
* should a component be defined relative to a common componet defintion
- YES
* should that defintion support required versus optional elements
- YES
* should a container be aware of and deal with optional elements
- YES
* should the development of service and compoent management be
restricted to
a single container model such as Merlin
- NO
* should the development of service and compoent management be
restricted to
a single container model such as Phoenix
- NO
* should the development of service and compoent management be
restricted to
a single container model such as Fortress
- NO
* should the development of service and compoent management attempt
to aggregate
established and vaidated features across the set of Avalon containers
- YES
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>> so perhaps Peter can clarify where the
>>> differences for alternate container should be apparent.
>>>
>>
>>
>> No you summed it up well. All the containers I will work on will have
>> a common model. Currently this is evolving but getting closer to set
>> and is basically defined in containerkit project.
>
>
> Umm, sounds familiar - a common model defined within a scope that
> enabled YOU personally to veto anything that YOU personally don't
> like. Reality check - containerkit doesn't work for Merlin, doesn't
> work for Fortress. Do you indent to deal with this or simply discount
> the rest of us as irrelevant to you view of the world ?
With respect to Peter, the .xinfo contract was not the product of a
rushed design. Stephen, please pull back from personal attack.
>> 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.
>
Are we talking BlockInfo.java here? Or .xinfo?
> [...]
> [...] The API is not defined by the DTD. Please - let's focus on one
> layer at a time and keep the discussion cleanly focussed on the issues
> at hand.
>
> The objective is one DTD that address all of the requirements - not
> just yours.
With respect, if the DTD allows elements and attributes that Phoenix
cannot use, then there is a possibility that the block developer might
avail of those features and thus, yes it is part of the API.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>On Sun, 18 Aug 2002 18:32, Paul Hammant wrote:
>
>
>>> My only rationale explination I can see is that Pete is
>>> simply attempting to oppose anything that would facilitate
>>> component reuse outside of Phoenix. I believe that this an
>>> attitude will simply result in the death of Phoenix. I don't
>>> see that as too great a problem as the Merlin/Fortress work
>>> is in many areas significantly ahead of Phoenix. However,
>>> Pete's continued opposition to an open-container world is
>>> damaging overall Avalon credibility and remains a very real
>>> concern.
>>>
>>>
>>My hope is that Peter is only making sure that the component contract
>>changes are well thought out and carefully planned. I think Peter has
>>no formal objections to other containers that can mount either a)
>>existing blocks or b) entire SAR files. With respect to a) I am
>>guessing Peter believes the contract with the .xinfo files (and .mxinfo
>>for mgmt) is good enough. I am guessing that Peter has no opposition to
>>those other containers not using assembly.xml and config.xml. I'm
>>putting words in Peter's mouth here (my second-guessing gland quite
>>often goes into overdrive), so perhaps Peter can clarify where the
>>differences for alternate container should be apparent.
>>
>>
>
>No you summed it up well. All the containers I will work on will have a common
>model. Currently this is evolving but getting closer to set and is basically
>defined in containerkit project.
>
Umm, sounds familiar - a common model defined within a scope that
enabled YOU personally to veto anything that YOU personally don't like.
Reality check - containerkit doesn't work for Merlin, doesn't work for
Fortress. Do you indent to deal with this or simply discount the rest
of us as irrelevant to you view of the world ?
>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.
>
And ignoring the more comprehensive and validated Type DTD.
Come on - lets get down to real tangible content here - your objections
to the Type DTD are that is provides support for something you have been
unable to sucessfully implement with the context of Phoenix.
Independetly of the fact that two other containers have successfully
addressed and resolved this issue - you continue to claim that this
isn't a good thing but neglect to explain why. You still havn't
addressed why Phoenix cannot use a common DTD that includes defintions
that Phoenix currently does not support.
>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.
>
As opposed to working with the commuity in developing a comprehensive
solution.
You and I both know that you can implement the entire containerkit
meta-info model using the Type DTD. You have not addressed the question
of the common DTD - istead, you have chosen (repeatedly) to respond on
the grounds of a meta-info API conflict which is misleading and
inacurate. An API defines a info model and that model can be created
for different mechanisms. The API is not defined by the DTD. Please -
let's focus on one layer at a time and keep the discussion cleanly
focussed on the issues at hand.
The objective is one DTD that address all of the requirements - not
just yours.
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: All committers please read -> Bad Karma is happening.
Posted by Peter Donald <pe...@apache.org>.
On Sun, 18 Aug 2002 18:32, Paul Hammant wrote:
> > My only rationale explination I can see is that Pete is
> > simply attempting to oppose anything that would facilitate
> > component reuse outside of Phoenix. I believe that this an
> > attitude will simply result in the death of Phoenix. I don't
> > see that as too great a problem as the Merlin/Fortress work
> > is in many areas significantly ahead of Phoenix. However,
> > Pete's continued opposition to an open-container world is
> > damaging overall Avalon credibility and remains a very real
> > concern.
>
> My hope is that Peter is only making sure that the component contract
> changes are well thought out and carefully planned. I think Peter has
> no formal objections to other containers that can mount either a)
> existing blocks or b) entire SAR files. With respect to a) I am
> guessing Peter believes the contract with the .xinfo files (and .mxinfo
> for mgmt) is good enough. I am guessing that Peter has no opposition to
> those other containers not using assembly.xml and config.xml. I'm
> putting words in Peter's mouth here (my second-guessing gland quite
> often goes into overdrive), so perhaps Peter can clarify where the
> differences for alternate container should be apparent.
No you summed it up well. All the containers I will work on will have a common
model. 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.
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>> 1) calm things down.
>
>
>
> +1
>
> The biggest contributing factory will be some rational discussion
> about changes.
>
>>
>>
>> 2) arbitrate between opposing factions
>
>
>
> Here is a summary of my view of the issues:
>
> 1. Cornerstone
>
> Conerstone is an Avalon poject that includes several
> utility components. Several of these components are
> used within the scope of external projects in the
> context of service and component managers. While
> attempting to use the cornerstone jar from the CVS
> with James, I encounter class cast exception when
> a ComponentManager was attempring to return a
> cornerstone component as a Component instance.
>
> I corrected this issue by reincluding the Component
> interface. Pete has -1'ed the revision without
> supplying an explination.
> Cornerstone remains broken.
Well that is probably nearer my fault. I upgraded in Phoenix inside
JAMES CVS. I should have put back the previous cornerstone.jar that
they were using as it was Component using. We have known for months
that JAMES has a problem with the removal of Component. The problem is
one of backwards-compatability given that maillets are handed a Context
which has getComponentManager() method (v eryun IoC). I'm taking this
on the chin not Peter. The whole of the Avalon community mulled how to
get rid of Component months ago and I, as an un-official JAMES laison,
failed to reslove the remaining issue.
> 2. Cornerstone components have for a long time been
> considered as a set of Phoenix blocks. With the
> introduction of Merlin, we have the potential for
> Cornerstone blocks to be used not only within the
> scope of Phoenix, but across any other container that
> supports the Avalon Meta Model DTD.
> To enable containers other than Phoenix to use the
> Cornerstone components, I added a set of resources
> (equivalent to the .xinfo named .xtype to avoid
> conflict with Phoenix).
> A modification to the build file was made to include
> the resources into the jar file. This modification
> was -1'ed by Pete on the grounds of introducing
> meta-info dependecies and Pete's desire to reserve
> ".xprofile" for Phoenix - both arguments have addressed,
> showing (a) no implied meta-info - its a DTD question,
> and (b) a description of how one .something file can be
> used with different DTD. No response, objection or
> disagreement was raised by Pete to any of these
> messages.
It appears that the need for .xprofile and .xtype is the issue. Laymen,
such as myself migh ask 'why is not .xinfo not sufficient'?
> Some questions come out of this:
>
> 1. Are Cornerstone components intended to be exclusive to
> Phoenix or are they intended to be re-usable across
> Avalon containers?
Multiple containers is what I have been telling people for years. Does
each container have its own .x* files? Refer my point above. The
conflict area is the xml manifests the developer (rather than the
assembler) makes.
> 2. Should Cornerstone componets implement Component
> interface or not (in particular taking into account there
> existing usage with ComponentManager based systems in the
> field)?
I'd hope we can find a way where Component is finally shoved into
obscurity. Part of this involves me publishing a new JAMES Maillet API
(born from my work on Jesktop and EOB).
> 3. Should resolution of the DTD question be solved first
> (taking into account recent updates to the Type DTD to
> fully support the Phoenix blockinfo requirements)?
One would hope there is a healthy discussion that leads us to a DTD
resolution, and then something that can be committed.
> 3. Recent modifications were made to the way Phoenix creates a
> BlockInfo class. These modifications simply checked the root
> element type and build the Phoenix BlockInfo accordingly.
> These changes have been -1'ed by Pete without justification.
Perhaps we could seek a reason for this.
> My only rationale explination I can see is that Pete is
> simply attempting to oppose anything that would facilitate
> component reuse outside of Phoenix. I believe that this an
> attitude will simply result in the death of Phoenix. I don't
> see that as too great a problem as the Merlin/Fortress work
> is in many areas significantly ahead of Phoenix. However,
> Pete's continued opposition to an open-container world is
> damaging overall Avalon credibility and remains a very real
> concern.
My hope is that Peter is only making sure that the component contract
changes are well thought out and carefully planned. I think Peter has
no formal objections to other containers that can mount either a)
existing blocks or b) entire SAR files. With respect to a) I am
guessing Peter believes the contract with the .xinfo files (and .mxinfo
for mgmt) is good enough. I am guessing that Peter has no opposition to
those other containers not using assembly.xml and config.xml. I'm
putting words in Peter's mouth here (my second-guessing gland quite
often goes into overdrive), so perhaps Peter can clarify where the
differences for alternate container should be apparent.
>> 3) consider what is best for individual sub-projects of Avalon
>> constantly.
>
>
>
> I recently posted an email to the James list in feedback to critisism
> about Avalon. That email request more specifics - things that could
> be dealt with. I received a lot of off-list replies. Within these
> the most significant issue was Avalon version management. I was a
> little suprised until I realized that everyone out-there looks at
> "Avalon" as:
>
> * Framework
> * Excalibur everything
> * Cornerstone components
> * Phoenix
> * and all of the Avalon Apps content
It has taken me some time to publish the fact that there are
sub-projects to Avalon. Some of the JAMESers had a principal objection
to Phoenix but expressed it as "I hate Avalon". I felt my suggestion to
think of things differntly would help our cause (Avalon is a project not
a product).
> When something is a component inside cornerstone breaks, the message
> "Avalon is broken again". When Phoenix doesn't supply the row column
> and source of a configuration exception - its "Avalon doesn't do
> this...". Bottom line - they are right - looking at the Avalon
> big-picture there are lots of inconsitencies. Lets's not focus on
> what best for avalon sub-projects, but instead, lets focus on what's
> best for the Avalon user community. Let's eliminate the artificial
> segregation we have between projects and get on with the job of
> delivering and properly maintaining great component solutions.
>
>>
>> 4) define whether we should be voting in advance or in arrears
>> of significant contributions to common projects (nobody gives
>> stuff what I do to apps/db/** right?)
>
>
>
> I think comes down to one of the issues raised by the James people.
> Aside for the 4 CVS division (which is a real source of confusion), we
> don't have a good framework fo seperating early development from
> released projects.
>
> One suggestion from a James committer was to follow the commons appraoch:
>
> * Merge Avalon Framework / Excalibur / Phoenix into a single CVS
We un merged some time ago.
> * composition of the cvs based on
> - released projects
> - Framework
> - Excalibur released utilities
> - Phoenix
> - Individual cornerstone released components
+1 to Cornerstone splitup.
> - a scratchpad project (trial/experimentation/pre-release)
> - Excalibur pre-release utilities
> - Merlin
> - Fortress
> - Some of the cornerstone components
> - a playground project
> - Tweety
> - demonstrations
My feeling is that if our documentation is good enough (" This is Alpha
quality and not intended for production deployment "), then it is good
enough. WRT Commons-Scratchpad. You'll remember I ran from there with
AltRMI.
> Escalation of a scratchpad project to an Avalon project should be
> something properly managed and the notion of ownership should move
> from the "initiator" to the "community". This would encourage
> segregation between release verus development projects. For example I
> would not be able to able to add content to Phoneix that depended on a
> scratch project. User's would see one site - a consitent set of
> documentation and with release status (Alpha, Beta, Final, etc.).
> Properly packaged components and utilities with version management not
> just on the framework, but on all of the released Avalon content.
That is a good point. It would mean we lose some external comps, like
MX4J which despite a 1.1 label is perhaps nearer a 0.99 release.
>> 5) aim to be all lovey-dovey from a point of time none to distant in
>> the future.
>
>
>
> I skip on this one - lovey-dovey isn't going to solve the problem.
> Some good, detailed explinations from Pete would go a long way towards
> resolving things.
> Cheers, Steve.
Actually, I manages the perceptions of our user community. This is not
a closed list. Every insulting, rude, sarcastic and derisory message on
this list hampers the adpotion of any aspect of the Avalon project, and
probably puts ammo in the guns of those actively dissing Avalon and its
central patterns.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: All committers please read -> Bad Karma is happening.
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Folks,
>
> There appears to be a little discord present in the avalon-dev list,
> and hence the Avalon Developer community. I'd like to propose that we
> seek to achieve multiple things ...
>
> 1) calm things down.
+1
The biggest contributing factory will be some rational discussion about
changes.
>
>
> 2) arbitrate between opposing factions
Here is a summary of my view of the issues:
1. Cornerstone
Conerstone is an Avalon poject that includes several
utility components. Several of these components are
used within the scope of external projects in the
context of service and component managers. While
attempting to use the cornerstone jar from the CVS
with James, I encounter class cast exception when
a ComponentManager was attempring to return a
cornerstone component as a Component instance.
I corrected this issue by reincluding the Component
interface. Pete has -1'ed the revision without
supplying an explination.
Cornerstone remains broken.
2. Cornerstone components have for a long time been
considered as a set of Phoenix blocks. With the
introduction of Merlin, we have the potential for
Cornerstone blocks to be used not only within the
scope of Phoenix, but across any other container that
supports the Avalon Meta Model DTD.
To enable containers other than Phoenix to use the
Cornerstone components, I added a set of resources
(equivalent to the .xinfo named .xtype to avoid
conflict with Phoenix).
A modification to the build file was made to include
the resources into the jar file. This modification
was -1'ed by Pete on the grounds of introducing
meta-info dependecies and Pete's desire to reserve
".xprofile" for Phoenix - both arguments have addressed,
showing (a) no implied meta-info - its a DTD question,
and (b) a description of how one .something file can be
used with different DTD. No response, objection or
disagreement was raised by Pete to any of these
messages.
Some questions come out of this:
1. Are Cornerstone components intended to be exclusive to
Phoenix or are they intended to be re-usable across
Avalon containers?
2. Should Cornerstone componets implement Component
interface or not (in particular taking into account there
existing usage with ComponentManager based systems in the
field)?
3. Should resolution of the DTD question be solved first
(taking into account recent updates to the Type DTD to
fully support the Phoenix blockinfo requirements)?
3. Recent modifications were made to the way Phoenix creates a
BlockInfo class. These modifications simply checked the root
element type and build the Phoenix BlockInfo accordingly.
These changes have been -1'ed by Pete without justification.
My only rationale explination I can see is that Pete is
simply attempting to oppose anything that would facilitate
component reuse outside of Phoenix. I believe that this an
attitude will simply result in the death of Phoenix. I don't
see that as too great a problem as the Merlin/Fortress work
is in many areas significantly ahead of Phoenix. However,
Pete's continued opposition to an open-container world is
damaging overall Avalon credibility and remains a very real
concern.
>
> 3) consider what is best for individual sub-projects of Avalon
> constantly.
I recently posted an email to the James list in feedback to critisism
about Avalon. That email request more specifics - things that could be
dealt with. I received a lot of off-list replies. Within these the
most significant issue was Avalon version management. I was a little
suprised until I realized that everyone out-there looks at "Avalon" as:
* Framework
* Excalibur everything
* Cornerstone components
* Phoenix
* and all of the Avalon Apps content
When something is a component inside cornerstone breaks, the message
"Avalon is broken again". When Phoenix doesn't supply the row column
and source of a configuration exception - its "Avalon doesn't do
this...". Bottom line - they are right - looking at the Avalon
big-picture there are lots of inconsitencies. Lets's not focus on what
best for avalon sub-projects, but instead, lets focus on what's best for
the Avalon user community. Let's eliminate the artificial segregation
we have between projects and get on with the job of delivering and
properly maintaining great component solutions.
>
> 4) define whether we should be voting in advance or in arrears
> of significant contributions to common projects (nobody gives
> stuff what I do to apps/db/** right?)
I think comes down to one of the issues raised by the James people.
Aside for the 4 CVS division (which is a real source of confusion), we
don't have a good framework fo seperating early development from
released projects.
One suggestion from a James committer was to follow the commons appraoch:
* Merge Avalon Framework / Excalibur / Phoenix into a single CVS
* composition of the cvs based on
- released projects
- Framework
- Excalibur released utilities
- Phoenix
- Individual cornerstone released components
- a scratchpad project (trial/experimentation/pre-release)
- Excalibur pre-release utilities
- Merlin
- Fortress
- Some of the cornerstone components
- a playground project
- Tweety
- demonstrations
Escalation of a scratchpad project to an Avalon project should be
something properly managed and the notion of ownership should move from
the "initiator" to the "community". This would encourage segregation
between release verus development projects. For example I would not be
able to able to add content to Phoneix that depended on a scratch
project. User's would see one site - a consitent set of documentation
and with release status (Alpha, Beta, Final, etc.). Properly packaged
components and utilities with version management not just on the
framework, but on all of the released Avalon content.
>
> 5) aim to be all lovey-dovey from a point of time none to distant in
> the future.
I skip on this one - lovey-dovey isn't going to solve the problem.
Some good, detailed explinations from Pete would go a long way towards
resolving things.
Cheers, Steve.
>
> I'd like to vote +1 for each of the above to kick things off.
>
> I'd also like to add something from a personal agenda:
>
> 6) each and every committer should consider xdocs source to be
> temporarily
> more important than java source and got on with some additions.
> Even if
> compiling it is strangely beyond them, I will consent to fix
> compilation
> issues
>
> +1 for that too.
>
> Non committers could voice their solidarity to the process by with a
> single comment persuading us go with peacemaking if they believe it is
> best.
>
> Regards,
>
> - 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>