[ openjms-Bugs-1123902 ] Heirarchical names results in NameNotFoundException

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
>Status: Closed
>Resolution: Fixed
Priority: 5
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:48

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642