| Author |
Message
|
| radiatejava |
 Posted: Thu Nov 29, 2007 11:19 pm Post subject: |
 |
|
Novice
Joined: 21 Nov 2007
Posts: 17
|
| radiatejava wrote: |
| No luck yet to me.. I am yet to see a TextMessage by the subscriber when the publisher puts a TextMessage. Thanks in advance again. |
|
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Nov 30, 2007 1:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You now seem to have 2 threads running on the same problem:
http://www.mqseries.net/phpBB2/viewtopic.php?t=40802
Have you considered following the advice given in either or indeed both?
Have you used the references given? What changes have you made, and what was your reasoning? What happened as a result?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| radiatejava |
| Posted: Wed Dec 05, 2007 3:50 am Post subject: |
|
|
Novice
Joined: 21 Nov 2007
Posts: 17
|
Actually, upon investigation, found that the middleware app that was publishing the msg to the topic was marking the topic as non-JMS client (using the setTargetClient(int)) API on the condition if msg source was non-JMS (it was non-JMS as msg.getJMSDestination() came as null and hence this destination could not be verified whether it was JMS client or not using the dest.getTargetClient API)). This caused the msg received being a BytesMessage instead of TextMessage. My application is this:
non-JMS Java client -> MQ JMS queue -> middleware -> MQ JMS topic -> JMS Receiver
Can someone point me to some sample code on how to write a java client incorporating RFH2 headers so that the middleware treats the source as JMS.
Sorry for causing the confusions.
Thanks
-Satish |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 05, 2007 4:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| radiatejava wrote: |
| Can someone point me to some sample code on how to write a java client incorporating RFH2 headers |
A Java client that incorporates RFH2 headers is a JMS client!
There are samples with the product, and also on www.capitalware.biz/mqseries
A non-Java client that wants to include RFH2/JMS headers should consider using the XMS libraries.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 05, 2007 4:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| radiatejava wrote: |
Actually, upon investigation, found that the middleware app that was publishing the msg to the topic was marking the topic as non-JMS client (using the setTargetClient(int)) API on the condition if msg source was non-JMS (it was non-JMS as msg.getJMSDestination() came as null and hence this destination could not be verified whether it was JMS client or not using the dest.getTargetClient API)). This caused the msg received being a BytesMessage instead of TextMessage. My application is this:
non-JMS Java client -> MQ JMS queue -> middleware -> MQ JMS topic -> JMS Receiver
Can someone point me to some sample code on how to write a java client incorporating RFH2 headers so that the middleware treats the source as JMS.
Sorry for causing the confusions.
Thanks
-Satish |
| Quote: |
| This caused the msg received being a BytesMessage instead of TextMessage. |
This assumption is completely wrong.
What I suspect happened is that the original sender did not set the format to MQFMT_STRING and as such the application received a BytesMessage and published a BytesMessage.
Worst case scenario the application receives a TextMessage and publishes a BytesMessage but that would then be a problem for the app.
You have also to take into account the XML spec. The latest ajax stuff gives the XML message as BytesMessage because of multipart mime and attachments.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| radiatejava |
| Posted: Wed Dec 05, 2007 9:50 pm Post subject: |
|
|
Novice
Joined: 21 Nov 2007
Posts: 17
|
Let me make clear:
- The middleware app receives TextMessage and pulishes publishes TextMessage to the MQ JMS topic. We have access to the middleware src code and did debugging on this. In my first post, I had given the printed the msg being sent.
- The non-JMS client does set mqMessage.format = MQC.MQFMT_STRING but it is not in RFH2 format
- No XML msgs being sent or received here.
Middleware app used to this with the received JMS message:
public boolean isNonJMSSender(Message recvdMsg) {
if(recvdMsg.getJMSDestination() != null) {
if(recvdMsg.getJMSDestination()..getTargetClient() ==
JMSC.MQJMS_CLIENT_JMS_COMPLIANT) {
return false;
}
}
return true;
}
Since recvdMsg.getJMSDestination() came as null, it assumed that the sender was non-JMS and hence at the time of publishing the msg to the topic, it did topic.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ). This caused the receiver program to receive BytesMessage and replyTo field were missing.
As per java api doc for javax.jms.Message.getJMSDestination() - "When a message is sent, this field is ignored. After completion of the send or publish method, the field holds the destination specified by the method. When a message is received, its JMSDestination value must be equivalent to the value assigned when it was sent."
When I use a JMS client to send the msg, msg.getJMSDestination() does return the destination the msg was sent to, though I do not set it explicitely by doing msg.setJMSDestination() and the java doc holds true.
So my next question is, if I send the initial msg to the MQ JMS queue using the nonJMS cient but in RFH2 format without setting the JMS destination, will msg.getJMSDestination() still return null? or will it give me the actual correct value as in case when the JMS client is used ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 06, 2007 1:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| radiatejava wrote: |
| So my next question is, if I send the initial msg to the MQ JMS queue using the nonJMS cient but in RFH2 format without setting the JMS destination, will msg.getJMSDestination() still return null? or will it give me the actual correct value as in case when the JMS client is used ? |
That will, I imagine, depend on if the sender included and set the JMS destination information when it was building the RFH2 header.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 06, 2007 5:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Depending on your JMS client....
Remember that in V6 the default is targetClientMatching(true)....
Now what you have is a case where evidently you receive a non JMS message and do not want to match the target client.
Did you considered creating a different qcf/tcf with the same information but setting targetClientMatching(false) ??
Have some fun trying it out   
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
