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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjms-developer
Subject:    [openjms-developer] [ openjms-Bugs-1123902 ] Heirarchical names results in NameNotFoundException
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2005-07-13 14:47:09
Message-ID: E1DsiVx-0003iT-IY () sc8-sf-web1 ! sourceforge ! net
[Download RAW message or body]

Bugs item #1123902, was opened at 2005-02-16 23:23
Message generated for change (Settings changed) 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: Open
Resolution: None
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: 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 the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
openjms-developer mailing list
openjms-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openjms-developer
[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic