Paul Hammant wrote:
Which one is fine?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 ]For me that is fine.
What is does do is define the interfaces and artifacts used in the interaction of a container with a component. ....
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 otherWhich is a demonstration of the value and utility of the component model and lifecycle patterns put forward by the framework as it stands today.
open-source projects.
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*I absolutely agree.
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.
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.
Your creating a scenario that suggests the solution is along linear path.* Right. In my email excange on that issue that Peter Goldstein was also involved with, I wasIn another thread, Paul Hammant and Peter Goldstein were discussing issuesI'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.
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.
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 :-)
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.
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.Imagine the diseased possibilities - a future uberubercontainer could be a mailet, servlet, bean, any component hosting server - out of the box. Hmmm ;)
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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
