On 11/6/06, Andrew C. Oliver <[EMAIL PROTECTED]> wrote:

I'm not really particularly interested in James specific needs.  I am
interested in a standardized
portable Mailet API.  I would like to participate in mailet API
specifically so long as there is a
consensus that the same mailet running on different implementations
without code changes is
a desirable goal.

Its certainly my goal Andy, to the extent that I'd be prepared to
release the API in advance of James implementing it, so long as we
also had an RI or SDK to release which could be used to support
container independant mailet development.

Your involvement would obviously help to promote it as a goal of the
group, and would enhance its credibility precisely because of your
distance from James.


<sniped a lot of my own drivel/>

I don't entirely disagree.

that's the nicest thing anyone has said to me on this list ever. (sad
but probably true too)

:-)


I guess if you can explain how you would provision two instances of a
service otherwise
then I might be able to wrap my head around it.

Not sure, which is why I suspect we *will* need them.

Local namepaces are generally used for configuration settings ala (which
I don't particularly like JNDI for, preferring
to inject into individual setters), portability and instance separation.

I'm not mad on the idea of using JNDI for config either, but its
always going to be available to vendors and developers via
context.bind unless we lock it down, which I'm not crazy about either,
so I guess we can only sneer about it and attempt to cover the bases
with a well designed API.

That said the indirection provided by mapping global to local is a
good thing, its just that the means of doing it isn't easy to trace or
debug (debug errors in the mappings I mean, not the things which are
bound and mapped). I'm 99% sure we're a long way from needing to make
a decision about deployment descriptors, I'm happy to let this remain
undecided until we actually do need an answer, none of the PoC stuff
would be invalid in either case.

d.



> d.



Reply via email to