SourceForge.net
2006-02-05 05:48:26 UTC
Bugs item #1123902, was opened at 2005-02-16 23:23
Message generated for change (Comment added) made by tanderson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1123902&group_id=54559
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: jndi
Group: v0.7.7-alpha-1
Submitted By: Tim Anderson (tanderson)
Assigned to: Tim Anderson (tanderson)
Summary: Heirarchical names results in NameNotFoundException
Initial Comment:
Originally from
http://article.gmane.org/gmane.comp.java.openjms.use
r/2289
Hi,
I'm having a problem with openjms 0.7.6.1 and
heirarchical naming of
queue connection factories and queues that I'm
migrating over from some
existing weblogic JMS code.
For instance, I have:
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory
name="cardionet.QueueConnectionFactory"
/>
</ConnectionFactories>
</Connector>
</Connectors>
<AdministeredDestinations>
<AdministeredTopic name="cardionet.CallStatus">
<Subscriber name="sub2" />
</AdministeredTopic>
<AdministeredQueue
name="cardionet.ReportTaskQueue" />
<AdministeredQueue
name="IncomingP2SendMessageQ" />
</AdministeredDestinations>
The problem is that the lookup of the queue connection
factory with the
heirarchical name works fine but when I try to lookup
the queue with the
heirarchical name, I get a NameNotFoundException.
This doesn't happen if
I lookup a non-heirarchical queue name.
Is this a bug in the avalon Context implementation?
Has anyone seen this
before?
Here is a sample stack trace that I am getting when
lookup up the queue
after successfully getting a handle to the
queueconnectionfactory:
javax.naming.NameNotFoundException:
cardionet.ReportTaskQueue
at
org.apache.avalon.excalibur.naming.memory.MemoryCo
ntext.doLocalLookup(Me
moryContext.java:89)
at
org.apache.avalon.excalibur.naming.AbstractLocalContex
t.localLookup(Abst
ractLocalContext.java:297)
at
org.apache.avalon.excalibur.naming.AbstractLocalContex
t.lookup(AbstractL
ocalContext.java:278)
at
org.apache.avalon.excalibur.naming.rmi.server.RMINami
ngProviderImpl.look
up(RMINamingProviderImpl.java:157)
at
sun.reflect.GeneratedMethodAccessor15.invoke
(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
sun.rmi.server.UnicastServerRef.dispatch
(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run
(Transport.java:148)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Transport.java:144)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.r
un(TCPTransport.ja
va:701)
at java.lang.Thread.run(Thread.java:534)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedF
romServer(StreamRem
oteCall.java:247)
at
sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:223
)
at sun.rmi.server.UnicastRef.invoke
(UnicastRef.java:133)
at
org.apache.avalon.excalibur.naming.rmi.server.RMINami
ngProviderImpl_Stub
.lookup(Unknown Source)
at
org.apache.avalon.excalibur.naming.RemoteContext.look
up(RemoteContext.ja
va:233)
at
org.apache.avalon.excalibur.naming.AbstractContext.loo
kup(AbstractContex
t.java:246)
at javax.naming.InitialContext.lookup
(InitialContext.java:347)
at com.cardionet.util.JMSClient.<init>
(JMSClient.java:50)
at
com.cardionet.jms.QueueClientTest.test_reportTaskQueu
e(QueueClientTest.j
ava:89)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at junit.framework.TestCase.runTest
(TestCase.java:154)
at junit.framework.TestCase.runBare
(TestCase.java:127)
at junit.framework.TestResult$1.protect
(TestResult.java:106)
at junit.framework.TestResult.runProtected
(TestResult.java:124)
at junit.framework.TestResult.run
(TestResult.java:109)
at junit.framework.TestCase.run
(TestCase.java:118)
at junit.framework.TestSuite.runTest
(TestSuite.java:208)
at junit.framework.TestSuite.run
(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.r
unTests(RemoteTe
stRunner.java:421)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.r
un(RemoteTestRun
ner.java:305)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
main(RemoteTestRu
nner.java:186)
Thanks in advance.
Charles
----------------------------------------------------------------------
Message:
Logged In: YES
user_id=557161
Updated CVS use spice-jndikit 1.2.
Fix will be available in 0.7.7-beta-1.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-07-14 00:46
Message:
Logged In: YES
user_id=557161
Reopening this. The fix isn't in 0.7.7 yet, as it uses spice-jndikit
1.1 which still has the bug, rather than the fork of the old avalon
version in 0.7.6.
Can be closed once spice-jndikit 1.2 is released which resolves
the problem.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-02-17 00:02
Message:
Logged In: YES
user_id=557161
Fixed in CVS, on the openjms_0_7_6_maint branch. Fix will
be available in the 0.7.6.2 release.
Note that you will need to perform the lookup using "/"
instead of "." i.e, the topic "cardionet.CallStatus" needs to be
looked up in JNDI using the name "cardionet/CallStatus", as
the "cardionet" part is bound a separate context.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-02-16 23:29
Message:
Logged In: YES
user_id=557161
The cause of this is identical to the bug report:
http://jira.codehaus.org/browse/SPICE-47
Will backport the fixes into 0.7.6.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1123902&group_id=54559
Message generated for change (Comment added) made by tanderson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1123902&group_id=54559
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: jndi
Group: v0.7.7-alpha-1
Status: Closed
Resolution: Fixed
Priority: 5Resolution: Fixed
Submitted By: Tim Anderson (tanderson)
Assigned to: Tim Anderson (tanderson)
Summary: Heirarchical names results in NameNotFoundException
Initial Comment:
Originally from
http://article.gmane.org/gmane.comp.java.openjms.use
r/2289
Hi,
I'm having a problem with openjms 0.7.6.1 and
heirarchical naming of
queue connection factories and queues that I'm
migrating over from some
existing weblogic JMS code.
For instance, I have:
<Connectors>
<Connector scheme="rmi">
<ConnectionFactories>
<QueueConnectionFactory
name="cardionet.QueueConnectionFactory"
/>
</ConnectionFactories>
</Connector>
</Connectors>
<AdministeredDestinations>
<AdministeredTopic name="cardionet.CallStatus">
<Subscriber name="sub2" />
</AdministeredTopic>
<AdministeredQueue
name="cardionet.ReportTaskQueue" />
<AdministeredQueue
name="IncomingP2SendMessageQ" />
</AdministeredDestinations>
The problem is that the lookup of the queue connection
factory with the
heirarchical name works fine but when I try to lookup
the queue with the
heirarchical name, I get a NameNotFoundException.
This doesn't happen if
I lookup a non-heirarchical queue name.
Is this a bug in the avalon Context implementation?
Has anyone seen this
before?
Here is a sample stack trace that I am getting when
lookup up the queue
after successfully getting a handle to the
queueconnectionfactory:
javax.naming.NameNotFoundException:
cardionet.ReportTaskQueue
at
org.apache.avalon.excalibur.naming.memory.MemoryCo
ntext.doLocalLookup(Me
moryContext.java:89)
at
org.apache.avalon.excalibur.naming.AbstractLocalContex
t.localLookup(Abst
ractLocalContext.java:297)
at
org.apache.avalon.excalibur.naming.AbstractLocalContex
t.lookup(AbstractL
ocalContext.java:278)
at
org.apache.avalon.excalibur.naming.rmi.server.RMINami
ngProviderImpl.look
up(RMINamingProviderImpl.java:157)
at
sun.reflect.GeneratedMethodAccessor15.invoke
(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
sun.rmi.server.UnicastServerRef.dispatch
(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run
(Transport.java:148)
at java.security.AccessController.doPrivileged
(Native Method)
at sun.rmi.transport.Transport.serviceCall
(Transport.java:144)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages
(TCPTransport.java:460)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.r
un(TCPTransport.ja
va:701)
at java.lang.Thread.run(Thread.java:534)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedF
romServer(StreamRem
oteCall.java:247)
at
sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:223
)
at sun.rmi.server.UnicastRef.invoke
(UnicastRef.java:133)
at
org.apache.avalon.excalibur.naming.rmi.server.RMINami
ngProviderImpl_Stub
.lookup(Unknown Source)
at
org.apache.avalon.excalibur.naming.RemoteContext.look
up(RemoteContext.ja
va:233)
at
org.apache.avalon.excalibur.naming.AbstractContext.loo
kup(AbstractContex
t.java:246)
at javax.naming.InitialContext.lookup
(InitialContext.java:347)
at com.cardionet.util.JMSClient.<init>
(JMSClient.java:50)
at
com.cardionet.jms.QueueClientTest.test_reportTaskQueu
e(QueueClientTest.j
ava:89)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at junit.framework.TestCase.runTest
(TestCase.java:154)
at junit.framework.TestCase.runBare
(TestCase.java:127)
at junit.framework.TestResult$1.protect
(TestResult.java:106)
at junit.framework.TestResult.runProtected
(TestResult.java:124)
at junit.framework.TestResult.run
(TestResult.java:109)
at junit.framework.TestCase.run
(TestCase.java:118)
at junit.framework.TestSuite.runTest
(TestSuite.java:208)
at junit.framework.TestSuite.run
(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.r
unTests(RemoteTe
stRunner.java:421)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.r
un(RemoteTestRun
ner.java:305)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.
main(RemoteTestRu
nner.java:186)
Thanks in advance.
Charles
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2006-02-05 16:48Message:
Logged In: YES
user_id=557161
Updated CVS use spice-jndikit 1.2.
Fix will be available in 0.7.7-beta-1.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-07-14 00:46
Message:
Logged In: YES
user_id=557161
Reopening this. The fix isn't in 0.7.7 yet, as it uses spice-jndikit
1.1 which still has the bug, rather than the fork of the old avalon
version in 0.7.6.
Can be closed once spice-jndikit 1.2 is released which resolves
the problem.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-02-17 00:02
Message:
Logged In: YES
user_id=557161
Fixed in CVS, on the openjms_0_7_6_maint branch. Fix will
be available in the 0.7.6.2 release.
Note that you will need to perform the lookup using "/"
instead of "." i.e, the topic "cardionet.CallStatus" needs to be
looked up in JNDI using the name "cardionet/CallStatus", as
the "cardionet" part is bound a separate context.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-02-16 23:29
Message:
Logged In: YES
user_id=557161
The cause of this is identical to the bug report:
http://jira.codehaus.org/browse/SPICE-47
Will backport the fixes into 0.7.6.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1123902&group_id=54559