On Jul 9, 2009, at 2:38 PM, David Blevins wrote:
On Jul 9, 2009, at 2:12 PM, David Jencks wrote:
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?
If that works for you, it works for me. To test, we'd just need to
do an undeploy and ensure the "openejb/Deployment/" namespace is
empty (sans our little "." placeholder binding).
I implemented this in geronimo. Not quite sure what test is needed...
the exception we were getting is gone anyway.
I still owe openejb an xbean jndi impl...
thanks
david jencks
-David
