Yeah, Ijust wonder how much James really nees it, but I think it may
be unavoidable
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.
If you had one EJB looking it up by
the "well-known" name on JBoss
the same code would fail on WebLogic.
yeah, what I'd propose would be that instead of using "well known"
names that the API actually constrains the namespaces which can be
used for portability.
Frameworks allow development to achieve benefits because they contain
pre-determined decisions which suit developments which don't challenge
the scope of the framework.
I think J2EE missed a trick by omitting to mandate namespaces more
thoroughly. After all I struggle to see why anyone would care what the
namespace is, so long as it is appropriately granular.
Vendor specific deployment descriptors and namespace mappings always
look like a kind of fudge, as if sun threw up its hands and said
"enough" because there was too much variability in too many
parameters. I understand that there needs to be extensibility at the
edges to allow a framework to accept new technology and new thinking,
and to evolve, and I understand that ther are benefits to vendor
specific extensions. What I don't accept is that those requirements
necessarily mean that a framework cannot mandate the things which are
comfortably in scope.
I don't entirely disagree.
This is less clear of an analogy here at this point, but supposing there
are a number of mailets and services
and that in some cases they can be swapped, or in the case of multiple
instances with different configuration
or location independence, the separation becomes more clearly
advantageous.
I agree that if you want to have two provisions of a single service
type you need to map a provision to satisfy a dependance. What I'm
asking is is that scenario a requirement for this API, or can we
reason that it'll be so rare that we can ignore it providing that we
don't actually exclude the possibility of satisfying it later?
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.
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.
d.
