On Jul 9, 2009, at 2:03 PM, David Blevins wrote:
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?
That might work, I'd be a little worried about whether
getNameInNamespace() would work right for a context federated into 2
other contexts.
I got involved in untying some other knots. For now maybe the
geronimo xbean stuff could just implement unbind to strip prefixes and
call removeDeepBinding?
thanks
david jencks
-David
