Peter M. Goldstein wrote:
All,
<minor-rant>
<snip>
</minor-rant>
Might I kindly suggest that when you want to collect information about
another project, you query the dev list for that project? Idle
speculation by the Avalon developers is hardly profitable and is not
really an effective way of evaluating customer needs. See my comments
on the current discussion below.
thatlittleI'm not sure that this is a great example. The MailetContext shares
in common with the Avalon Context, other than a name. It's the way
aContainer)
MailetContainer (potentially very different from an Avalon
domain-specificprovides contextual information to a Mailet, which is a
leftmechanismscomponent running in a well-defined environment.That pretty much defines the purpose of Avalons context ;)
ie Take the ServletContext and remove configuration mechanisms (or
Configuration/Parameters in Avaloon terms) and service provision
(or ServiceManager/ComponentManager in Avalon terms) and you are
withindication
what should remain in the context.Exactly what I thought. I preferred to use this Context instead of the
ServletContext because it's about something that uses Avalon; the fact
that it does not extend the Avalon Context though is another
of something that's not really ok.This dialogue is not quite right. Let's clarify a few things:
Leo Simons wrote:
> Apples 'n pears if you ask me.
>
> The JAMES MailetContext is not intimately related to the
> avalon Context
> at all. The MailetContext is used in a well-defined problem domain
> (e-mail; mailets), the avalon context is way more generic.
So, how do we put this?
It's evident to me that there is some kind of miosmatch here between
avalon devs them selves, and also avalon devs and users.
Here is the one and only way that the James source code currently uses
the Avalon context. This is to obtain the application base directory,
which is used in configuration URL resolution. This critical usage
isn't even mentioned in the above discussion. But it appears to be
consistent with all the divergent views of the Context, as the base
directory is a containter-provided data value that is made available to
the components.
There is an additional location where the Phoenix-specific BlockContext
should be used instead of the current code as written. In the
RemoteManager code James shuts down the system by directly calling
System.exit(0). That's not exactly a well behaved component, as it
doesn't give the container a proper opportunity for cleanup.
Instead, this code should call the requestShutdown() method of
BlockContext for a clean shutdown. Of course, this would further couple
us to Phoenix. And, from the recent discussion on the list, there
appears to be confusion as to whether this sort of method (side-effect,
no data) belongs in the Context. In any case, what James does is wrong,
but it's not clear to me exactly what would be the correct thing to do,
or even if Avalon has any ability to support the right thing in a way
that doesn't lock us to one container.
Now, on to the MailetContext. This has zero, zip, nada to do with the
Avalon Context, Paul's desires notwithstanding. In fact, some
discussions of the proper behavior of the Avalon Context (as a read-only
repository of container-provided data) clearly don't seem to support the
idea of implementing the MailetContext as an extension of Context.
The MailetContext is primarily used by Mailets to execute actions (i.e.
bouncing emails, placing an email on the processing queue) or to check
values (i.e. checking a server name to see if it's local), neither of
which seem to jibe with the read-only data container model espoused by
some.
Note that the current version of the Mailet API shouldn't be taken as
the final word. Explicitly slated for the next revision of James is a
redesign of the Mailet API. Some James developers (notably me) will be
pushing to remove at least some of the above from the MailetContext
(i.e. bounce logic). And we may find it desirable to add additional
functionality to the James-provided Mailet context. But this discussion
still lies in the future.
As a prelude to future James requirements, I would say that the most
important idea remains the contract(s) provided by a Context. Once
again, it is critical that a developer writing a component or set of
components that use Avalon be able to determine what contracts and
associated interfaces are provided by a container in a
container-independent way. Moreover some subset set of those
contracts/interfaces must be container-independent if it is going to be
possible to write components that are non-trivially
container-independent. These are the essential points.
+1
As far as the counter-argument that "containers have nothing in common",
all I can say is that seems highly unlikely to me. If a container
exposes the ability to address files in the file system, a unified
interface seems possible. A container-independent interface for
exposing container identity information (i.e. name, version string)
seems easily within reach. A common interface that allows the component
to request component and/or container shutdown from the container also
seems feasible. Not all features need to be encapsulated in common
interfaces, but some should. Honestly, these three would satisfy James
entirely. And make it much more container portable. I think more
attention is required on this front.
+1
On a related note, I'm also going to say here that I really like theTwo things I want to take issue with:
version of the Context logic that Noel was pushing, where the Context
lookup involves passing in a contract interface to the lookup and
retrieving a class that implements that interface. It seems an
effective and extensible way to provide container-defined services.
It also seems compatible with what seems to me to be the natural
separation between Contextualizable and Serviceable. Context involves
data and services that are uniquely owned by the container (i.e. for
Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James
Mailets, getPostmaster(), isLocalServer(String)). The essential
distinction as I see it is that services should be user-defined and
configured, while context-related items should be container-defined and
not require configuration. Also, the services may include a
configurable dependency chain, while Context implementations should be
available before any services are loaded and should not have a
configurable dependency chain.
Firstly, I think the work "container" in the above context is much too broad - a container deals with a lot of things - one of these things is lifecycle mangement within which one aspect is context - I guess in my head thare is a signifcant difference between "container" (the system), "containement context" (the container side context concern) and "context" (the client side view of all of this). A "containment context" can be declared by interface (e.g. BlockContext) - the container implemetation can use this information to establish the "containerment context" for the component by deploying the appropriate "containment context provider".
Second point - how a container establishes a particular container context is a container concern - there should no constraints here on how a container resolves the requirement- i.e. I don't agree with the last sentence above.
This distinction can be applied to any container/component model, not just Avalon. And it also demonstrates why nested containers should not necessarily simply pass through a Context from one level to another.
Agreed.
The above definition is tightly tied to the nature of the container and
the API it supports. Hence what is in the Context in a nested container
might not naturally fall into the Context of its parent container.
I will be raising this design suggestion as part of the discussion over
the next revision of the Mailet API.
Looking forward to it. Cheers, Steve.
--Peter
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- 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]>
