Aaron Knauf wrote:
The calling of a particulat method on the client is not only an implementation detail, because it defines also a time in which it is given, and that is defined by the container, and a clean way of scoping the config done by the container.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.
I concede that you do achieve _part_ of the IOC benefits, yes.
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.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.
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.
Context myContext = new InitialContext(); How does it get scoped? In avalon it's given through a method, here?
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.
The fact is that Avalon APIs *are* implementation agnostic. And what you loose is a formal service dependency and supply system.
Another advantage is that it is easier for new Mailet authors to learn, because developers will often already be familiar with JNDI.
Doesn't compute ;-P
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.I agree with the intent but disagree somewhat with the solutions proposed. It seems to me that many things here are just a recreation of Avalon and the things that it solves starting from Avalon 2 ;-)
Ok, I'm joking, I really don't know where the truth lies, but I encourage you to continue pursuing your way. It will surely, as anything, have positive points and less positive ones. We will all learn from this.
I was thinking today, that I understood that you see Avalon as a utility system, not a service or component framework. For me mailets are services and components, this is why I see Avalon in them. It's natural.
But then I think about the servlet API, and how it has success even if in many points it's flawed. Heck, *anything* is flawed somewhere.
The mailet API list, the decoupling of Avalon (that was not really that well used now anyway), all make me think that you are all positioning the mailet API beside the Servlet one.
Then why not make mailets *extend* the servlet spec? Even if not in code, if it's not feasable, at least in practices. IE: How is this done with servlets? Ok, do it with mailets too! Like config, logging and all that stuff.
Politically and consumer-wise it could really be a plus.
Anyway, I don't have that much time to continue this interesting talk anymore, so I will back-off in a more lurker mode. I see that the discussions are very nice and active already, so I'm really happy :-)
Keep up the good work guys, James ROCKS! :-D
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
