Bug 735030
Summary: | After deploying AdminObject for queue in EAP queue is not created on qpid side | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise MRG | Reporter: | Jiri Sedlacek <jsedlace> | ||||||
Component: | qpid-jca | Assignee: | messaging-bugs <messaging-bugs> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | MRG Quality Engineering <mrgqe-bugs> | ||||||
Severity: | urgent | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 2.0 | CC: | astitcher, iboverma, oskutka, wprice | ||||||
Target Milestone: | 2.1.2 | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | Type: | --- | |||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | 499109, 700494 | ||||||||
Bug Blocks: | |||||||||
Attachments: |
|
Description
Jiri Sedlacek
2011-09-01 08:45:54 UTC
I am not sure I understand the sentence: 'If the message producer is the first user of the queue, on the qpid side does not exist corresponding queue,' Could you clarify as well as provide your *-ds.xml file for your AdminObject? Weston, You can use *-ds.xml from qpid-java-jca examples, just configure the build.xml to use correct eap server and profile and mrg url. The behavior is below: after deployment of *-ds.xml and before sending message: [jsedlace@mrg01 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== reply-mrg01.mw.lab.eng.bos.redhat.com.7336.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 topic-mrg01.mw.lab.eng.bos.redhat.com.7336.1 Y Y 0 0 0 0 0 0 1 4 qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 26 26 0 442 442 1 4 qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7336.1 Y Y 0 0 0 0 0 0 1 1 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7336.1 Y Y 0 1 1 0 227 227 1 2 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7336.1 Y Y 0 13 13 0 76.2k 76.2k 1 2 after sending message no change: [jsedlace@mrg01 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 28 28 0 476 476 1 4 qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7352.1 Y Y 0 0 0 0 0 0 1 1 topic-mrg01.mw.lab.eng.bos.redhat.com.7352.1 Y Y 0 0 0 0 0 0 1 4 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7352.1 Y Y 0 13 13 0 77.0k 77.0k 1 2 reply-mrg01.mw.lab.eng.bos.redhat.com.7352.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7352.1 Y Y 0 0 0 0 0 0 1 2 after deploying MDB configured to listen to the queue/Hello - queue created with 15 cons: [jsedlace@mrg01 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7403.1 Y Y 0 0 0 0 0 0 1 1 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7403.1 Y Y 0 13 13 0 97.0k 97.0k 1 2 qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 32 32 0 544 544 1 4 reply-mrg01.mw.lab.eng.bos.redhat.com.7403.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 topic-mrg01.mw.lab.eng.bos.redhat.com.7403.1 Y Y 0 0 0 0 0 0 1 4 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7403.1 Y Y 0 0 0 0 0 0 1 2 amq.direct 0 0 0 0 0 0 15 2 after sending message this time, message is received: [jsedlace@mrg01 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 34 34 0 578 578 1 4 reply-mrg01.mw.lab.eng.bos.redhat.com.7415.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 topic-mrg01.mw.lab.eng.bos.redhat.com.7415.1 Y Y 0 0 0 0 0 0 1 4 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7415.1 Y Y 0 0 0 0 0 0 1 2 qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7415.1 Y Y 0 0 0 0 0 0 1 1 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7415.1 Y Y 0 13 13 0 33.9k 33.9k 1 2 amq.direct 0 1 1 0 13 13 15 2 Ok, I think there may be some misunderstanding here in regards to configuration and QPID in general: amq.direct is an exchange not a queue. So, when you initially deploy the *-ds.xml file nothing is created because amq.direct is again, not a queue but is an exchange that must exist in all AMQP compliant brokers. If you execute qpid-stat -e you will see something like the following: [wmprice@mrgm1 ~]$ qpid-stat -e Exchanges exchange type dur bind msgIn msgOut msgDrop byteIn byteOut byteDrop =========================================================================================== qmf.default.topic topic 1 9.93k 0 9.93k 5.56m 0 5.56m amq.direct direct Y 1 59 68 0 22.3k 22.4k 0 direct 5 0 0 0 0 0 0 amq.topic topic Y 0 0 0 0 0 0 0 amq.fanout fanout Y 0 0 0 0 0 0 0 amq.match headers Y 0 0 0 0 0 0 0 qpid.management topic 3 9.93k 0 9.93k 1.54m 0 1.54m qmf.default.direct direct 1 9 9 0 2.34k 2.34k Note the existence of the amq.direct exchange. At some point in your testing, you have inadvertently create a queue called amq.direct. This is causing the behavior you are seeing. A word about the examples: The example code is meant as a starter point for development, not an end in and of itself. When configuration destinations, you should really not use amq.direct for your testing as this is an exchange, not a queue. For a simple example, use something like the following in your *-ds.xml file: <mbean code="org.jboss.resource.deployment.AdminObject" name="qpid.jca:name=HelloQueue"> <attribute name="JNDIName">HelloQueue</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends> <attribute name="Type">javax.jms.Destination</attribute> <attribute name="Properties"> destinationType=QUEUE destinationAddress=hello;{create:always,node:{type:queue}} </attribute> </mbean> Which would result in something like: Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind ======================================================================================================== topic-mrgm1.6037.1 Y Y 0 0 0 0 0 0 1 4 qmfc-v2-mrgm1.6037.1 Y Y 0 11 11 0 24.1k 24.1k 1 2 qmfc-v2-ui-mrgm1.6037.1 Y Y 0 0 0 0 0 0 1 1 qmfc-v2-hb-mrgm1.6037.1 Y Y 0 0 0 0 0 0 1 2 reply-mrgm1.6037.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 hello 0 0 0 0 0 0 10 1 Obviously, you can use whatever name you like. I believe there are other bugs that have been filed as a result of this syntax/destination issue. I will go back and review. If this explanation is sufficient for you, you can close this bug. Weston, destinationAddress=hello;{create:always,node:{type:queue}} cannot be used with this version of jca adapter. But we need to define queues/topics in correct way, so it would be useful to prepare some verified and working examples, how to configure admin object, which we can use. Example for a queue direct://amq.direct//hello.Queue Note the use of the the direct exchange class, the exchange itself and the queue Topic topic://amq.topic//hello.Topic?routingKey='hello.Topic' I am providing the same description here: https://bugzilla.redhat.com/show_bug.cgi?id=734059 Queue is configured in this way direct://amq.direct//hello.Queue but the problem is the same, until first consumer is connected to the queue, you can send thousands of messages, which ends in the black hole. Next problem is missing routingKey for the queue in your example above. If I configure two queues in this way, message send to one is delivered into both. 'but the problem is the same, until first consumer is connected to the queue, you can send thousands of messages, which ends in the black hole. ' If no one is listening on that destination, messages will not be delivered. This is the expected behavior. Once you deploy your MDB(s), the message(s) will be delivered once they are deployed and activated. Note, the messages don't go into a 'black hole', the are enqueued and will be delivered when you deploy. 'Next problem is missing routingKey for the queue in your example above. If I configure two queues in this way, message send to one is delivered into both.' Why would you do this? This would be a misconfiguration. If you want a different routing key, simply add it as per the BURL syntax. The example I gave assumed one queue, not multiples. direct://amq.direct//hello.Queue?routingKey='hello.Queue.key1' direct://amq.direct//hello.Queue?routingKey='hello.Queue.key2' Remember, you need to have separate AdminObjects for each of these: <mbean code="org.jboss.resource.deployment.AdminObject" name="qpid.jca:name=HelloQueue1"> <attribute name="JNDIName">HelloQueue</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends> <attribute name="Type">javax.jms.Destination</attribute> <attribute name="Properties"> destinationType=QUEUE destinationAddress=direct://amq.direct//hello.Queue?routingKey='hello.Queue.key1' </attribute> </mbean> <mbean code="org.jboss.resource.deployment.AdminObject" name="qpid.jca:name=HelloQueue2"> <attribute name="JNDIName">HelloQueue</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends> <attribute name="Type">javax.jms.Destination</attribute> <attribute name="Properties"> destinationType=QUEUE destinationAddress=direct://amq.direct//hello.Queue?routingKey='hello.Queue.key2' </attribute> </mbean> Similarly you would have a two listeners (MDB's), one bound to Hello1, the other bound to Hello2. @ActivationConfigProperty(propertyName = "destination", propertyValue = "HelloQueue1"), public class FirstListener implements MessageListener { } @ActivationConfigProperty(propertyName = "destination", propertyValue = "HelloQueue2"), public class SecondListener implements MessageListener { } >>If no one is listening on that destination, messages will not be delivered.
>>This is the expected behavior. Once you deploy your MDB(s), the message(s) will
>>be delivered once they are deployed and activated.
>>Note, the messages don't go into a 'black hole', the are enqueued and will be
>>delivered when you deploy.'
This is the way it should work, but it's not. If the queue was not used never before, and the producer is the first user of the jms queue, messages are not delivered later when MDB is connected. Try it.
Second problem, two queues:
<mbean code="org.jboss.resource.deployment.AdminObject"
name="qpid.jca:name=qAA">
<attribute name="JNDIName">queue/AA</attribute>
<depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
<attribute name="Type">javax.jms.Destination</attribute>
<attribute name="Properties">
destinationAddress=direct://amq.direct//hello.aa
destinationType=queue
</attribute>
</mbean>
<mbean code="org.jboss.resource.deployment.AdminObject"
name="qpid.jca:name=qBB">
<attribute name="JNDIName">queue/BB</attribute>
<depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
<attribute name="Type">javax.jms.Destination</attribute>
<attribute name="Properties">
destinationAddress=direct://amq.direct//hello.bb
destinationType=queue
</attribute>
</mbean>
two MDBs:
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/AA"),
@ActivationConfigProperty(propertyName = "connectionURL", propertyValue = "amqp://guest:guest@/test?brokerlist='tcp://mrg01.mw.lab.eng.bos.redhat.com:5672'")
}, mappedName = "jms/firstMdb")
@ResourceAdapter("qpid-ra-0.10.rar")
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/BB"),
@ActivationConfigProperty(propertyName = "connectionURL", propertyValue = "amqp://guest:guest@/test?brokerlist='tcp://mrg01.mw.lab.eng.bos.redhat.com:5672'")
}, mappedName = "jms/secondMdb")
@ResourceAdapter("qpid-ra-0.10.rar")
One message send to queue/AA
two messages received, one by first MDB, second by second MDB. Is this OK?
'This is the way it should work, but it's not. If the queue was not used never before, and the producer is the first user of the jms queue, messages are not delivered later when MDB is connected. Try it.' I have and it works as expected. How are you verifying that the message is delivered? Log file, console? Do you have a system I can examine? 'two messages received, one by first MDB, second by second MDB. Is this OK?' Yes, this is the expected behavior. >>'two messages received, one by first MDB, second by second MDB. Is this OK?' >>Yes, this is the expected behavior. so, how to set queues that just mdb, that listen to the queue A received the message sent to queue A and other mdbs not receive it? I am setting up an example for you that shows exactly how to do it. I will attach it when complete or give you a pointer to the code. Also, for the two messages issue, I need to see the MDB's (there should be two) you are using. Ok, sorry, my eyes are a bit tired, I just saw the MDB's. All things considered, this 'should' work. I have a similar example working with no issues. The only thing I can think of is if you still have the old 'amq.direct' queue in the system, this might cause the problem. Did you try restart your broker to make sure that isn't there? Ok, I did some debugging, and I was finally able to reproduce the issue(s) that you are seeing. There are a few issues which can be easily resolved: 1)Make absolutely certain that you do not have a queue named amq.direct in your system. The original configuration for the example code could possible create an amq.direct queue (not exchange) and this causes real problems. Sometimes it's easy to forget, run qpid-stat -q often and verify that amq.direct is not there. If it is: qpid-config --force del queue amq.direct 2) If you make modifications to the qpid-jca-ds.xml file you MUST (no, this is not an option), either reboot your server, or redeploy your application. Note, this is NOT a Qpid JCA issue but is inherent in the JBoss EAP implementation, in other words, this is applicable for any adapter JDBC, JMS etc 3) You MUST provide a routing key for each destination: destinationAddress=direct://amq.direct//hello.aa?routingkey='hello.aa' destinationAddress=direct://amq.direct//hello.bb?routingkey='hello.bb' Here is what I am doing: Example: Here we have two queue's Hello and GoodBye <mbean code="org.jboss.resource.deployment.AdminObject" name="qpid.jca:name=HelloQueue"> <attribute name="JNDIName">HelloQueue</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends> <attribute name="Type">javax.jms.Destination</attribute> <attribute name="Properties"> destinationType=QUEUE destinationAddress=direct://amq.direct//hello.Queue?autodelete='true',routingkey='hello.Queue' </attribute> </mbean> @MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "HelloQueue"), @ActivationConfigProperty(propertyName = "connectionURL", propertyValue = "amqp://anonymous:@client/test?brokerlist='tcp://10.0.1.44:5672?sasl_mechs='ANONYMOUS''"), @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "10") }) public class QpidHelloListenerBean implements MessageListener <mbean code="org.jboss.resource.deployment.AdminObject" name="qpid.jca:name=GoodByeQueue"> <attribute name="JNDIName">GoodByeQueue</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends> <attribute name="Type">javax.jms.Destination</attribute> <attribute name="Properties"> destinationType=QUEUE destinationAddress=direct://amq.direct//goodbye.Queue?autodelete='true',routingkey='goodbye.Queue' </attribute> </mbean> @MessageDriven(activationConfig = { @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "destination", propertyValue = "GoodByeQueue"), @ActivationConfigProperty(propertyName = "connectionURL", propertyValue = "amqp://anonymous:@client/test?brokerlist='tcp://10.0.1.44:5672?sasl_mechs='ANONYMOUS''"), @ActivationConfigProperty(propertyName = "useLocalTx", propertyValue = "false"), @ActivationConfigProperty(propertyName = "maxSession", propertyValue = "10") }) public class QpidGoodByeListenerBean implements MessageListener start EAP: 14:26:51,613 INFO [AdminObject] Bound admin object 'org.apache.qpid.ra.admin.QpidDestinationProxy' at 'HelloQueue' 14:26:51,620 INFO [AdminObject] Bound admin object 'org.apache.qpid.ra.admin.QpidDestinationProxy' at 'GoodByeQueue' Send a message with client either web or RMI, here we are sending one message to the HelloQueue destination: ant -Dtarget.platform=jboss run-client [java] 1124 [main] DEBUG org.apache.qpid.jca.example.client.QpidTestClient - Sending 1 message(s) with content: Hello, World! with destination HelloQueue Server: 19:05:19,107 INFO [QpidHelloListenerBean] Received text message with contents Hello, World! at Sat Sep 03 19:05:19 EDT 2011 Note, only the HelloMDB received the message. Now, let's send one to the GoodByeQueue [java] 1170 [main] DEBUG org.apache.qpid.jca.example.client.QpidTestClient - Sending 1 message(s) with content: Hello, World! with destination GoodByeQueue 19:08:20,431 INFO [QpidGoodByeListenerBean] Received text message with contents Hello, World! at Sat Sep 03 19:08:20 EDT 2011 I am sure I can help you with this but I just wanted to show you the process and config I am using. Let know if I can help. I am attaching jca-examples.jar which is a rework of the JCA examples providing much more realistic examples for Queue/Topics, syntax etc. This should give better examples that what was previously provided. There is a BZ for this 735322, but I thought I would get the work out early so you can start taking a look. Alternatively you can check it out from GitHub as well: git://github.com/astitcher/qpid-jca.git branch is wp-BZ-735322 Created attachment 521454 [details]
Updated examples to aid in testing
>>3) You MUST provide a routing key for each destination:
>>destinationAddress=direct://amq.direct//hello.aa?routingkey='hello.aa'
>>destinationAddress=direct://amq.direct//hello.bb?routingkey='hello.bb'
That's exactly what we need to know, thanks, the second problem is resolved.
The first problem still remains:
Situatuin is:
clean server, no user queue visible in qpid-stat -q listing
I deploy this queue
<mbean code="org.jboss.resource.deployment.AdminObject"
name="qpid.jca:name=qAA">
<attribute name="JNDIName">queue/AA</attribute>
<depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
<attribute name="Type">javax.jms.Destination</attribute>
<attribute name="Properties">
destinationAddress=direct://amq.direct//hello.aa?autodelete='true',routingkey='hello.aa'
destinationType=queue
</attribute>
</mbean>
no change in qpid-stat -q listing
no line in qpid-printevents listing, so probably nothing happen on qpid side
deployed MRGConnectionFactory:
<mbean code="org.jboss.resource.deployment.AdminObject"
name="qpid.jca:name=MRGConnectionFactory">
<attribute name="JNDIName">MRGConnectionFactory</attribute>
<depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends>
<attribute name="Type">javax.jms.ConnectionFactory</attribute>
<attribute name="Properties">
connectionURL=amqp://guest:guest@/test?brokerlist='tcp://mrg01.mw.lab.eng.bos.redhat.com:5672'
</attribute>
</mbean>
one message sent to the queue with standalone client, (by getting MRGConnectionFactory from JNDI and getting destination queue/AA from JNDI)
no change in qpid-stat -q listing
listing of qpid-printevents show 2 lines:
Mon Sep 5 09:52:35 2011 INFO org.apache.qpid.broker:clientConnect broker=localhost:5672 rhost=10.16.88.240:5672-10.34.3.11:46540 user=guest@QPID
Mon Sep 5 09:52:36 2011 INFO org.apache.qpid.broker:clientDisconnect broker=localhost:5672 rhost=10.16.88.240:5672-10.34.3.11:46540 user=guest@QPID
simple MDB bind to queue/AA deployed, queue is now visible in qpid-stat -q:
queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind
===================================================================================================================================
...
hello.aa Y 0 0 0 0 0 0 15 2
...
one message sent with simple standalone client, this time is visible in qpid-stat -q, that message was sent.
Queues
queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind
===================================================================================================================================
...
hello.aa Y 0 1 1 0 40 40 15 2
...
Everything has default configuration, nothing special is used, /etc/qpidd.conf contains just 3 lines:
cluster-mechanism=ANONYMOUS
truncate=yes
auth=no
Can you run a trace on the Broker? Something along the lines of qpidd --log-enable info+ --log-enable trace+:amqp_0_10 I am going to try and reproduce this on my end. I just tried reproducing this and I cannot. Did you restart your Broker and make sure everything was clean before running the test? I started from a completely clean system, and again, I can not reproduce this issue. Created attachment 521473 [details]
Trace log from server
Log is attached, sequence of activities was:
start qpidd
deploy queue/AA
send message with standalone client
deploy MDB bound to queue/AA
send message with standalone client
Yes, restarted broker, everything was clean. Info for package qpid-cpp-server Installed Packages Name : qpid-cpp-server Arch : x86_64 Version : 0.10 Release : 3.el5 Size : 3.3 M Repo : installed Summary : An AMQP message broker daemon URL : http://qpid.apache.org License : ASL 2.0 Description: A message broker daemon that receives stores and routes messages using : the open AMQP messaging protocol. I can ask for update to current version. start qpidd deploy queue/AA send message with standalone client deploy MDB bound to queue/AA send message with standalone client Ok, this is a different start-qpidd --> No problems here clean system deploy queue/AA --> Here is the issue, the queue is not created by default In fact, I don't believe there is a way to create a destination on deployment using the BURL syntax as this is an ADDR option only from what I know. Rajith would better be able to answer this. However, if this is indeed the case, they we are going to need to get https://bugzilla.redhat.com/show_bug.cgi?id=700494 in place before we support this. Otherwise, you will have to create the destinations manually if you want to use the older syntax. Again, this isn't supported by BURL, I confirmed this with the JMS client team this morning. So, we will have to upgrade the adapter to support this. Ok, we have temporary workaround, which let us do testing, but for customers it will be definitely necessary to have it there. Thanks for investigation. No problem, again, I don't necessarily disagree with you. We can treat it as a feature request moving forward. Thanks for your work on this one, I know it wasn't easy. if this is a feature request please change the target release to 2.2 I just submitted the latest build of the Qpid JCA adapter which has the fix to use ADDR syntax for destinations. This should address: https://bugzilla.redhat.com/show_bug.cgi?id=700494 and allow you to continue testing now that you can use ADDR syntax with the adapter. I'm a little confused by this bug report, but are we saying that fixing this bug is dependent on fixing Bug 700494? If so we should make this bug dependent on that one. Adding dependency on Bug 700494 ADDR syntax included as part of the new adapter build. This should be addressed with the new code and Bug 700494. This has been fixed in package qpid-java-jca-0.10-10 Setting to verified for the second time. |