Danny Angus wrote:
Yesterday I made some refactorings to the fork in the sandbox to play
with JNDI instead of avalon for service location.
Sadly I had to rush off with my changes uncomitted, but I thought I'd
give you an update anyway.
First of all on a practical level it works a treat (means "very well")
with o.a.naming from the directory sandbox (jars checked in to the
fork).
It works seamlessly with Avalon, because the services and datasources
can be made to bind themselves using a configured name in configure()
or a class constant in initialize() and unbind themselves in dispose().
Is this supplemental or instead of injection. I can see them being used
together.
at the moment I think there should be three or four contexts as follows:
.. snip ..
I'm trying to decide whether we need to mirror the J2EE idea of global
and
local contexts, and mappings between global and local bindings. I'm not
convinced, but not 100% sure that it isn't necessary to have local
contexts
either.
In order to avoid the predetermined "well-known" name situation that you
described
above. That is exactly why you want local contexts. Otherwise we have
the same kind
of issue that we have with "well known" ports. With names you can use
conventions
(name spaces) to avoid some of this, but collision is possibly
problematic. Generally
the prefix: part should not be a requirement. Usually this is used via
assignment (with
the exception of the java: which is the well understood local) via
configuration (aka jndi.properties)
to deal with multiple name servers. It just complicates configuration
unnecessarily. With
a separation between global and local the code stays independent of this
and other namespacing
issues anyhow.
For a demonstration of this look to EJB 2.1 and porting between JEE
appservers. Say you wanted
you JBoss app to also run on weblogic and you used the "well known"
defaults for where EJBs were
bound. On JBoss a bean with ejb-name "FooBean" would be bound as
"FooBean" where on web logic
it would be bound as ejb/FooBean. If you had one EJB looking it up by
the "well-known" name on JBoss
the same code would fail on WebLogic. If that same code were configured
so that it always looked up
in the local context, the code would succeed with configuration on
either appserver.
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.
-Andy
