On Apr 20, 2009, at 12:12 PM, Jean-Louis MONTEIRO wrote:
Laird,
I found the problem (on a new project created from scratch ;-)).
If you duplicate the line
this.context = new InitialContext(properties);
it will work.
A JIRA already exists on that point.
https://issues.apache.org/jira/browse/OPENEJB-1011
https://issues.apache.org/jira/browse/OPENEJB-1011
I don't know why, but sometimes the InitialContext used to bootstrap
OpenEJB
is corrupted.
It's basically due to this strange way that the InitialContext works.
You can register a provider to handle lookups that start with a prefix
(see Context.URL_PKG_PREFIXES which is an internal flag). When
someone does a "new InitialContext().lookup("java:foo")", the
InitialContext looks for a class called '<any-package-
prefix>.java.javaURLContextFactory', instantiates it and does the
lookup using that factory.
But when the InitialContext is constructed with properties that
contain an Context.INITIAL_CONTEXT_FACTORY, it decides to go a
different route entirely, ignores the javaURLContextFactory
implementation and instead delegates the call to the Context created
by the InitialContextFactory. Kind of a messy API, but that's the way
it is.
To get around it I basically had to beef up the IvmContext
implementation to catch "java:" lookups and delegate them to our
"javaURLContextFactory" implementation. This should give us a more
consistent view of url lookups. In lots of situations (tomcat or
geronimo) the "java:" provider is already taken, so it seemed like a
good additional measure to add a new prefix "openejb:" that would be
guaranteed to work more universally. So in 3.1.1 using
"openejb:Resource/TestDataSource" is definitely preferred to
"java:openejb/Resource/TestDataSource".
-David
