On Jul 9, 2009, at 9:06 AM, David Jencks wrote:
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.
Both the OpenEJB and XBean Context implementations support "create
contexts on bind" and "remove contexts on unbind" in some fashion, so
I don't see an issue with using them.
On the indirection topic, I wonder if we could do something clever to
avoid the strangeness. Maybe create an "openejbroot" context, then
create an "openejb" subcontext. Bind the "openejb" into Geronimo for
federation and pass the "openejbroot" context to OpenEJB through the
JndiFactory. The "openejbroot" context would be the only context to
support the deep bind/unbind concepts and, for all intense purposes,
is hidden from the Geronimo tree, only the "openejb" subcontext is
exposed which would have any of the fanciness that you don't like --
i.e. so no one consuming the Geronimo tree could become dependent on
any odd behavior.
Thoughts?
-David
