What you propose need not preclude the configuration subsystem that I am proposing. It seems to me that you are proposing that Mailets look up any resource that they want in JNDI - be it a configuration object (or element), a DataSource, an ejb home object, etc. This is simply a matter of how one obtains a reference to the resource in question.
From the perspective of the Mailet API, what you are saying is that the API will not address any of these concerns at all. The more I think about it, the more I like this concept. If we carry this to its logical conclusion, we would get rid of the MailetConfig object from the Mailet API entirely. This means no structured config and no name/value pairs.
Yup. This could be good. Keep the Mailet API and spec focussed toward simply building up chains of Mailets and Matchers into Processors. Message repositories would have to stay in the API, too. I have my doubts about spools. They don't need to be visible to the Mailets. User repositories could disappear, too. Users would have to stay, but they could be looked up in a particular sub-context of JNDI (with a well-known name). (I wonder if we could fit in JAAS compatability?)
Of course, all of this is quite abstract from the actual config.xml file itself. I don't think that config.xml belongs in the Mailet spec at all. The only thing that matters to the mailet spec is that Mailets be able to obtain their configuration in the same way in container A as in container B. Hmmm. This comes back to the MailetConfig object. Whether you look it up in JNDI or call getMailetConfig() seems to be irrelevant.
Incidentally, I think you could support IOC with the JNDI model, too. Simply give each Mailet its own sub-context, containing references to just the resources that Mailet is supposed to have. Exactly which resources are in a given Mailet's context would be configured somewhere unspecified. (e.g. In config.xml.) You just say "thisResource" has "thisName" for context "myMailet".
Oops - I think we just got rid of MailetConfig again. What we do instead is to put all possible configuration parameters in the JNDI context that is returned by "new InitialContext()". (I wonder how to get our InitialContextFactory impl to know which mailet to know which Mailet was calling it? Not impossible, but perhaps it would be easier to use MailetContext.getJndiContext() instead?)
This actually gives us name/value pairs by default, an structure if the mailet container implementer wants to go to the effort of providing it! If the guy writing the mailet container doesn't provide a way of specifying a subcontext of the context given to a mailet, then the mailet author won't use one. Of course, trying to run your Mailet in a container that doesn't provide sub-contexts after writing it for one that does would cause headaches, but you would get that kind of problem with any value add that a particular container implementer provided.
Right. That's it from me for the moment.
Comments?
ADK
Noel J. Bergman wrote:
Aaron,
I would like to propose an alternative to more complex configuration. My
proposal allows the Mailet configuration to be kept relatively simple, as in
other proposals, but still provides support for more complex configurations
such as you've described.
My proposal is a resource-based model. I will explain this model in J2EE
terms, although were there some decision to use Avalon lifecycle methods in
the Mailet API, we could invert the pattern. In either case, the same thing
happens: the matcher or mailet gets a resource. The key is that we keep
this out of the Mailet API, and use standard Java APIs. This is a good
thing, in my view.
Are you familar with JNDI resources? Basically, we can define a resource in
the config.xml file. The resource is basically made up of a class and other
parameters. A JNDI lookup is used to get that resource. So for a matcher
or mailet requiring a complex configuration, we use the simple configuration
to tell it the name of a resource that it should use. Elsewhere in the
config, we establish that resource.
See the tomcat docs:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html.
The implementation is not difficult. We can take the work that Serge has
already done for the JNDI DataSource, and extend it generically with little
additional effort. And if we run into an implementation surprise (not
expecting one), code for all of this is present in Tomcat, a sister project.
For the simple, native, configuration format, I support the proposal for
which Danny recently posted the DTD. You can see how we can easily tell a
matcher or mailet to load a resource containing more complex content. And
advantage is that it enables modular configuration, separating those complex
configurations, instead of keeping them in-line.
Please give some serious consideration to this proposal. It covers more
than just config. If we adopt it, we have a simple model for extending
resources to matchers and mailets without a change to the Mailet API, and
without imposing artificial limits on flexibility.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
