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=421741They 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...
--kevan