On Tue, 4 Feb 2003 17:42, Aaron Knauf wrote: > Ok Folks, > > After careful deliberation, I think it is fair to sum up the JNDI > discussion as follows: > 1) Making JNDI integral to the Mailet container will not fly. Noel > correctly points out that lightweight container are made difficult > (impossible?) by requiring JNDI support. I can't really see the use of > a lightweight container, but my perspective is somewhat narrow on this > count, so I am willing to agree that someone else might find one useful. > > :-) > > 2) While I am convinced that per-mailet contexts are a great idea, > no-one else seems to be. This tells me that my approach here might be > the silver bullet that I am looking for (;-p), but others won't find it > generally useful - so I won't force it on anyone. > 3) Everyone seems to agree (or at least, not disagree) that JNDI is a > good way for James to implement general resource sharing. This is to be > considered a James-specific implementation detail and provided to > Mailets as extended functionality, rather than as part of the Mailet > API/spec. >
To tell the truth, the whole idea of using JNDI for standard resource access doesn't sit all that well with me. The JNDI Context interface just seems too broad and too general for what we want to achieve. I don't feel really strongly about this, but it seems that the primary benefit listed for using JNDI is that it's pre-existing standard. This is important, but not the only factor to consider. We should also examine whether it's a good match for what we want to provide to mailets. Namely: 1) Is there a close match between the javax.naming.Context interface, and what we want to provide to mailets? Do we want to provide a mutable context to Mailets? 2) Will using JNDI be easier for a Mailet author than, say, something like an Avalon Context? 3) Will using JNDI make it harder to provide a controlled, constrained environment for running Mailets. I'm a fan of IoC, and I think we need to keep control over what each Mailet can access. 4) Are we better off adding explicit lookup (and bind) methods to the Mailet API? Will this be clearer for Mailet authors than a simple, "for anything else you use JNDI"? 5) The hard part of resource provision is allowing Mailets to "declare" what they need, and for containers to set up their environment accordingly. The Servlet API just avoids this, it seems, by assuming everything is already there in JNDI under well-known names. This is simpler, I guess; and maybe that's all we want? Just some stuff I've been mulling over from behind the firewall, where my mailing lists are hidden from me :-/ (I'm starting to wonder if this work caper is all it's cracked up to be :). -- ciao, Daz --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
