Noel J. Bergman wrote:
I disagree. I am certainly taking your proposal somewhat further that you intended. I believe that this direction leads to a simplification of the Mailet API and of the contract between the Mailet container and the Mailet.Aaron, I think you are getting just a bit carried away.
Why have two ways of doing something? I think it is better for mailet authors to know that there is one place to go for all resources, than to go to one place for simple parameters and to anouther for more complex ones. Using JNDI for both would (in simple cases) still be exactly the same amount of code for the Mailet author. As I mentioned before, we could implement our own Context sub-interface to provide accessors that return strings.
I am not proposing that we remove getInitParameter from the Mailet API.
That is all that most matchers and mailets need, and it is easy to manage.
I am proposing that resources, including more complex configuration files,
would be accessed via JNDI.
e.g.
---------------------------
MailetContext myContext = new InitialMailetContext();
String myParam = myContext.getAttribute("myParam");
--------------------------
How is this any more complex than getInitParameter?
James has no equivalent to the Webapp concept. There is no mechanism for the grouping of Mailets into "mailapps". (In fact, I am not really sure that it would even make sense.) If there were, then a per mailapp Context would certainly be a better granularity that per Mailet. However, each Mailet is currently a distinct unit, with distinct resource requirements.
The Context returned by new InitialContext() is specific to this Mailet.
You might want to rethink this notion. That is a lot of work for the container, and is not the way that the Servlet API works, which is per-webapp.
See my ToRepository example. Even for as simple a case as that, JNDI is simpler for the mailet author. This simplicity is primarily provided by per-mailet contexts.
There seems to be some perception that per Mailet Contexts are complex and difficult. This is certainly not true from the Mailet author's perspective. While there is some complexity involved from the container authors perspective, this is exactly the point of having containers at all - get someone to do the hard bits for you! The complexity involved in per-mailet contexts is certainly no worse than any number of other problems encountered by appserver authors. In fact most existing appservers already provide JNDI facilities - providing per-mailet contexts would be only a small step.
If worst comes to worst, and per mailet contexts prove impossible from off the InitialContext constructor, then "Mailet::getContext() : Context" is extremely simple to implement. As is "new InitialMailetContext(this)".
As for the complexity of actually getting the right stuff into the Context - achieving simple parameters is no more difficult this way than it is now. Putting links to other resources in the context is no more difficult than providing references any other way. Anything that should be provided globally would have a well-known name that would be implicity bound. Anything that should not be provided globally would have to be configured somehow anyway.
There seems to be some resistence to this idea, but I cannot see why. I have heard two objections so far:
1 - Servlets don't do it.
2 - It sounds difficult.
These are somewhat non-specific. I have tried to address both of these. Does anyone actually think that this would be detrimental to the container design, or to the mailet concept in any way?
Cheers
ADK
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
