On Jun 26, 2009, at 1:11 PM, Kevan Miller wrote:
On Jun 26, 2009, at 12:15 PM, David Jencks wrote:
On Jun 26, 2009, at 6:11 AM, Kevan Miller wrote:
On Jun 26, 2009, at 3:26 AM, David Jencks wrote:
On Jun 26, 2009, at 12:02 AM, chander_bawa wrote:
Thanks Djencks,
You are right. I tried deploying the ear from command line and
faced the
same issue.
The thing is i am working on upgrading the geronimo server from
1.1.1 to
2.1.4 and the application is working perfectly in 1.1.1
My confusion is why this error came when app is deployed on
2.1.4 when it
worked perfectly on 1.1.1?
The only reason I can think that this might work on 1.1.1 is that
we had a bug in the jndi implementation in 1.1.1 that lets the
lookup succeed. It should fail on 1.1.1 just as it does on 2.1.4.
If you answer the questions I asked in my previous reply I might
be able to suggest a way to proceed. For instance you might be
able to look the destinations up in the jca:/ global jndi context.
I don't think they're looking for destinations. Instead, it's
looking for a TransactionManager. This same problem was reported
back in April. That user reported that the oracle adapter was
looking for "java:comp/pm/TransactionManager". I wonder if they
could be configured to look for "java:/TransactionManager".
I'm also wondering if throwing a RunTime exception is the
appropriate behavior, in this situation. Why not a
NamingException? I confess that the subtleties of JNDI are
frequently lost on me...
I think a RuntimeException might be appropriate here..... there's a
major logic problem in how the user is attempting to use jndi, this
is not a problem due to someone forgetting to bind something in jndi.
Well, not necessarily a logic error. Code may be looking for a
TransactionManager in a number of jndi locations. For example, see
the following OpenJPA code -- http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/ee/AutomaticManagedRuntime.java?annotate=421741&pathrev=421741
They are catching Throwable, when looking for a TM in a number of
locations. Don't know what Oracle is doing, here. But it sure sounds
like they are treating a RuntimeException differently from a
NamingException. You might argue that they should be more accepting.
We've had two people report this problem. I'm just trying to see if
we can/should *fix* the problem...
Ya, you're right... I guess NotContextException is probably good.
thanks
david jencks
--kevan
