On Jul 9, 2009, at 1:08 AM, David Blevins wrote:
On Apr 6, 2009, at 6:35 PM, David Blevins wrote:
One last "extra bit" that we do is the inverse of the "auto
subcontext adding" is "auto empty-subcontext pruning" via the
IvmContext.prune() method we use to prune the section of the
OpenEJB internal JNDI tree that holds the EJB refs (openejb/
Deployment and openejb/ejb). I don't recall if it was a TCK issue
or an issue on the G user list, but I added that pruning to get
around issues relating to undeployment of an app leaving behind
empty subcontexts that can result in inability to deploy apps that
might want to use that same name as a non-context. Happens more
frequently with longer deployment ids (i.e. appName/moduleName/
ejbName/interfaceClass).
On this bit I've just updated the Assembler so that it doesn't
assume the IvmContext -- the current code would blow up in Geronimo
if we tried to undeploy something. I've just surrounded the
IvmContext.prune() methods with an instanceof check.
This is fine but we should still get this functionality back in
place when using xbean-naming. So as we are currently doing a
"addDeepBinding(new CompositeName(name), value, false, true);" we
need to mirror that with "removeDeepBinding(name, true, false);". I
went to hack that in but the DeepBindableContext is a bit confusing.
The wrapper is constructed as a non-static inner class of the
WritableContext subclass, yet the object it wraps is obtained via
"(Context) new InitialContext().lookup("")". It delegates most it's
calls to the "looked up" Context and the bind calls to the outer
class Context. I have to assume that the two instances are one and
the same or the code would simply not work, but it seems unclear as
the WrapperContext could simply grab a reference to the outer class
and delegate to that all the time. For that matter you don't even
need a wrapper as the WritableContext subclass could do all the work.
Also any insight on why the WrapperContext bind method strips off
the "openejb" prefix? My gut says it's because the context
delate(s) are themselves the "openejb" subcontext.
The way this works in geronimo is that there's a DeepBindingContext
that gets federated into the global naming context at "openejb". So
binding needs to happen in the DeepBindingContext but the root context
is the global context, including the "openejb/" segment.
I don't like this but don't really see a way around it as long as you
want the bind and prune operations to operate on a context rather than
a simpler openejb specific object that only exposes the operations
that openejb actually uses.
thanks
david jencks
-David
