You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/11/22 13:44:42 UTC
[Proposal/Attn:Mr.Donald&Mr.Hammant] Phoenix no longer reference container
All,
I have been following the discussions about a single container
or a set of containers with some interest. However, reading
Peter Donald's emails I believe that the project is doomed
to failure due to its structure.
I believe that the need for non-concensus-based development
of Phoenix (that is, not concensus across all of Avalon) is
(and please correct me if I'm wrong here, Peter) that your user
base demand certain development / new features. You state as
much when you said that the comments were "easier to sell to
the boss", etc.
Now, this could be done via concensus across Avalon, which is
by necessity a slower process than concensus across Phoenix
due to Phoenix being a subset of Avalon. Or, you could solve it
with a container-specific extension that would then be promoted
to "official" API.
The problem:
1) If you choose concensus, you are slowing down development
of Phoenix, meaning that your users suffer. Concensus may be
fine and all, but it sure doesn't pay any paychecks.
2) If you choose container-specific extensions you end up with:
"a reference container with container specific extensions"
which sounds like an oxymoron to me.
I therefore propose the following: Phoenix drops the "Avalon
reference container" part of itself and joins Merlin, Fortress
and the others as just another container.
Advantages:
+ You can drive development much faster.
+ Less coupling between Phoenix and framework.
+ Forces us to really consider the contracts in framework.
Disadvantages:
- You lose some advertising points.
Invariant:
0 Code sharing, three-tiered container hierarchy and all
is still perfectly possible and a separate issue.
0 Phoenix stays as-is, just not being the reference
container.
Part 2: What is a reference container?
With Phoenix as a reference container we ended up with a
maxmimalist container that saw wide commercial deployment.
For reasons above (*direct* exposure to user requirements),
Phoenix evloved much faster than framework, meaning that
it is:
+ A reference container for framework
+ A set of container-specific extensions
+ A testbed for expermental code.
This is too much.
In my opinion, a reference container is what you go look at
to get clarification of a contract in framework. Not something
you'd deploy commercially.
I would propose that the reference container should be very
simple, and only evolve as framework evolves. The experimental
code, the user feedback, should be at the Phoenix/Fortress/Merlin
level. Then, once there are features in those containers that
have withstood the tests of real-life deployment, should the
features be merged back into framework and the reference
container.
This allows all sorts of experiments at the Phoenix/Fortress/Merlin
level, even a merge of everything into Merlin's Phortress. But it
does isolate framework from having to adapt rapidly, meaning
that those contracts will be very stable.
Because we do need code that can change quickly and adapt quickly,
even though we may not be sure whether the change is "the right
thing". And concensus across all of Avalon may not be the right
method for it. However, changes to a reference container, which
is equal to changes to framework, does require concensus (stability
is paramount).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Phoenix no longer reference container
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>I therefore propose the following: Phoenix drops the "Avalon
>reference container" part of itself and joins Merlin, Fortress
>and the others as just another container.
>
>
+1
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: Phoenix no longer reference container
Posted by Peter Donald <pe...@apache.org>.
On Fri, 22 Nov 2002 23:44, Leo Sutic wrote:
> I therefore propose the following: Phoenix drops the "Avalon
> reference container" part of itself and joins Merlin, Fortress
> and the others as just another container.
Eh? Phoenix has never been a "reference container" and I have specifically
gone out of my way to discourage such terminology (Go back to discussions wrt
to icons where I asked Leo to remove the term). The closer we have had to a
"reference implementation" is ECM and that is going the way of the dodo.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Phoenix no longer reference container
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 23 Nov 2002 23:09, Paul Hammant wrote:
> [To All]: All people embroiled in these discussions, must try to go back a
> year or two and read out threads on K/HC/CAPI (or was it K/CAPI/HC, darn,
> I'm muddying google's water now just talking about it).
>
> Peter, you have a summary handy?
Not really ;(
It talks about the concepts in loader docs but nothing specifically related to
K/CAPI/HC.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Phoenix no longer reference container
Posted by Paul Hammant <pa...@yahoo.com>.
Berin,
> I would be retisent to split the jars at this point because users
> *expect* everything to be in there. I am not a fan of splitting
> interface/implementation jars unless the interface jar is used for
> compilation purposes and not distribution purposes.
For application servers (Phoenix, EOB etc), implementation hiding is *very* important. This is
achieved with two things :
1) Use of dynamic proxy
2) hiving off impl to a different (invisible to client) classloader.
[To All]: All people embroiled in these discussions, must try to go back a year or two and read
out threads on K/HC/CAPI (or was it K/CAPI/HC, darn, I'm muddying google's water now just talking
about it).
Peter, you have a summary handy?
> For instance, I see the number of jars necessary for AltRMI as too many
> for deployment. I only need the interfaces to compile, but the
> implementation is necessary for the deployment. I would much rather
> have the only the Client/Server/Common jars as opposed to Client-API,
> Client-Impl, Server-Api, Server-Impl, Common, Generator. That is
> my preference.
I agree there are alot. I think we could reasonably get it down to three.
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Phoenix no longer reference container
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Sat, 23 Nov 2002 06:59, Berin Loritsch wrote:
> > > The one benefit is for classes which have external
> dependencies (ie
> > > Logkit/Log4j etc). Splitting the jars makes it possible for
> > > us to keep
> > > LogKit/Log4j out of the base Classloader but we can still
> > > resolve them higher
> > > up in the chain where the classloaders are present.
> >
> > I can support this approach:
> >
> > 1) Core Avalon (no requirements for dependencies from any other jar
> > including LogKit/Log4J)
> >
> > 2) Add-on Jars (adding LogKit/Log4J functionality using the external
> > jar).
> >
> > But this also begs the question why have a Jar for one or
> two classes?
> > If the LogKit/Log4J compliance is done at a higher level (i.e. those
> > classes are moved into Excalibur Logger for example), then the core
> > Avalon is dependency free and still one jar.
> >
> > Is that a viable solution?
>
> For Avalon5 it sounds good (though I would put LogKit adapter
> in Logkit jar
> somewhere to reduce the lines of dependency). For now it may
> be best just to
> split the jars.
I would asume this would be for whatever is next. The only dependency
Framework has on external libraries is LogKit/Log4J/JDK1.4 logging.
I can see adding support for the logging package as a complete jar in
itself (if something more than the ConsoleLogger or NullLogger are
needed which is 90% of the time).
I would be retisent to split the jars at this point because users
*expect* everything to be in there. I am not a fan of splitting
interface/implementation jars unless the interface jar is used for
compilation purposes and not distribution purposes.
For instance, I see the number of jars necessary for AltRMI as too many
for deployment. I only need the interfaces to compile, but the
implementation is necessary for the deployment. I would much rather
have the only the Client/Server/Common jars as opposed to Client-API,
Client-Impl, Server-Api, Server-Impl, Common, Generator. That is
my preference.
I think it is just as scary to see 20 JARS that are 20-40KB each as it
is to see one JAR that is 3MB. Anyway, packaging is an issue we can
delay for the time being. Let's focus on the bigger picture items right
now.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Phoenix no longer reference container
Posted by Peter Donald <pe...@apache.org>.
On Sat, 23 Nov 2002 06:59, Berin Loritsch wrote:
> > The one benefit is for classes which have external dependencies (ie
> > Logkit/Log4j etc). Splitting the jars makes it possible for
> > us to keep
> > LogKit/Log4j out of the base Classloader but we can still
> > resolve them higher
> > up in the chain where the classloaders are present.
>
> I can support this approach:
>
> 1) Core Avalon (no requirements for dependencies from any other jar
> including LogKit/Log4J)
>
> 2) Add-on Jars (adding LogKit/Log4J functionality using the external
> jar).
>
> But this also begs the question why have a Jar for one or two classes?
> If the LogKit/Log4J compliance is done at a higher level (i.e. those
> classes are moved into Excalibur Logger for example), then the core
> Avalon is dependency free and still one jar.
>
> Is that a viable solution?
For Avalon5 it sounds good (though I would put LogKit adapter in Logkit jar
somewhere to reduce the lines of dependency). For now it may be best just to
split the jars.
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Phoenix no longer reference container
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Peter Donald [mailto:peter@apache.org]
>
> On Sat, 23 Nov 2002 00:54, Berin Loritsch wrote:
> > > From: Paul Hammant [mailto:paul_hammant@yahoo.com]
> > >
> > > On that note we previously voted on whether to split
> > > avalon-framework.jar into two* ->
> > > avalon-framework-api.jar and avalon-framework-refimpl.jar.
> > > Can someone run thru the votes and see
> > > if we got majority. It was a week ago I think. Can't do it
> > > myself as on webmail presently. Maybe
> > > it needs crisping up a little bit before enacting.
> >
> > I wasn't aware of that proposal/vote amid all the noise.
> >
> > -1 from me. There is no reason to split the framework into
> > two jars. Not only is it already small, but the default
> > implementations of the Configuration/Context/etc. are all
> > part of the interface. I can't imagine what gains can be
> > made by separating interface/implementation for the Jars.
> > What about the Parameters object? There is no separate
> > interface, although it is directly named in the Parameterizable
> > interface. It provides no real benefit that I can see.
>
> The one benefit is for classes which have external dependencies (ie
> Logkit/Log4j etc). Splitting the jars makes it possible for
> us to keep
> LogKit/Log4j out of the base Classloader but we can still
> resolve them higher
> up in the chain where the classloaders are present.
I can support this approach:
1) Core Avalon (no requirements for dependencies from any other jar
including LogKit/Log4J)
2) Add-on Jars (adding LogKit/Log4J functionality using the external
jar).
But this also begs the question why have a Jar for one or two classes?
If the LogKit/Log4J compliance is done at a higher level (i.e. those
classes are moved into Excalibur Logger for example), then the core
Avalon is dependency free and still one jar.
Is that a viable solution?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Phoenix no longer reference container
Posted by Paul Hammant <pa...@yahoo.com>.
> > > On that note we previously voted on whether to split
> > > avalon-framework.jar into two* ->
> > > avalon-framework-api.jar and avalon-framework-refimpl.jar.
> > > Can someone run thru the votes and see
> > > if we got majority. It was a week ago I think. Can't do it
> > > myself as on webmail presently. Maybe
> > > it needs crisping up a little bit before enacting.
> >
> > I wasn't aware of that proposal/vote amid all the noise.
> >
> > -1 from me. There is no reason to split the framework into
> > two jars. Not only is it already small, but the default
> > implementations of the Configuration/Context/etc. are all
> > part of the interface. I can't imagine what gains can be
> > made by separating interface/implementation for the Jars.
> > What about the Parameters object? There is no separate
> > interface, although it is directly named in the Parameterizable
> > interface. It provides no real benefit that I can see.
It's important for me on the EOB project, and many others who are just using A-F interfaces (and
associated immutable beans) in their project internals. Not everyone is going to use the A-F
implementation, it's quite a harmless change.
Imagine if Catalina used our lifecycle interfaces instead of theirs for its internals...
- Paul
(from internet cafe)
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal] Phoenix no longer reference container
Posted by Peter Donald <pe...@apache.org>.
On Sat, 23 Nov 2002 00:54, Berin Loritsch wrote:
> > From: Paul Hammant [mailto:paul_hammant@yahoo.com]
> >
> > On that note we previously voted on whether to split
> > avalon-framework.jar into two* ->
> > avalon-framework-api.jar and avalon-framework-refimpl.jar.
> > Can someone run thru the votes and see
> > if we got majority. It was a week ago I think. Can't do it
> > myself as on webmail presently. Maybe
> > it needs crisping up a little bit before enacting.
>
> I wasn't aware of that proposal/vote amid all the noise.
>
> -1 from me. There is no reason to split the framework into
> two jars. Not only is it already small, but the default
> implementations of the Configuration/Context/etc. are all
> part of the interface. I can't imagine what gains can be
> made by separating interface/implementation for the Jars.
> What about the Parameters object? There is no separate
> interface, although it is directly named in the Parameterizable
> interface. It provides no real benefit that I can see.
The one benefit is for classes which have external dependencies (ie
Logkit/Log4j etc). Splitting the jars makes it possible for us to keep
LogKit/Log4j out of the base Classloader but we can still resolve them higher
up in the chain where the classloaders are present.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Phoenix no longer reference container
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> On that note we previously voted on whether to split
> avalon-framework.jar into two* ->
> avalon-framework-api.jar and avalon-framework-refimpl.jar.
> Can someone run thru the votes and see
> if we got majority. It was a week ago I think. Can't do it
> myself as on webmail presently. Maybe
> it needs crisping up a little bit before enacting.
I wasn't aware of that proposal/vote amid all the noise.
-1 from me. There is no reason to split the framework into
two jars. Not only is it already small, but the default
implementations of the Configuration/Context/etc. are all
part of the interface. I can't imagine what gains can be
made by separating interface/implementation for the Jars.
What about the Parameters object? There is no separate
interface, although it is directly named in the Parameterizable
interface. It provides no real benefit that I can see.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Phoenix no longer reference container
Posted by Paul Hammant <pa...@yahoo.com>.
> > 1) I'd like my name kept out of subject lines please.
>
> OK, done.
:-)
> > > ... Then, once there are features in those containers that have
> > > withstood the tests of real-life deployment, should the features be
> > > merged back into framework and the reference container.
> >
> > I disagree. We should keep the ref very light. I buy the idea
> > of "not intended for real deployments".
>
> What I mean is that if the features result in additional
> framework interfaces, there should be a reference implementation
> for them.
>
> This reference impl need not be heavy. (Consider
> DefaultComponentManager).
Yup. That's just one part of the ref impl..... or at least what should be the complete mainable()
ref impl.
On that note we previously voted on whether to split avalon-framework.jar into two* ->
avalon-framework-api.jar and avalon-framework-refimpl.jar. Can someone run thru the votes and see
if we got majority. It was a week ago I think. Can't do it myself as on webmail presently. Maybe
it needs crisping up a little bit before enacting.
* plus the current fat jar for back-compat.
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] Phoenix no longer reference container
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Paul Hammant [mailto:paul_hammant@yahoo.com]
>
> 1) I'd like my name kept out of subject lines please.
OK, done.
> > ... Then, once there are features in those containers that have
> > withstood the tests of real-life deployment, should the features be
> > merged back into framework and the reference container.
>
> I disagree. We should keep the ref very light. I buy the idea
> of "not intended for real deployments".
What I mean is that if the features result in additional
framework interfaces, there should be a reference implementation
for them.
This reference impl need not be heavy. (Consider
DefaultComponentManager).
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Proposal/Attn:Mr.Donald&Mr.Hammant] Phoenix no longer reference container
Posted by Paul Hammant <pa...@yahoo.com>.
1) I'd like my name kept out of subject lines please.
> I therefore propose the following: Phoenix drops the "Avalon
> reference container" part of itself and joins Merlin, Fortress
> and the others as just another container.
+1
It is one container in a multi-container world.
> In my opinion, a reference container is what you go look at
> to get clarification of a contract in framework. Not something
> you'd deploy commercially.
My opinion too. Tweety is closer. I'll say again that it should be part of
jakarta-avalon-framework CVS.
> ... Then, once there are features in those containers that
> have withstood the tests of real-life deployment, should the
> features be merged back into framework and the reference
> container.
I disagree. We should keep the ref very light. I buy the idea of "not intended for real
deployments".
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>