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.
cool
that's the nicest thing anyone has said to me on this list ever. (sad
but probably true too)
:-)
Yes I know.
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.
yes. Once other have had time to sound of on this particular issue we
should start
specing it out on the wiki as well. I prefer your code-first method but
think some level
of specification is also required. Mainly because I'm way to lazy to
search mail archives
when it comes time to implement.
-Andy
d.
> d.
