Aaron:
You have lost me - can you expand on something for me?
Context myContext = new InitialContext();
How does a container control what is in the instance myContext?
Cheers, Steve.
Aaron Knauf wrote:
Nicola Ken Barozzi wrote:
This is not true IOC. The Mailet asks for something, it is not given it.
IOC in practice means that the container calls a method on the child.
This is not the case here...
:-)
From my previous post - "My current thinking is closer to IOC than to
pull, but not entirely the same." ... "IOC is there in spirit".
The calling of a particular method on the child is an implementation
detail. The salient point in my proposal is that the container is
still in control of what resources the Mailet has access to, because
it has to put them in the mailet's context.
I agree that this is not true IOC, as defined by the Avalon designers,
however the major benefit (having the container maintain control of
resources used by the component) is still there - I just have a
different way of achieving it.
One thing I like about this is the huge scope that container
implementers have for providing access to value-add features. The
ability to pull an actual DataSource out of the context, rather than
just a JDBC url is a good example. On the surface, this may seem
like an invitation to sabotage mailet portability. I think that
quite the opposite is true.
Then this is not a configuration, but a ComponentManager. Avalon has
separated the concepts, here they are intermixed.
There is a place when this still happens which is the Context, but
it's also the most controversial part of the Framework and the most
unportable one. This is basically a Context as I see it.
Yes, this is basically a context. I do not believe that this is a bad
thing. We are specifying a contract between the Mailet and its
Container that says that the mailet container must place everything
that the mailet desires into the mailet's context. (Kinda like your
own personal djinni!) Essentially, the Context becomes a facade into
whatever mechanisms the underlying appserver wishes to use to provide
these resources.
As mentioned in my previous post, I believe that this enhances
portability. It does this in the following manner:
1) It uses a standard API (JNDI) for access to resources. It is
more reasonable to expect that an alternative mailet container will
provide JNDI, than it is to expect that the Avalon ComponentManager
interface will be provided.
2) It provides a layer of indirection between the way that the
Mailet refers to a resource and the way that an appserver provides
it. The container serves as the translator here.
Here is an example of how the ToRepository mailet might differ if
written with this system
--------------- Current ToRepository mailet ----------------------
public void init() {
repositoryPath = getInitParameter("repositoryPath");
try {
passThrough = new
Boolean(getInitParameter("passThrough")).booleanValue();
} catch (Exception e) {
// Ignore exception, default to false
}
try {
repository =
getMailetContext().getMailRepository(repositoryPath);
} catch (MessagingException e) {
log("Initialisation failed can't get repository
"+repositoryPath);
}
}
------------------------------------------------------------------------------
----------------- New ToRepository mailet -----------------------------
public void init() {
try {
Context myContext = new InitialContext();
passThrough =
((Boolean)myContext.lookup("passThrough")).booleanValue();
repository = myContext.lookup("repository");
} catch (NamingException ne) {
log("Initialisation failed");
}
}
-------------------------------------------------------------------------------
As you can see, there is now no need to supply the repository name as
an init param. The mailet always refers to the repository by the same
name. The name will always be unique because each instance of a
mailet has its own Context and therefore its own namespace. If you
have multiple instances of the same mailet, the context for each
instance is configured separately. The fully qualified name of the
context is, of course, different for each instance.
In what way does this reduce portability? This is certainly more
portable than using Avalon API's. It is also completely
implementation agnostic. The actual contents of the context may come
from an XML file, a database, or may be generated on the fly by the
container, or a combination of all of the above.
Another advantage is that it is easier for new Mailet authors to
learn, because developers will often already be familiar with JNDI.
I agree that this is a very different approach to that currently used
by Avalon. Reproducing Avalon was not (and is not) the goal. In fact
quite the opposite is true. We want to keep Avalon out of the Mailet
API, but we still want to provide access to all of the useful
resources that Avalon provides. (That is kinda the point of using an
appserver.) This proposal provides a portable facade into the
resources provided by any appserver.
Cheers
ADK
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
