You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/11/22 20:41:23 UTC
reduction ad unum
My sarcasm hasn't helped some people on this list to understand what I
believe are his mistakes. I'll drop it. I move to 'let me humbly suggest
you' mode.
Avalon has a dual face: great technical ideas, very nervous community.
Some here imply that the first might be a consequence of the second. I
disagree. Following darwinistic principles, if the mutation rate is too
high, this leads to estinction.
Why is the community 'nervous'?
I think because it values technical excellence more than community
stability.
This leads to continuous "I'll do my own way" approach. the ASF has
experienced the amount of social energy required to deal with internal
forks (see Tomcat 3.x vs Tomcat 4.x) in projects where this is not
common practice.
Avalon seems to have internal forking methodology as a 'built-in'
practice for dealing with social friction.
This is a potentially explosive situation if these concepts are injected
into other communities. The ASF board acted as consequence.
- o -
Now, what can we do to solve this?
There is only one way: stop the 'route around consensus by forking'
attitude that this project is based on.
Does this mean that we must throw away Phoenix and all the great work
that people have done so far?
read my lips: N O !
Does it mean that the ASF wants to kick Peter out?
N O ! but he has to agree on the social practices that Apache values if
he wants to be part (and legally protected!) by this foundation.
Does it mean that somebody from above (board, PMC, members) will impose
a technical vision on this community? (such as a single ubercontainer)
No!
Does it mean that simply by saying so friction will go away?
No, I'm aware of this, but a number of people that have a proven record
of appreciation around consensus-based development practices will help
this community to polish its social practices but without imposition,
just with suggestions, like I'm doing now.
Berin, Paul, others, no reason to freak out: from a technical point of
view, the community will decide how things work and how things are going.
I just voted -1 on moving Phoenix out and I just proposed the community
to think about the social value of *converging* toward a single layered
container, instead of multiple ones.
And I acted as an invividual, with just my avalon committer hat on (a
hat that I earned thru direct and explicit re-election, I remind you all)
So, my title 'reduction ad unum' doesn't have any technical concepts,
but just social: let's go back in having *one* avalon development
community, let's put all containers on the same level inside this
community, and let's start convergence from there.
What does it mean technically? I don't really care, as long as it's the
entire community and not single individuals that decide.
I like Berin's proposal of layered containers:
- reference implementation
- embeddable
- standalone
and I would love if they shared code directly rather than having
different implementations of the same interfaces.
So, let's start from here: is anybody against this?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Stefano Mazzocchi wrote:
> Ah, BTW, there is a typo in the title, it should read
>
> reductio ad unum
>
> just for the record so that my latin teachers don't kill me :)
>
semper ubi sub ubi
(only funny translated to english)
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by Stefano Mazzocchi <st...@apache.org>.
Ah, BTW, there is a typo in the title, it should read
reductio ad unum
just for the record so that my latin teachers don't kill me :)
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by Stephen McConnell <mc...@apache.org>.
Darrell DeBoer wrote:
>On Sun, 24 Nov 2002 00:35, Stephen McConnell wrote:
>
>
>>In every single one of the examples you have provided above, the
>>extension of context is related to the exposure of a service. Take the
>>"forwardMail" example and image we want to create a component that is
>>complete and container agnostic. What we would do is declare that the
>>component in question has a dependency on a MailForwardingService. The
>>contract says nothing about where the service comes from (could be the
>>result of assembly, could be the result of a facility supplied by a
>>custom container). The point is that using *existing* Avalon Framework
>>contracts - this sort of dependency can be expressed providing we have a
>>consistent component model. Combine this with standard context entries
>>(avalon:home, avalon:work, etc) and the whole requirement for context
>>specialization disappears - or is at least pushed out into relatively
>>closed environments where component reuse outside of a particular
>>technical domain is of no interest.
>>
>>
>
>This makes heaps of sense to me. The idea of a "MailForwardingContext" is a
>perfect example of something that doesn't really fit the concept of a
>*context*. It's really a *service* that provides the ability to forward mail.
>
>A "ShutdownRequestContext" could, likewise, be seen as a *service* which
>provides the ability to shutdown the container. The container may or may not
>provide that service to certain components.
>
>Following that, even the "DirectoryContext" (used for getBaseDirectory() etc)
>could be seen as a "FileSystemService". (I'm just suggesting this as a
>*possibility*, not necessarily *recommending* it). Imagine the possibilities
>of using a Virtual File System (see commons-sandbox-vfs), so that the
>component could be transparently be switched from Local file system, to
>WebDAV, to zipfile, to whatever.
>
>The way I see it:
>1) We need a way for a component to declare it's dependencies on services.
>2) Why should we invent another mechanism for container-specific contexts,
>where 1) would suffice.
>
>Of course, there may well be a small set of contextual information which
>should be provided as part of the Context. Maybe a FileSystemContext makes
>sense as a generic extension to Context, which almost every container would
>provide. But the point is that such examples are few, and *all* can be
>treated as services, until such a time they become so universal that they
>require special treatment.
>
>
+1
Good summary.
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: reduction ad unum
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 24 Nov 2002 09:46, Darrell DeBoer wrote:
> Of course, there may well be a small set of contextual information which
> should be provided as part of the Context. Maybe a FileSystemContext makes
> sense as a generic extension to Context, which almost every container would
> provide. But the point is that such examples are few, and *all* can be
> treated as services, until such a time they become so universal that they
> require special treatment.
It is accepted that any bit of data in the context can either be though of as
a service or some configuration data and thus available either via
ServiceManager/ComponentManager or Configuration/Parameters.
The difference is essentially that Context provides "runtime" / "contextual"
or "environmental" data. ie It essentially provides the component with
data/services that only the parent container can provide.
You could mix concerns but that makes for a more complex configuration setup
as now you have to be aware of the differences between container provided and
peer provided services and how that effects interaction with them. It also
makes the internals of the container much harder to maintain. We actually
started to do that about 2 years ago but after a few months decided to back
it out.
The end result? You have replaced container specific context with container
specific services and container specific configuration/parameters blending.
And this all becomes more complex for end user and harder for us to maintain.
--
Cheers,
Peter Donald
-----------------------------------------------------
When a stupid man is doing something he's ashamed of,
he always declares that it is his duty.
George Bernard Shaw
-----------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by Darrell DeBoer <da...@apache.org>.
On Sun, 24 Nov 2002 00:35, Stephen McConnell wrote:
> In every single one of the examples you have provided above, the
> extension of context is related to the exposure of a service. Take the
> "forwardMail" example and image we want to create a component that is
> complete and container agnostic. What we would do is declare that the
> component in question has a dependency on a MailForwardingService. The
> contract says nothing about where the service comes from (could be the
> result of assembly, could be the result of a facility supplied by a
> custom container). The point is that using *existing* Avalon Framework
> contracts - this sort of dependency can be expressed providing we have a
> consistent component model. Combine this with standard context entries
> (avalon:home, avalon:work, etc) and the whole requirement for context
> specialization disappears - or is at least pushed out into relatively
> closed environments where component reuse outside of a particular
> technical domain is of no interest.
This makes heaps of sense to me. The idea of a "MailForwardingContext" is a
perfect example of something that doesn't really fit the concept of a
*context*. It's really a *service* that provides the ability to forward mail.
A "ShutdownRequestContext" could, likewise, be seen as a *service* which
provides the ability to shutdown the container. The container may or may not
provide that service to certain components.
Following that, even the "DirectoryContext" (used for getBaseDirectory() etc)
could be seen as a "FileSystemService". (I'm just suggesting this as a
*possibility*, not necessarily *recommending* it). Imagine the possibilities
of using a Virtual File System (see commons-sandbox-vfs), so that the
component could be transparently be switched from Local file system, to
WebDAV, to zipfile, to whatever.
The way I see it:
1) We need a way for a component to declare it's dependencies on services.
2) Why should we invent another mechanism for container-specific contexts,
where 1) would suffice.
Of course, there may well be a small set of contextual information which
should be provided as part of the Context. Maybe a FileSystemContext makes
sense as a generic extension to Context, which almost every container would
provide. But the point is that such examples are few, and *all* can be
treated as services, until such a time they become so universal that they
require special treatment.
--
cheers,
Darrell DeBoer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
>>> Which one is fine?
>>>
>>> a) A-F interfaces only
>>> b) A-F interfaces + meta
>>>
>>> And for me option (a) is insufficient and the root of current
>>> container proliferation. Option (b) is crucial for completion of the
>>> component-container contract.
>>>
>>
>>
>> Signing off now from internet cafe in Amsterdam. Hmmm, it might
>> have been good to meet up with
>> Leo Simmons. I'll reply more fully in a day or so.
>>
>> The answer is interfaces only.
>
>
> That's what I was worried about.
That's what I was worried about :-)
>
>> I like the way that Leo Sutic's thread is progressing.
>>
>>
>
> Leo's approach does not negate the requirement for knowlege about
> context interface casting criteria or entry key/class criteriea. I
> potentially adds the notion of a context criteria being declared with
> multilple interface classes that it must support (which is managable),
> and lets us as a result, establish a set of standard context accessor
> interfaces and implemetaitons. Apart from that the
> container/component contract issue is still there and isn't going to
> go away.
No, actually, I think Leo's solution is just fne. Containers choose
which (core) Context derivatives they support.
>> Question : Is it possible for us to deal with the long-running
>> Context sub-interface issue
>> separately from XML meta info on components. My opinion is yes, and
>> given it is something that we
>> can resolve quite quickly, we should do so.
>>
>
> And my opinion is no.
>
> If you seperate these two, you effictively say
>
> "let's abandon the idea that a compont author can define *portable*
> context solutions"
With respect, I said nothing of the sort.
> Can you explain to me why this is a good thing?
If I understood what that (non-quote) means, I might do.
Look, we can either squeeze some context interface only solutions into
Phoenix codebase without revolutionising anything, or if they really are
tied to the uber-meta, then they only go into ubercontainer and Phoenix
sails on with BlockContext as is. We've committed to no revolution on
Phoenix CVS. Uber can take whatever fantastic collaborative Context
design it likes.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
>Stephen,
>
>
>
>>Which one is fine?
>>
>>a) A-F interfaces only
>>b) A-F interfaces + meta
>>
>>And for me option (a) is insufficient and the root of current container
>>proliferation.
>>Option (b) is crucial for completion of the component-container contract.
>>
>>
>
>Signing off now from internet cafe in Amsterdam. Hmmm, it might have been good to meet up with
>Leo Simmons. I'll reply more fully in a day or so.
>
>The answer is interfaces only.
>
That's what I was worried about.
>I like the way that Leo Sutic's thread is progressing.
>
>
Leo's approach does not negate the requirement for knowlege about
context interface casting criteria or entry key/class criteriea. I
potentially adds the notion of a context criteria being declared with
multilple interface classes that it must support (which is managable),
and lets us as a result, establish a set of standard context accessor
interfaces and implemetaitons. Apart from that the container/component
contract issue is still there and isn't going to go away.
>Question : Is it possible for us to deal with the long-running Context sub-interface issue
>separately from XML meta info on components. My opinion is yes, and given it is something that we
>can resolve quite quickly, we should do so.
>
>
And my opinion is no.
If you seperate these two, you effictively say
"let's abandon the idea that a compont author can define *portable*
context solutions"
Can you explain to me why this is a good thing?
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: reduction ad unum
Posted by Paul Hammant <pa...@yahoo.com>.
Stephen,
> Which one is fine?
>
> a) A-F interfaces only
> b) A-F interfaces + meta
>
> And for me option (a) is insufficient and the root of current container
> proliferation.
> Option (b) is crucial for completion of the component-container contract.
Signing off now from internet cafe in Amsterdam. Hmmm, it might have been good to meet up with
Leo Simmons. I'll reply more fully in a day or so.
The answer is interfaces only. I like the way that Leo Sutic's thread is progressing.
Question : Is it possible for us to deal with the long-running Context sub-interface issue
separately from XML meta info on components. My opinion is yes, and given it is something that we
can resolve quite quickly, we should do so.
This (context interfaces) is something that can be done in the current phoenix product without
breaking back-compat or introducing new XML comp-lacing etc. It is also similar to the
GenericBlockContext that was reverted. Similar in goal that is.
Regards,
-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>
Re: reduction ad unum
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
>Stephen,
>
>
>>Be warned - it's one of my longer emails.
>>
>
>We'll get you the book on Agile emails on day ;-)
>
>
>>[ A-F interfaces, interfaces only or interfaces + meta ]
>>What is does do is define the interfaces and artifacts used in the
>>interaction of a container with a component. ....
>>
>
>For me that is fine.
>
Which one is fine?
a) A-F interfaces only
b) A-F interfaces + meta
And for me option (a) is insufficient and the root of current container
proliferation.
Option (b) is crucial for completion of the component-container contract.
>A-F is used in EOB, commercial componentization projects, internals of other
>open-source projects.
>
Which is a demonstration of the value and utility of the component model
and lifecycle patterns put forward by the framework as it stands today.
However, In ever single case of concrete deployment - there must be
grounding of the Avalon framework to some concrete notion of containment
- either explicitly or implicitly because without the other side of the
contract in place (component to container), we force the framework to be
forever abstract and incomplete. This forces the requirement for
implementation of concrete semantics in different development activities
and directly contributes to the proliferation of containers and
non-interoperable solutions. This in turn inhibits reuse of code, which
in-turn inhibits the utility and propagation of Avalon.
That's why I want to see completion of the component/container contract.
:-)
>
>There is a case for saying that some of the inteface definitions for Phoenix's BlockContext need
>to be abstracted to somewhere else if Merlin is unwilling to import and provide
>phoenix-client-api.jar.
>
Underlying the BlockContext question is the more fundamental question of
interfaces derived from Context. If a meta model is in place though
which this information is supplied to a container there is not a
problem. Looking at migrating up BlockContext is effect bypassing the
real issue. The issue (with respect to context) concerns the ability to
container to establish the assumptions a component makes with respect to
context casting, and secondly, the assumptions a component makes with
respect to context entry key names and the casting of entry values.
This is simply the expression of a operational deployment criteria by a
component to a container. A container on receiving the criteria can
choose to accept or reject the component. This approach negates any
question about specific derived interfaces - it simply qualifies a
component as being A-F derived (as opposed to A-F pure), and enables a
generic container to be adaptive to these cases based on the existing
A-F semantics.
>See Later*
>
>Merlin and Phoenix do not represent the only containers that will ever be written. It is a
>fallacy to tie one component-lacing scheme to the A-F project.
>
>
I absolutely agree.
If we look at Phoenix is a specific way of describing component to
container criteria, Merlin uses the excalibur/meta package which in turn
has a more complete definition that is very similar to excalibur/info.
In both the Phoenix implementation and Merlin implementations the
"lacing" schemes are different, and yet it is possible to deploy a
Phoenix scheme within an Merlin container. That's because you can
clearly separate the component meta information for other concerns such
as assembly and so forth.
As we move forward will want to evolve meta-information and we will need
similar levels of adaptability across version of component descriptors.
This evolution needs to supported in a way that is stable and consistent
at the higher level of abstraction such as type management, etc. This
in-turn will let us evolve good container-side facilities that
developers can choose to use or ignore.
>
>>>>In another thread, Paul Hammant and Peter Goldstein were discussing
>>>>issues
>>>>over how to add more robust semantic contracts to the Frameworks.
>>>>More work
>>>>to do, but acceptable points of convergence appeared to be in the
>>>>offering.
>>>>
>>>
>>>I'm pretty sure that everybody on this list is tired of fighting and
>>>cares about Avalon enough to set aside personal issues and work toward
>>>a common goal.
>>>
>
>* Right. In my email excange on that issue that Peter Goldstein was also involved with, I was
>trying to come up with positive suggestions for past and future issue of BlockContext (and alike).
> As part of my discussion I took time to see the other person's point of view and modify my
>position, trying to propose multiple things that might be acceptable. Unfortunately that came
>across (and was stated as such) as arguing against myself.
>
>My votable position is summarisable to :
>
>1) No change to Context.class for specific containers.
>2) No GenericBlockContext type (interface/impl merging) changes to Phoenix
>3) No massive hierarchies of sub-interfaces to Context.class
>
>Currently I feel these are some very small facets of context expressable in individual interfaces
>and in A-F-API. One example is :
>
> interface ShutdownRequestingContext extends Context {
> void requestShutdown();
> }
>
>Now, it is up to the container in question as to whether they will implement that, and also to an
>extent how they implement that. Phoenix and Merlin would undoubtedly implement it. EOB would
>not.
>Phoenix might change BlockContext to extend that interface (for back-compat), but otherwise
>deprecate BlockContext. JAMES might not implement it (PeterG - forgive Avalon people for
>imagining /their/ ideal world Mailet engine).
>
>A client side usage might be :
>
> contectualize(Context context) {
> ShutdownRequestingContext src =
> (ShutdownRequestingContext) context;
> src.requestShutdown();
> }
>
>With this design, it would be compatible many containers.
>
>Where the line is drawn, is for specialized containers's specialzed context features :
>
> interface MailForwardingContext extends Context {
> void forwardMail(MailItem item, String recipient);
> }
>
>In that case, the interface stays in JAMES CVS not in A-F-API.
>
>Stephen - please meet me in the middle here, this is a significant modification for me, as you
>know it is not a loss to move you position :-)
>
Your creating a scenario that suggests the solution is along linear path.
I think the solution is on another plane.
In every single one of the examples you have provided above, the
extension of context is related to the exposure of a service. Take the
"forwardMail" example and image we want to create a component that is
complete and container agnostic. What we would do is declare that the
component in question has a dependency on a MailForwardingService. The
contract says nothing about where the service comes from (could be the
result of assembly, could be the result of a facility supplied by a
custom container). The point is that using *existing* Avalon Framework
contracts - this sort of dependency can be expressed providing we have a
consistent component model. Combine this with standard context entries
(avalon:home, avalon:work, etc) and the whole requirement for context
specialization disappears - or is at least pushed out into relatively
closed environments where component reuse outside of a particular
technical domain is of no interest.
>
>Imagine the diseased possibilities - a future uberubercontainer could be a mailet, servlet, bean,
>any component hosting server - out of the box. Hmmm ;)
>
I actually think we are in violent agreement. You want to see the
possibility for Context specialization and you consider this as an
important aspect of container usage in a broad spectrum of application
areas. I agree that that framework should enable this. However - there
is a friction between a Context derivative that has strictly convenience
operations, as opposed to a context derivative that introduced behaviour
that goes beyond the Context contract. Nothing that has been said on
this list suggests that anything more that convenience interfaces are
justified.
Consider the following:
ShutdownRequestHandler handler =
(ShutdownRequestHandler) context.get("shutdown-handler");
handler.requestShutdown();
This could be packaged under a convinience interface:
((ShutdownRequestContext)context).requestShutdown();
In either case the component needs to declare the fact that it intends
to narrow an object supplied by a container to some class. The container
is responsible for ensuring that it can service that requirement.
If the context entry is not a Avalon "standard" entry and is not a "Xxx
container" proprietary entry, then there is still the potential for
containers to resolve the value based on supplementary information
provided by an assembler as part of a container specific deployment
directives. This sort of approach enables you to do the sort of things
you want to do, without breaking the A-F contact and minimizing
container dependencies.
But isn't it just better to keep this sort of stuff as service dependencies?
Then the whole issue disappears!
:-)
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: reduction ad unum
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Paul,
> * Right. In my email excange on that issue that Peter Goldstein was
also
> involved with, I was
> trying to come up with positive suggestions for past and future issue
of
> BlockContext (and alike).
> As part of my discussion I took time to see the other person's point
of
> view and modify my
> position, trying to propose multiple things that might be acceptable.
> Unfortunately that came
> across (and was stated as such) as arguing against myself.
>
> My votable position is summarisable to :
>
> 1) No change to Context.class for specific containers.
Fine with me.
> 2) No GenericBlockContext type (interface/impl merging) changes to
Phoenix
Also fine with me.
> 3) No massive hierarchies of sub-interfaces to Context.class
Certainly fine with me. I didn't see any reason for massive
hierarchies. I still don't.
> Currently I feel these are some very small facets of context
expressable
> in individual interfaces
> and in A-F-API. One example is :
>
> interface ShutdownRequestingContext extends Context {
> void requestShutdown();
> }
>
> Now, it is up to the container in question as to whether they will
> implement that, and also to an
> extent how they implement that. Phoenix and Merlin would undoubtedly
> implement it. EOB would
> not.
> Phoenix might change BlockContext to extend that interface (for back-
> compat), but otherwise
> deprecate BlockContext. JAMES might not implement it (PeterG -
forgive
> Avalon people for
> imagining /their/ ideal world Mailet engine).
>
> A client side usage might be :
>
> contectualize(Context context) {
> ShutdownRequestingContext src =
> (ShutdownRequestingContext) context;
> src.requestShutdown();
> }
>
> With this design, it would be compatible many containers.
Yep. That's exactly what we were talking about. This is the syntactic
sugar version of the methodology we were discussing.
> Where the line is drawn, is for specialized containers's specialzed
> context features :
>
> interface MailForwardingContext extends Context {
> void forwardMail(MailItem item, String recipient);
> }
>
> In that case, the interface stays in JAMES CVS not in A-F-API.
Exactly. Commonly used interfaces are moved into the framework by a
vote of the framework committers. Container custom interfaces stay with
the container. I have no idea whether the James example would apply (I
suspect it won't), but the abstract concept works for me.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by Paul Hammant <pa...@yahoo.com>.
Stephen,
> Be warned - it's one of my longer emails.
We'll get you the book on Agile emails on day ;-)
> [ A-F interfaces, interfaces only or interfaces + meta ]
> What is does do is define the interfaces and artifacts used in the
> interaction of a container with a component. ....
For me that is fine. A-F is used in EOB, commercial componentization projects, internals of other
open-source projects.
There is a case for saying that some of the inteface definitions for Phoenix's BlockContext need
to be abstracted to somewhere else if Merlin is unwilling to import and provide
phoenix-client-api.jar. See Later*
Merlin and Phoenix do not represent the only containers that will ever be written. It is a
fallacy to tie one component-lacing scheme to the A-F project.
> >> In another thread, Paul Hammant and Peter Goldstein were discussing
> >> issues
> >> over how to add more robust semantic contracts to the Frameworks.
> >> More work
> >> to do, but acceptable points of convergence appeared to be in the
> >> offering.
> >
> >
> > I'm pretty sure that everybody on this list is tired of fighting and
> > cares about Avalon enough to set aside personal issues and work toward
> > a common goal.
* Right. In my email excange on that issue that Peter Goldstein was also involved with, I was
trying to come up with positive suggestions for past and future issue of BlockContext (and alike).
As part of my discussion I took time to see the other person's point of view and modify my
position, trying to propose multiple things that might be acceptable. Unfortunately that came
across (and was stated as such) as arguing against myself.
My votable position is summarisable to :
1) No change to Context.class for specific containers.
2) No GenericBlockContext type (interface/impl merging) changes to Phoenix
3) No massive hierarchies of sub-interfaces to Context.class
Currently I feel these are some very small facets of context expressable in individual interfaces
and in A-F-API. One example is :
interface ShutdownRequestingContext extends Context {
void requestShutdown();
}
Now, it is up to the container in question as to whether they will implement that, and also to an
extent how they implement that. Phoenix and Merlin would undoubtedly implement it. EOB would
not.
Phoenix might change BlockContext to extend that interface (for back-compat), but otherwise
deprecate BlockContext. JAMES might not implement it (PeterG - forgive Avalon people for
imagining /their/ ideal world Mailet engine).
A client side usage might be :
contectualize(Context context) {
ShutdownRequestingContext src =
(ShutdownRequestingContext) context;
src.requestShutdown();
}
With this design, it would be compatible many containers.
Where the line is drawn, is for specialized containers's specialzed context features :
interface MailForwardingContext extends Context {
void forwardMail(MailItem item, String recipient);
}
In that case, the interface stays in JAMES CVS not in A-F-API.
Stephen - please meet me in the middle here, this is a significant modification for me, as you
know it is not a loss to move you position :-)
Imagine the diseased possibilities - a future uberubercontainer could be a mailet, servlet, bean,
any component hosting server - out of the box. Hmmm ;)
- 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>
Re: reduction ad unum
Posted by Stephen McConnell <mc...@apache.org>.
Stefano:
Here is a mixed response to your email.
I'm attempting to bridge real requirements relative to what we have in
the framework today, explain why there is a significant semantic gulf in
solutions within Avalon, present the rationale as to why and how
solutions play into this - and throw into this are problem statement,
actual requirements, and forward looking objectives.
Be warned - it's one of my longer emails.
;-)
Stefano Mazzocchi wrote:
> I would much rather start the discussion from scenarios of use and
> from the functionality required by all the framework user.
>
> For example, during the cocoon block discussion over at cocoon-dev I'm
> sure that the perception of the architecture of a container changed a
> little (at least, Stephen said that he had to think more about the
> functional needs that cocoon blocks required)
I think you are RIGHT with respect to a step back - some level of
overview is missing in the last round of discussions. What's missing is
the correlation of all of this with the respect to the original base - I
least I think it is worth going over the ground between the Avalon
framework as it is today, the issues and problems, and how the current
discussions address them. There are a lot of new people lurking around
and to really leverage these people an introduction/update is needed.
The Avalon framework as it stands today does not define the complete
component contract.
What is does do is define the interfaces and artifacts used in the
interaction of a container with a component. It says very little about
the way a component communicates its operational criteria to a
container. In fact, communication from component to container is limited
to a few marker interfaces. The solution to this has been the evolution
of two different approaches:
Framework default - programmatic resolution
ECM - dynamic resolution
Phoenix - static resolution
The end result of this is the following implicit meta-model evolution:
Avalon Framework
Meta-Model
^
|
------------------
| |
ECM Phoenix
Meta-Model Meta-Model
Both of the branches overload framework specifications in order to
resolve problems.
The solution to this is to (a) recognize the different semantic of the
respective models, and (b) establish a comon mechanisms for
communicating this to a container. Both the ECM and Phoenix strains
introduced mechanisms to achieve this. The ECM approach is through a
roles file which is basically a configuration instance that holds a
conceptual model, combined with dynamic dependency resolution (which
makes assembly a lot easier but also position validation as a
run-and-see-what-happens). In contract, the Phoenix model came up with
the Block descriptors which enabled assembly and system validation in
advance of deployment.
What come out of this is that there at least two fundamental things
missing in the Avalon Framework as it is today.
* complete communication of component operation requirements
to its hosting container
* of which the concept of an assembly strategy (static or dynamic)
is one of several computational aspects
Consider the following picture:
|-------------| |------------|
| container |<------------------------> | component |
| | component | class |
|-------------| introspection |------------|
(returns boolean values
- is X instance of Y)
Options available according to the framework are limited to
introspection. Does the component implement interface Initializable,
Does the component implement interface SingleTreaded, etc. Based on this
introspection based assessment it is possible build and deploy a minimal
component. There is no information about context (which means that
context is 100% container dependent based on current spec), it provides
not information about service dependencies (which means that Serviceable
and Composable interfaces are 100% container dependent based on current
spec).
So what does this mean - it means that the Avalon Framework spec is
basically only any good if you use it within the context of (a) an
existing container, or (b) your own programmatic management of component
which is in effect code acting in the role of a container.
Let's take a leap forward - the meta stuff - its only about the problem
of communicating deployment criteria from a component to a container.
Consider the following:
|-------------| |------------|
| container |<-------------------> | component |
| | component | class |
|-------------| type defintion |------------|
(returns complete
type model with lifecycle,
lifestyle, assembly strategy,
etc., packaged in object model)
What we have here is a scenario where a developer can include
information about a component with the component class that is
sufficient for a generic container to say - YES or NO on deployment. The
container can look at information concerning deployment constraints such
as lifestyle - instead of doing introspection on interfaces, we lookup
an attribute in the model named avalon:lifestyle - and if the value if
"per-thread" then we known how to handle lifestyle - but that's not the
kicker - the kicker comes in when we look at things like service
dependencies, context criteria, assembly strategy, etc. These aspects of
a component can be declared so that any container that understands the
components meta model can make an assessment of its ability to deploy
that component. This has some very important implications:
(a) assessment can fail with a constructive and detailed explanation
(b) the information provided by a component can be container neutral
(c) containers can optimize solutions in advance (pre-loading
components, etc.)
>
> Don't get me wrong: I'm pretty damn sure that you guys have most of
> the solutions at hand at this point, but I would like to start from
> "problems" and then drawing solutions, rather than refactoring
> different solutions and futher abstract them.
The problems are:
1. the current Avalon Framework contracts are insufficient
for anything more than container specific solutions
2. due to an insufficiency in the current spec with respect
to retrieval of information from a component concerning
its operation requirements
>
>
> I'm not saying it's a bad thing, it's just that I fear that not many
> people, even on this list, are able to follow the discussion of
> refactoring between the various containers.
I remember first getting involved in Avalon and wondering if I would
ever get to grips with the framework as it is. This whole discussion is
going a big step beyond - so it's easy to loose track. But actually,
it's not so dramatic.
Consider the following:
* ECM style solution to framework deficiencies - the dynamic
resoltion strategy and represented by Fotress and ECM.
MyService service = (MyService) manager.lookup(
"org.somewhere.MyComponent" );
This implementation of a component or service manager
"assumes" that the argument to lookup is an interface name
with possible extra sugar. The implementation understands
the syntax and semantics and handles resolution of a solution
based on runtime availability of components in the classloader
together with application context supplied in a roles file.
* Phoenix style solutions to framework deficiencies - the declarative
resolution strategy and represented by Phoenix and Merlin
MyService service = (MyService) manager.lookup( "vault" );
This implementation of a component or service manager knows
what "vault" translates to in terms of a service interface and
knows what components to supply to service that interface. This
implementation assumes that all of this information about role
to service mapping, service to component provision, etc. is
taken care of within an internal framework based a bunch of
pre-declared assembly information (either static or derived).
These are two well defined strategies from service resolution and yet
even today, we do no have a standard framework approach for a component
to declare - "hey, I want to be deployed using strategy X".
>
> Real life scenarios will make a better way to understand the reason
> behind an architectural choice. Something that I personally found very
> hard to get when the Avalon 5 discussions took place.
Here is a real life scenario. I write a new component.
public class HelloWorld implements Initializable
{
public void initialize()
{
System.out.println( "hello" );
}
}
This component would probably run in Tweety (the edu. container), will
run in Merlin, will not run in Phoenix, and will probably run in
Fortress. If we add some javadoc adornments and expand the application
level assembly directives it will run in Phoenix. If we add some xinfo
files in Merlin is becomes usable as supporting service. Problem is that
(a) the definition of an Avalon component is insufficiently defined, and
(b) the mechanisms across containers make some very divergent semantic
assumptions and present different models in terms of how component to
container communication is handled. This means big problems in
portability, more overheads for the component developer and extra work
for container developers attempting to resolve other container assumptions.
>
>> In another thread, Paul Hammant and Peter Goldstein were discussing
>> issues
>> over how to add more robust semantic contracts to the Frameworks.
>> More work
>> to do, but acceptable points of convergence appeared to be in the
>> offering.
>
>
> I'm pretty sure that everybody on this list is tired of fighting and
> cares about Avalon enough to set aside personal issues and work toward
> a common goal.
>
>> Do you believe that these represent a reasonable set of enumerable
>> points
>> around which the community can agree, pick the easiest ones to start
>> (you
>> have to start somewhere, might as well start with what you can do
>> easily so
>> that community behavior begins to build), and go from there?
>
>
> Yes, why not. But I'm afraid that only a very few will be able to
> participate.
>
> For example:
>
> > * Type management [the fork problem must be fixed]
>
> that might be perfectly clear to many here, but I don't have any clue
> about what that means. And this mean that I can't contribute my
> vision. And no, I don't think this is intentional, it's just that I
> (and others here) have missed many architectural discussions.
I am concerned about this as well.
There are a couple of things here - (1) the fork isn't a problem - yes -
there are a couple of packages - there are pro and cons about those
respective packages - at the end of the day I see a third package
emerging based on the clazz package, (2) the meta level stuff in
mechanics - data-structures, its not important - what is important is
how that information is managed and that's where things like type
managers and other Xxxx Manager come into play. Meta is an
implementation mechanisms through which we communicate information about
a component - it is nothing more, nothing less. The fun is in managing
this stuff.
> This doesn't mean that you guys have to slow down the process because
> of me or others that missed a few episodes. Not at all.
Put away any fears that you may have - things are moving forward!
>
> But I think it might be more productive, for everybody, to take a step
> back and restart from the solutions we want to provide to existing
> needs and problems. At least to avoid the accademic effect that might
> be coming out of those very deep and abstract architectural
> refactoring discussions.
>
> Hope you see my point here.
The point is understood and recognized.
I hope that this email provides some of the context and rationale around
this subject. There is another important aspect - if we go back to the
Merlin implementation .. after getting things in place and demonstrating
deployment of James and some work that Berin was doing, Berin starting
digging into Merlin. Initial reactions were positive and within a few
days (maybe hours) Berin managed to nail in on the less-than-perfect
parts of Merlin - namely the core-core of the implementation. While the
Merlin implementation has identified and resolved a much a management
aspects, the internal structure of type, profiles and appliance
management are difficult to work with - because its complex. This in
tern makes it difficult for others to get engaged because Merlin today
requires that you grasp a lot stuff. The refactoring work going on is
primarily targeting this aspect - facilitating separation of concerns
such that we can reach a object model that is easier to understand -
where other committers can engage with more confidence. That's part of
the process of ensuing that obstacles to community participation are
eliminated.
>> If so, how do you propose that the Avalon community begin to
>> formalize its
>> roadmap, and use it to marshall its resources?
>
>
> I would love to see each one of us writing an email where he/she
> explains the functional needs and the expectation out of Avalon and an
> Avalon container and the plans to use it.
Functional Needs
----------------
A component model that enables:
- complete consistency in development approach
- supports and enhances the notions IOC and SOC
- enables consistency across a broad spectrum of development
projects (within and external to Avalon)
A container model that ensures:
- drop dead simple deployment (standalone or embedded)
- automated assembly
- extendable/customizable at every level
- pre-deployment validation
- distributed service composition and runtime management
- pluggable enhancements
- block packaging
- a bunch of stuff in meta-driven policy management that I'm
saving up for a little later
Plans for Use
-------------
OSM internal work used an extended Merlin container. These extensions
deal with distributed service management - in particular the ability to
deploy and publish a service in one location and the ability for a
container in another location to bind this service as a dependency
provider. We need solutions that ensure that deployment of a something
like a catalina component can be reduced down to nothing more than a few
lines of configuration (we are currently running at about 18 lines - but
the target is 6-8). We are working on user-centric business model that
layers above all of this and provides a view of distributed containers
and services as task owned by users, held in workspaces, connected to
processes, accessed by members of a digital communities, controlled by
community and process policies (express as meta-policy). See
http://www.osm.net/doc for more details.
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: reduction ad unum
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
> I would love to see each one of us writing an email where he/she
> explains the functional needs and the expectation out of Avalon and an
> Avalon container and the plans to use it.
Big time! +100000000000000000000000000000000000000000000000000
Explain problems and how applying specific parts of Avalon solve them.
Include implementation examples. .
That would be lucious! A guy can dream... Boy if thats what my dreams
are of I need a life ;-)
>
> Avalon is *nothing* by itself. So each one of us has plans on how to
> build something on it.
>
> Let's put them on the table and start from there.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: reduction ad unum
Posted by "Noel J. Bergman" <no...@devtech.com>.
I think that we're just looking at it from different directions. My
thinking was in two parts.
First, when it became clear early this week that this community was going to
have to come together then when the questions of where were things
discordant came up, fingers were pointed primarily at the multiple
containers. Everyone seems OK with the notion of a single framework and a
library of components. And when the focus turned to those containers, the
level of discourse that the developers threw back was at the level of
architecture. So I figure that if that is the level at which they are
starting to talk, and as long as those conversations are productive and
convergent, then why not go with it for a time, and pickup some of the low
hanging fruit -- the easy agreements? A few easy victories might be just
the thing to boost spirits.
Second, my implicit thinking is that any justification for an architectural
or design choice has to include real-life examples. So my thought was that
as the developers start to pull together these common approaches outlined by
Stephen, Peter, and others, that we'd have something more substantial to
deal with, in terms of the architecture to review, and the reasons behind
it.
> I'm afraid that only a very few will be able to participate.
> For example:
> > * Type management [the fork problem must be fixed]
That is totally *MY* fault. Stephen provided nice descriptions for all of
his items, but I clipped just the headers for my summary. I viewed the
scope of the lists provided by Stephen and Peter as very encouraging, and
the intent of my collecting them was along the lines of "hey, if the Avalon
Community feels that these are ripe, then these seem like a good set of
starting points for group activity."
Regardless, I do think that it behooves us, and I certainly include myself
in this category, to ask questions about anything we don't understand. If
only because there a fresh outside perspective is valuable, and developers
are generally our own worst reviewers.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: reduction ad unum
Posted by Stefano Mazzocchi <st...@apache.org>.
Noel J. Bergman wrote:
> Stefano,
>
>
>>I like Berin's proposal of layered containers:
>> - reference implementation
>> - embeddable
>> - standalone
>>and I would love if they shared code directly rather than having
>>different implementations of the same interfaces.
>>So, let's start from here: is anybody against this?
>
>
> To begin the process, what do you think of Stephen McConnell's recent
> postings? As I understand it, and I expect to be corrected if I am wrong,
> he believes that:
>
> * service management
> * type management
> * profile management
> * appliance management
> * logging management
> * context management
> * configuration management
> * component assembly
> * lifecycle processing
> * lifestyle handling
>
> are fairly mature service facilities that are well enough understood and
> developed to support strong common contracts, and considerable common code.
> He also mentioned classloader management, containment strategies, and
> security policy management as additional areas for consensus, but which he
> didn't feel were as well understood.
>
> These could add to the list of existing facilities listed by Peter Donald as
> in process for sharing, if not already shared:
>
> * extension management
> * logging
> * XML Policy
> * classloader management.
> * Type management [the fork problem must be fixed]
> * Configuration validation
> * JMX integration
> * Isolation management (ThreadContext + jprocess)
> * Pooling
>
> I'm not sure why things like pooling aren't taken from Commons, but that's a
> matter for a technical discussion, not a process discussion.
>
> Peter further suggested that "compiled interceptor chains" would help to
> build "a viable container IMO that satisfies all our needs" and pointed out
> three other specific areas:
>
> * [component info] can be cross container relatively easy.
> * [Component assembly] is likely to be about 70% portable
> between containers
> * [component runtime state] will most likely be completely
> container dependent.
>
> It isn't 100% shared, but it is a starting point.
What concerns me a little with this approach (but that might be only me
so feel free to ignore if nobody resonates with this vision) is that we
are discussing architectural solutions and not functional requirements.
I would much rather start the discussion from scenarios of use and from
the functionality required by all the framework user.
For example, during the cocoon block discussion over at cocoon-dev I'm
sure that the perception of the architecture of a container changed a
little (at least, Stephen said that he had to think more about the
functional needs that cocoon blocks required)
Don't get me wrong: I'm pretty damn sure that you guys have most of the
solutions at hand at this point, but I would like to start from
"problems" and then drawing solutions, rather than refactoring different
solutions and futher abstract them.
I'm not saying it's a bad thing, it's just that I fear that not many
people, even on this list, are able to follow the discussion of
refactoring between the various containers.
Real life scenarios will make a better way to understand the reason
behind an architectural choice. Something that I personally found very
hard to get when the Avalon 5 discussions took place.
> In another thread, Paul Hammant and Peter Goldstein were discussing issues
> over how to add more robust semantic contracts to the Frameworks. More work
> to do, but acceptable points of convergence appeared to be in the offering.
I'm pretty sure that everybody on this list is tired of fighting and
cares about Avalon enough to set aside personal issues and work toward a
common goal.
> Do you believe that these represent a reasonable set of enumerable points
> around which the community can agree, pick the easiest ones to start (you
> have to start somewhere, might as well start with what you can do easily so
> that community behavior begins to build), and go from there?
Yes, why not. But I'm afraid that only a very few will be able to
participate.
For example:
> * Type management [the fork problem must be fixed]
that might be perfectly clear to many here, but I don't have any clue
about what that means. And this mean that I can't contribute my vision.
And no, I don't think this is intentional, it's just that I (and others
here) have missed many architectural discussions.
This doesn't mean that you guys have to slow down the process because of
me or others that missed a few episodes. Not at all.
But I think it might be more productive, for everybody, to take a step
back and restart from the solutions we want to provide to existing needs
and problems. At least to avoid the accademic effect that might be
coming out of those very deep and abstract architectural refactoring
discussions.
Hope you see my point here.
> If so, how do you propose that the Avalon community begin to formalize its
> roadmap, and use it to marshall its resources?
I would love to see each one of us writing an email where he/she
explains the functional needs and the expectation out of Avalon and an
Avalon container and the plans to use it.
Avalon is *nothing* by itself. So each one of us has plans on how to
build something on it.
Let's put them on the table and start from there.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: reduction ad unum
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano,
> I like Berin's proposal of layered containers:
> - reference implementation
> - embeddable
> - standalone
> and I would love if they shared code directly rather than having
> different implementations of the same interfaces.
> So, let's start from here: is anybody against this?
To begin the process, what do you think of Stephen McConnell's recent
postings? As I understand it, and I expect to be corrected if I am wrong,
he believes that:
* service management
* type management
* profile management
* appliance management
* logging management
* context management
* configuration management
* component assembly
* lifecycle processing
* lifestyle handling
are fairly mature service facilities that are well enough understood and
developed to support strong common contracts, and considerable common code.
He also mentioned classloader management, containment strategies, and
security policy management as additional areas for consensus, but which he
didn't feel were as well understood.
These could add to the list of existing facilities listed by Peter Donald as
in process for sharing, if not already shared:
* extension management
* logging
* XML Policy
* classloader management.
* Type management [the fork problem must be fixed]
* Configuration validation
* JMX integration
* Isolation management (ThreadContext + jprocess)
* Pooling
I'm not sure why things like pooling aren't taken from Commons, but that's a
matter for a technical discussion, not a process discussion.
Peter further suggested that "compiled interceptor chains" would help to
build "a viable container IMO that satisfies all our needs" and pointed out
three other specific areas:
* [component info] can be cross container relatively easy.
* [Component assembly] is likely to be about 70% portable
between containers
* [component runtime state] will most likely be completely
container dependent.
It isn't 100% shared, but it is a starting point.
In another thread, Paul Hammant and Peter Goldstein were discussing issues
over how to add more robust semantic contracts to the Frameworks. More work
to do, but acceptable points of convergence appeared to be in the offering.
Do you believe that these represent a reasonable set of enumerable points
around which the community can agree, pick the easiest ones to start (you
have to start somewhere, might as well start with what you can do easily so
that community behavior begins to build), and go from there?
If so, how do you propose that the Avalon community begin to formalize its
roadmap, and use it to marshall its resources?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>