[mule-user] MQ Series and RFH2 Heading

[YQuinby]

Hi,

We are using Mule to send JMS messages via IBM MQ Series.

I have the messages arriving on the queues, but we need to remove the JMS RFH2 header from our messages.

According to IBM documentation, this can be done by appending targetClient=1 to the end of a URI.

eg.

jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1

where 1=MQ and 0=JMS

However, this doesn't seem to be working for us.

Has anyone else who uses IBM MQ Series come across this issue before?

Thanks.

===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, ([phone] or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

[Tim Berkeley-2]

Hi,

I think that your problem is that the mule url is interpreting the ?targetClient=1 parameter and it is never getting to MQ as part of the MQ queue URL.

Is there a way of escaping the ? in the mule endpoint address? Maybe there should be.

If you have a JNDI server you could set the queues up here and set the property.

You may also be able to use the Spring org.springframework.mock.jndi.SimpleNamingContextBuilder to create a local JNDI context. I have used this for data sources but not for setting up JMS.

Some other JNDI options are...
http://oocjndi.sourceforge.net/
http://www.osjava.org/simple-jndi/

Though I have not used either of these.

Hope this helps.

Tim


-----Original Message-----
From: YQuinby@... [mailto:YQuinby@...]
Sent: 17 November 2005 01:03
To: user@...
Subject: [mule-user] MQ Series and RFH2 Heading



Hi,

We are using Mule to send JMS messages via IBM MQ Series.

I have the messages arriving on the queues, but we need to remove the JMS RFH2 header from our messages.

According to IBM documentation, this can be done by appending targetClient=1 to the end of a URI.

eg.

jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1

where 1=MQ and 0=JMS

However, this doesn't seem to be working for us.

Has anyone else who uses IBM MQ Series come across this issue before?

Thanks.




===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s).
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by
telephone, ([phone] or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.


**********************************************************************
This e-mail is confidential and should not be used by anyone who is not the original intended recipient.
If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism.
The Book People Limited cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of The Book People Limited.
We will not accept any responsibility for viruses, so please scan all attachments.
**********************************************************************

[YQuinby]

Hi Tim,

Yes, we figured that out yesterday. The endpoint URI gets chopped into an address and parameters. When the JMSConnector creates the queue destination, just the endpoint URL address is used, not the parameters.

I couldn't find a way to escape the "?". But there seemed to be a lot of chatter about endpoint URIs, so maybe that's something that will be looked at in the future.

I tried changing the source in the JMS11Support class to cast the Queue interface to an MQQueue implementation, then manually set the target client.

eg.

QueueSession qSession = (QueueSession)session;
MQQueue mQueue = (MQQueue)qSession.createQueue(name);
mQueue.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);


And that did the trick. For numerous reasons, that's not an award winning solution. I will take a look at a JNDI solution.

Thanks for your help.

Yvette

"Tim Berkeley" <tberkeley@...>

17/11/2005 06:05 PM

Please respond to
user@...

To	<user@...>
cc
Subject	RE: [mule-user] MQ Series and RFH2 Heading

Hi,

I think that your problem is that the mule url is interpreting the ?targetClient=1 parameter and it is never getting to MQ as part of the MQ queue URL.

Is there a way of escaping the ? in the mule endpoint address? Maybe there should be.

If you have a JNDI server you could set the queues up here and set the property.

You may also be able to use the Spring org.springframework.mock.jndi.SimpleNamingContextBuilder to create a local JNDI context. I have used this for data sources but not for setting up JMS.

Some other JNDI options are...
http://oocjndi.sourceforge.net/
http://www.osjava.org/simple-jndi/

Though I have not used either of these.

Hope this helps.

Tim


-----Original Message-----
From: YQuinby@... [mailto:YQuinby@...]
Sent: 17 November 2005 01:03
To: user@...
Subject: [mule-user] MQ Series and RFH2 Heading



Hi,

We are using Mule to send JMS messages via IBM MQ Series.

I have the messages arriving on the queues, but we need to remove the JMS RFH2 header from our messages.

According to IBM documentation, this can be done by appending targetClient=1 to the end of a URI.

eg.

jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1

where 1=MQ and 0=JMS

However, this doesn't seem to be working for us.

Has anyone else who uses IBM MQ Series come across this issue before?

Thanks.




===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s).
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by
telephone, ([phone] or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.


**********************************************************************
This e-mail is confidential and should not be used by anyone who is not the original intended recipient.
If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism.
The Book People Limited cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of The Book People Limited.
We will not accept any responsibility for viruses, so please scan all attachments.
**********************************************************************

===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s). 
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by 
telephone, ([phone] or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

[Biva]

Hello
one year after, I'm facing the same problem.... :-(
Can anyone help me to get rid of this RFH2 header?

Thank you
Eric

YQuinby wrote:

Hi,

We are using Mule to send JMS messages via IBM MQ Series.

I have the messages arriving on the queues, but we need to remove the JMS
RFH2 header from our messages.

According to IBM documentation, this can be done by appending
targetClient=1 to the end of a URI.

eg.

jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1

where 1=MQ and 0=JMS

However, this doesn't seem to be working for us.

Has anyone else who uses IBM MQ Series come across this issue before?

Thanks.

===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s).
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by
telephone, ([phone] or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

[Andrew Perepelytsya]

Eric,

Have you tried the workaround Yvette had posted? It worked for him.

Andrew

On 11/29/06, Biva <eric.biva@...> wrote:

Hello
one year after, I'm facing the same problem.... :-(
Can anyone help me to get rid of this RFH2 header?

Thank you
Eric


YQuinby wrote:

>
> Hi,
>
> We are using Mule to send JMS messages via IBM MQ Series.
>
> I have the messages arriving on the queues, but we need to remove the JMS
> RFH2 header from our messages.
>
> According to IBM documentation, this can be done by appending
> targetClient=1 to the end of a URI.
>
> eg.
>
> jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1
>
> where 1=MQ and 0=JMS
>
> However, this doesn't seem to be working for us.
>
> Has anyone else who uses IBM MQ Series come across this issue before?
>
> Thanks.
>

> ===================================================

> HBF Health Funds Inc. a registered organisation under the National Health
> Act
> HBF Insurance Pty Ltd ACN  009 268 277
> This email is a confidential communication intended only for the named
> Addressee(s).
> If you are not that person any disclosure, copying, distribution or use of
> this email
> or the information in it is prohibited. Please notify us immediately by
> telephone, ([phone] or return email and delete this email.
> The views in this email may be personal to the author and not those of
> HBF.
>
>

--
View this message in context: http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7603318
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Biva]

Hi Andrew
not yet, I was wondering if, one year later, a real solution was found. But it seems that it is not the case... unfortunately.
I will try the Yvette's workaround.

Regards
Eric

Andrew Perepelytsya wrote:

Eric,

Have you tried the workaround Yvette had posted? It worked for him.

Andrew

On 11/29/06, Biva <[e-mail]> wrote:
>
>
> Hello
> one year after, I'm facing the same problem.... :-(
> Can anyone help me to get rid of this RFH2 header?
>
> Thank you
> Eric
>
>
> YQuinby wrote:
> >
> > Hi,
> >
> > We are using Mule to send JMS messages via IBM MQ Series.
> >
> > I have the messages arriving on the queues, but we need to remove the
> JMS
> > RFH2 header from our messages.
> >
> > According to IBM documentation, this can be done by appending
> > targetClient=1 to the end of a URI.
> >
> > eg.
> >
> > jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1
> >
> > where 1=MQ and 0=JMS
> >
> > However, this doesn't seem to be working for us.
> >
> > Has anyone else who uses IBM MQ Series come across this issue before?
> >
> > Thanks.
> >
> > ===================================================
> > HBF Health Funds Inc. a registered organisation under the National
> Health
> > Act
> > HBF Insurance Pty Ltd ACN  009 268 277
> > This email is a confidential communication intended only for the named
> > Addressee(s).
> > If you are not that person any disclosure, copying, distribution or use
> of
> > this email
> > or the information in it is prohibited. Please notify us immediately by
> > telephone, ([phone] or return email and delete this email.
> > The views in this email may be personal to the author and not those of
> > HBF.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7603318
> Sent from the Mule - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

[Biva]

Hello
I tried and ... it works ;o)
So this is THE solution to specify that your message is sent to a non-JMS receiver (WebSphere MQ in my case).

Best regards
Eric


Hi Andrew
not yet, I was wondering if, one year later, a real solution was found. But it seems that it is not the case... unfortunately.
I will try the Yvette's workaround.

Regards
Eric

Andrew Perepelytsya wrote:

Eric,

Have you tried the workaround Yvette had posted? It worked for him.

Andrew

On 11/29/06, Biva <[e-mail]> wrote:
>
>
> Hello
> one year after, I'm facing the same problem.... :-(
> Can anyone help me to get rid of this RFH2 header?
>
> Thank you
> Eric
>
>
> YQuinby wrote:
> >
> > Hi,
> >
> > We are using Mule to send JMS messages via IBM MQ Series.
> >
> > I have the messages arriving on the queues, but we need to remove the
> JMS
> > RFH2 header from our messages.
> >
> > According to IBM documentation, this can be done by appending
> > targetClient=1 to the end of a URI.
> >
> > eg.
> >
> > jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1
> >
> > where 1=MQ and 0=JMS
> >
> > However, this doesn't seem to be working for us.
> >
> > Has anyone else who uses IBM MQ Series come across this issue before?
> >
> > Thanks.
> >
> > ===================================================
> > HBF Health Funds Inc. a registered organisation under the National
> Health
> > Act
> > HBF Insurance Pty Ltd ACN  009 268 277
> > This email is a confidential communication intended only for the named
> > Addressee(s).
> > If you are not that person any disclosure, copying, distribution or use
> of
> > this email
> > or the information in it is prohibited. Please notify us immediately by
> > telephone, ([phone] or return email and delete this email.
> > The views in this email may be personal to the author and not those of
> > HBF.
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7603318
> Sent from the Mule - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

[Andrew Perepelytsya]

Eric,

The real solution I'd like to implement one day is to provide vendor-specific JMS connectors, defaulting to vendor-specific support classes and properties. Yeah, it's not that all compatible in the real world.

The only factor slowing down it's implementation is it has to use reflection, and then cache the class instantiation results for performance reasons, thus a little bit more involved than just some properties defaults.

Andrew

On 11/30/06, Biva <eric.biva@...> wrote:

Hello
I tried and ... it works ;o)
So this is THE solution to specify that your message is sent to a non-JMS
receiver (WebSphere MQ in my case).

Best regards
Eric


Biva wrote:

>
> Hi Andrew
> not yet, I was wondering if, one year later, a real solution was found.
> But it seems that it is not the case... unfortunately.
> I will try the Yvette's workaround.
>
> Regards
> Eric
>
>
> Andrew Perepelytsya wrote:
>>
>> Eric,
>>
>> Have you tried the workaround Yvette had posted? It worked for him.
>>
>> Andrew
>>
>> On 11/29/06, Biva < eric.biva@...> wrote:
>>>
>>>
>>> Hello
>>> one year after, I'm facing the same problem.... :-(
>>> Can anyone help me to get rid of this RFH2 header?
>>>
>>> Thank you
>>> Eric
>>>
>>>
>>> YQuinby wrote:
>>> >
>>> > Hi,
>>> >
>>> > We are using Mule to send JMS messages via IBM MQ Series.
>>> >
>>> > I have the messages arriving on the queues, but we need to remove the
>>> JMS
>>> > RFH2 header from our messages.
>>> >
>>> > According to IBM documentation, this can be done by appending
>>> > targetClient=1 to the end of a URI.
>>> >
>>> > eg.
>>> >
>>> > jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1
>>> >
>>> > where 1=MQ and 0=JMS
>>> >
>>> > However, this doesn't seem to be working for us.
>>> >
>>> > Has anyone else who uses IBM MQ Series come across this issue before?
>>> >
>>> > Thanks.
>>> >
>>> > ===================================================
>>> > HBF Health Funds Inc. a registered organisation under the National
>>> Health
>>> > Act
>>> > HBF Insurance Pty Ltd ACN  009 268 277
>>> > This email is a confidential communication intended only for the named
>>> > Addressee(s).
>>> > If you are not that person any disclosure, copying, distribution or
>>> use
>>> of
>>> > this email
>>> > or the information in it is prohibited. Please notify us immediately
>>> by
>>> > telephone, ([phone] or return email and delete this email.
>>> > The views in this email may be personal to the author and not those of
>>> > HBF.
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7603318
>>> Sent from the Mule - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7617225
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list please visit:

     http://xircles.codehaus.org/manage_email

[Niels]

Hello,

I’m facing the same problem: sending a Websphere MQ JMS messages  to a non jms client.

My workaround was to make a vendor specific JmsConnector. I subclassed JmsConnector and I overrode the method doConnect as follows.

        public void doConnect() throws ConnectException {
                super.doConnect();
                this.setJmsSupport( new WebSphereMQSupport(this, this.getJndiContext(), false,
                   false));
        }

Second I implemented WebSphereMQSupport which is a subclass Jms102bSupport  (in my case, but it could be as well Jms11Support). I overrode the method createDestination as follows.

        public Destination createDestination(Session session, String name,
                        boolean topic) throws JMSException {
                Destination destination = super.createDestination(session, name, topic);
                ((MQDestination) destination)
                                .setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);

                return destination;
        }

Andrew Perepelytsya wrote:

Eric,

The real solution I'd like to implement one day is to provide
vendor-specific JMS connectors, defaulting to vendor-specific support
classes and properties. Yeah, it's not that all compatible in the real
world.

The only factor slowing down it's implementation is it has to use
reflection, and then cache the class instantiation results for performance
reasons, thus a little bit more involved than just some properties defaults.

Andrew

On 11/30/06, Biva <[e-mail]> wrote:
>
>
> Hello
> I tried and ... it works ;o)
> So this is THE solution to specify that your message is sent to a non-JMS
> receiver (WebSphere MQ in my case).
>
> Best regards
> Eric
>
>
> Biva wrote:
> >
> > Hi Andrew
> > not yet, I was wondering if, one year later, a real solution was found.
> > But it seems that it is not the case... unfortunately.
> > I will try the Yvette's workaround.
> >
> > Regards
> > Eric
> >
> >
> > Andrew Perepelytsya wrote:
> >>
> >> Eric,
> >>
> >> Have you tried the workaround Yvette had posted? It worked for him.
> >>
> >> Andrew
> >>
> >> On 11/29/06, Biva <[e-mail]> wrote:
> >>>
> >>>
> >>> Hello
> >>> one year after, I'm facing the same problem.... :-(
> >>> Can anyone help me to get rid of this RFH2 header?
> >>>
> >>> Thank you
> >>> Eric
> >>>
> >>>
> >>> YQuinby wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > We are using Mule to send JMS messages via IBM MQ Series.
> >>> >
> >>> > I have the messages arriving on the queues, but we need to remove
> the
> >>> JMS
> >>> > RFH2 header from our messages.
> >>> >
> >>> > According to IBM documentation, this can be done by appending
> >>> > targetClient=1 to the end of a URI.
> >>> >
> >>> > eg.
> >>> >
> >>> > jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1
> >>> >
> >>> > where 1=MQ and 0=JMS
> >>> >
> >>> > However, this doesn't seem to be working for us.
> >>> >
> >>> > Has anyone else who uses IBM MQ Series come across this issue
> before?
> >>> >
> >>> > Thanks.
> >>> >
> >>> > ===================================================
> >>> > HBF Health Funds Inc. a registered organisation under the National
> >>> Health
> >>> > Act
> >>> > HBF Insurance Pty Ltd ACN  009 268 277
> >>> > This email is a confidential communication intended only for the
> named
> >>> > Addressee(s).
> >>> > If you are not that person any disclosure, copying, distribution or
> >>> use
> >>> of
> >>> > this email
> >>> > or the information in it is prohibited. Please notify us immediately
> >>> by
> >>> > telephone, ([phone] or return email and delete this email.
> >>> > The views in this email may be personal to the author and not those
> of
> >>> > HBF.
> >>> >
> >>> >
> >>>
> >>> --
> >>> View this message in context:
> >>>
> http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7603318
> >>> Sent from the Mule - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe from this list please visit:
> >>>
> >>>     http://xircles.codehaus.org/manage_email
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7617225
> Sent from the Mule - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

[Andrew Perepelytsya]

Hi Niels,

We have started to branch out vendor specifics in dedicated JMS connectors, it's targeted for Mule 1.4 (already in trunk). At the moment it's only an emerging concept in Mule, not too many settings are yet tweaked (though some critical have been).

I think we'll create a WebsphereMqNativeJmsConnector to provide better means of supporting native WMQ connections and configuration (watch http://mule.mulesource.org/jira/browse/MULE-1520 for a start). If you have some other tweaks which were a pain to deal with and we could try simplify those, feel free to comment on the issue (can be renamed if need to).

Andrew

On 3/21/07, Niels <niels.boyen@...> wrote:

Hello,

I'm facing the same problem: sending a Websphere MQ JMS messages  to a non
jms client.

My workaround was to make a vendor specific JmsConnector. I subclassed
JmsConnector and I overrode the method doConnect as follows.

        public void doConnect() throws ConnectException {
                super.doConnect();
                this.setJmsSupport( new WebSphereMQSupport(this, this.getJndiContext(),
false,
                   false));
        }

Second I implemented WebSphereMQSupport which is a subclass Jms102bSupport
(in my case, but it could be as well Jms11Support). I overrode the method
createDestination as follows.

        public Destination createDestination(Session session, String name,
                        boolean topic) throws JMSException {
                Destination destination = super.createDestination(session, name, topic);
                ((MQDestination) destination)
                                .setTargetClient( JMSC.MQJMS_CLIENT_NONJMS_MQ);

                return destination;
        }


Andrew Perepelytsya wrote:

>
> Eric,
>
> The real solution I'd like to implement one day is to provide
> vendor-specific JMS connectors, defaulting to vendor-specific support
> classes and properties. Yeah, it's not that all compatible in the real
> world.
>
> The only factor slowing down it's implementation is it has to use
> reflection, and then cache the class instantiation results for performance
> reasons, thus a little bit more involved than just some properties
> defaults.
>
> Andrew
>
> On 11/30/06, Biva < eric.biva@...> wrote:
>>
>>
>> Hello
>> I tried and ... it works ;o)
>> So this is THE solution to specify that your message is sent to a non-JMS
>> receiver (WebSphere MQ in my case).
>>
>> Best regards
>> Eric
>>
>>
>> Biva wrote:
>> >
>> > Hi Andrew
>> > not yet, I was wondering if, one year later, a real solution was found.
>> > But it seems that it is not the case... unfortunately.
>> > I will try the Yvette's workaround.
>> >
>> > Regards
>> > Eric
>> >
>> >
>> > Andrew Perepelytsya wrote:
>> >>
>> >> Eric,
>> >>
>> >> Have you tried the workaround Yvette had posted? It worked for him.
>> >>
>> >> Andrew
>> >>
>> >> On 11/29/06, Biva <eric.biva@...> wrote:
>> >>>
>> >>>
>> >>> Hello
>> >>> one year after, I'm facing the same problem.... :-(
>> >>> Can anyone help me to get rid of this RFH2 header?
>> >>>
>> >>> Thank you
>> >>> Eric
>> >>>
>> >>>
>> >>> YQuinby wrote:
>> >>> >
>> >>> > Hi,
>> >>> >
>> >>> > We are using Mule to send JMS messages via IBM MQ Series.
>> >>> >
>> >>> > I have the messages arriving on the queues, but we need to remove
>> the
>> >>> JMS
>> >>> > RFH2 header from our messages.
>> >>> >
>> >>> > According to IBM documentation, this can be done by appending
>> >>> > targetClient=1 to the end of a URI.
>> >>> >

>> >>> > eg.
>> >>> >
>> >>> > jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1
>> >>> >
>> >>> > where 1=MQ and 0=JMS
>> >>> >

>> >>> > However, this doesn't seem to be working for us.
>> >>> >
>> >>> > Has anyone else who uses IBM MQ Series come across this issue
>> before?
>> >>> >
>> >>> > Thanks.
>> >>> >
>> >>> > ===================================================
>> >>> > HBF Health Funds Inc. a registered organisation under the National
>> >>> Health
>> >>> > Act
>> >>> > HBF Insurance Pty Ltd ACN  009 268 277
>> >>> > This email is a confidential communication intended only for the
>> named
>> >>> > Addressee(s).
>> >>> > If you are not that person any disclosure, copying, distribution or
>> >>> use
>> >>> of

>> >>> > this email

>> >>> > or the information in it is prohibited. Please notify us
>> immediately
>> >>> by
>> >>> > telephone, ([phone] or return email and delete this
>> email.
>> >>> > The views in this email may be personal to the author and not those
>> of
>> >>> > HBF.
>> >>> >
>> >>> >
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>>
>> http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7603318
>> >>> Sent from the Mule - User mailing list archive at Nabble.com.
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe from this list please visit:
>> >>>
>> >>>     http://xircles.codehaus.org/manage_email
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a7617225
>> Sent from the Mule - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
>

--
View this message in context: http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a9592436
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Justin Rowe]

We have figured out another way of doing this that doesn't require any change to existing Mule code, but you do need to create a custom JMS provider (mqjms in the example below). By creating custom EndpontBuilder.setEndpoint you can pass parameters (targetClient, priority etc) directly through to MQ (which understands queue:/ URI protocol, refer to MQ documentation), but this then precludes use of these parameters by Mule (e.g. to pass login credentials, which can in any case be done on the connector).

public class MQJmsEndpointBuilder  extends AbstractEndpointBuilder {

   protected void setEndpoint(URI uri, Properties props) throws MalformedEndpointException {
       address = "queue:/" + uri.getSchemeSpecificPart();
       endpointName = "jms";
   }
}

public class MQJmsConnector extends JmsConnector {
   public String getProtocol() {
      return "mqjms";
   }
}

Then put mqjms.properties with similar to following contents under META-INF/services/org/mule/providers:

connector=com.rabo.si.core.providers.jms.MQJmsConnector
dispatcher.factory=org.mule.providers.jms.JmsMessageDispatcherFactory
message.receiver=org.mule.providers.jms.JmsMessageReceiver
transacted.message.receiver=org.mule.providers.jms.TransactedJmsMessageReceiver
message.adapter=org.mule.providers.jms.JmsMessageAdapter
inbound.transformer=org.mule.providers.jms.transformers.JMSMessageToObject
response.transformer=org.mule.providers.jms.transformers.ObjectToJMSMessage
outbound.transformer=org.mule.providers.jms.transformers.ObjectToJMSMessage
#service.error=Cannot create Jms connector using current service descriptor
endpoint.builder=com.rabo.si.core.endpoints.MQJmsEndpointBuilder


- Justin

YQuinby wrote:

Hi Tim,

Yes, we figured that out yesterday. The endpoint URI gets chopped into an
address and parameters. When the JMSConnector creates the queue
destination, just the endpoint URL address is used, not the parameters.

I couldn't find a way to escape the "?". But there seemed to be a lot of
chatter about endpoint URIs, so maybe that's something that will be looked
at in the future.

I tried changing the source in the JMS11Support class to cast the Queue
interface to an MQQueue implementation, then manually set the target
client.

eg.

QueueSession qSession = (QueueSession)session;
MQQueue mQueue = (MQQueue)qSession.createQueue(name);
mQueue.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);


And that did the trick. For numerous reasons, that's not an award winning
solution. I will take a look at a JNDI solution.

Thanks for your help.

Yvette






"Tim Berkeley" <[e-mail]>
17/11/2005 06:05 PM
Please respond to
[e-mail]


To
<[e-mail]>
cc

Subject
RE: [mule-user] MQ Series and RFH2 Heading






Hi,

I think that your problem is that the mule url is interpreting the
?targetClient=1 parameter and it is never getting to MQ as part of the MQ
queue URL.

Is there a way of escaping the ? in the mule endpoint address? Maybe there
should be.

If you have a JNDI server you could set the queues up here and set the
property.

You may also be able to use the Spring
org.springframework.mock.jndi.SimpleNamingContextBuilder to create a local
JNDI context. I have used this for data sources but not for setting up
JMS.

Some other JNDI options are...
http://oocjndi.sourceforge.net/
http://www.osjava.org/simple-jndi/

Though I have not used either of these.

Hope this helps.

Tim


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: 17 November 2005 01:03
To: [e-mail]
Subject: [mule-user] MQ Series and RFH2 Heading



Hi,

We are using Mule to send JMS messages via IBM MQ Series.

I have the messages arriving on the queues, but we need to remove the JMS
RFH2 header from our messages.

According to IBM documentation, this can be done by appending
targetClient=1 to the end of a URI.

eg.

jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1

where 1=MQ and 0=JMS

However, this doesn't seem to be working for us.

Has anyone else who uses IBM MQ Series come across this issue before?

Thanks.




===================================================
HBF Health Funds Inc. a registered organisation under the National Health
Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named
Addressee(s).
If you are not that person any disclosure, copying, distribution or use of
this email
or the information in it is prohibited. Please notify us immediately by
telephone, ([phone] or return email and delete this email.
The views in this email may be personal to the author and not those of
HBF.


**********************************************************************
This e-mail is confidential and should not be used by anyone who is not
the original intended recipient.
If you have received this e-mail in error please inform the sender and
delete it from your mailbox or any other storage mechanism.
The Book People Limited cannot accept liability for any statements made
which are clearly the sender's own and not expressly made on behalf of The
Book People Limited.
We will not accept any responsibility for viruses, so please scan all
attachments.
**********************************************************************




===================================================
HBF Health Funds Inc. a registered organisation under the National Health Act
HBF Insurance Pty Ltd ACN  009 268 277
This email is a confidential communication intended only for the named Addressee(s).
If you are not that person any disclosure, copying, distribution or use of this email
or the information in it is prohibited. Please notify us immediately by
telephone, ([phone] or return email and delete this email.
The views in this email may be personal to the author and not those of HBF.

[Andrew Perepelytsya]

Justin,

A less intrusive approach is to use serviceOverrides to customize the builder. However, if there's a potential to have more fixes like that, it makes sense to customize the protocol as you did.

Andrew

On 6/1/07, Justin Rowe <justin.rowe@...> wrote:

We have figured out another way of doing this that doesn't require any change
to existing Mule code, but you do need to create a custom JMS provider
(mqjms in the example below). By creating custom EndpontBuilder.setEndpoint
you can pass parameters (targetClient, priority etc) directly through to MQ
(which understands queue:/ URI protocol, refer to MQ documentation), but
this then precludes use of these parameters by Mule (e.g. to pass login
credentials, which can in any case be done on the connector).

public class MQJmsEndpointBuilder  extends AbstractEndpointBuilder {

   protected void setEndpoint(URI uri, Properties props) throws
MalformedEndpointException {
       address = "queue:/" + uri.getSchemeSpecificPart();
       endpointName = "jms";
   }
}

public class MQJmsConnector extends JmsConnector {
   public String getProtocol() {
      return "mqjms";
   }
}

Then put mqjms.properties with similar to following contents under
META-INF/services/org/mule/providers:

connector=com.rabo.si.core.providers.jms.MQJmsConnector
dispatcher.factory=org.mule.providers.jms.JmsMessageDispatcherFactory
message.receiver=org.mule.providers.jms.JmsMessageReceiver
transacted.message.receiver=org.mule.providers.jms.TransactedJmsMessageReceiver
message.adapter=org.mule.providers.jms.JmsMessageAdapter
inbound.transformer=org.mule.providers.jms.transformers.JMSMessageToObject
response.transformer=org.mule.providers.jms.transformers.ObjectToJMSMessage
outbound.transformer=org.mule.providers.jms.transformers.ObjectToJMSMessage
#service.error=Cannot create Jms connector using current service descriptor
endpoint.builder=com.rabo.si.core.endpoints.MQJmsEndpointBuilder


- Justin


YQuinby wrote:
>
> Hi Tim,
>

> Yes, we figured that out yesterday. The endpoint URI gets chopped into an
> address and parameters. When the JMSConnector creates the queue
> destination, just the endpoint URL address is used, not the parameters.
>
> I couldn't find a way to escape the "?". But there seemed to be a lot of
> chatter about endpoint URIs, so maybe that's something that will be looked
> at in the future.
>
> I tried changing the source in the JMS11Support class to cast the Queue
> interface to an MQQueue implementation, then manually set the target
> client.
>
> eg.
>
> QueueSession qSession = (QueueSession)session;
> MQQueue mQueue = (MQQueue)qSession.createQueue(name);
> mQueue.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ);
>
>
> And that did the trick. For numerous reasons, that's not an award winning
> solution. I will take a look at a JNDI solution.
>
> Thanks for your help.
>
> Yvette
>
>
>
>
>
>
> "Tim Berkeley" <tberkeley@...>
> 17/11/2005 06:05 PM
> Please respond to
> user@...
>
>
> To
> <user@...>
> cc
>
> Subject
> RE: [mule-user] MQ Series and RFH2 Heading
>
>
>
>
>
>
> Hi,
>
> I think that your problem is that the mule url is interpreting the
> ?targetClient=1 parameter and it is never getting to MQ as part of the MQ
> queue URL.
>
> Is there a way of escaping the ? in the mule endpoint address? Maybe there
> should be.
>

> If you have a JNDI server you could set the queues up here and set the

> property.
>
> You may also be able to use the Spring
> org.springframework.mock.jndi.SimpleNamingContextBuilder to create a local
> JNDI context. I have used this for data sources but not for setting up
> JMS.
>
> Some other JNDI options are...
> http://oocjndi.sourceforge.net/
> http://www.osjava.org/simple-jndi/
>
> Though I have not used either of these.
>
> Hope this helps.
>
> Tim
>
>
> -----Original Message-----
> From: YQuinby@... [mailto:YQuinby@...]
> Sent: 17 November 2005 01:03
> To: user@...
> Subject: [mule-user] MQ Series and RFH2 Heading
>
>
>
> Hi,
>
> We are using Mule to send JMS messages via IBM MQ Series.
>
> I have the messages arriving on the queues, but we need to remove the JMS
> RFH2 header from our messages.
>
> According to IBM documentation, this can be done by appending
> targetClient=1 to the end of a URI.
>
> eg.
>
> jms://QUEUE_MANAGER/QUEUE_NAME?targetClient=1
>
> where 1=MQ and 0=JMS
>
> However, this doesn't seem to be working for us.
>
> Has anyone else who uses IBM MQ Series come across this issue before?
>
> Thanks.
>
>
>
>
> ===================================================
> HBF Health Funds Inc. a registered organisation under the National Health
> Act
> HBF Insurance Pty Ltd ACN  009 268 277
> This email is a confidential communication intended only for the named
> Addressee(s).
> If you are not that person any disclosure, copying, distribution or use of
> this email
> or the information in it is prohibited. Please notify us immediately by
> telephone, ([phone] or return email and delete this email.
> The views in this email may be personal to the author and not those of
> HBF.
>
>
> **********************************************************************
> This e-mail is confidential and should not be used by anyone who is not
> the original intended recipient.
> If you have received this e-mail in error please inform the sender and
> delete it from your mailbox or any other storage mechanism.
> The Book People Limited cannot accept liability for any statements made
> which are clearly the sender's own and not expressly made on behalf of The
> Book People Limited.
> We will not accept any responsibility for viruses, so please scan all
> attachments.
> **********************************************************************
>
>
>
>
> ===================================================
> HBF Health Funds Inc. a registered organisation under the National Health
> Act
> HBF Insurance Pty Ltd ACN  009 268 277
> This email is a confidential communication intended only for the named
> Addressee(s).
> If you are not that person any disclosure, copying, distribution or use of
> this email
> or the information in it is prohibited. Please notify us immediately by
> telephone, ([phone] or return email and delete this email.
> The views in this email may be personal to the author and not those of
> HBF.
>
>

--
View this message in context: http://www.nabble.com/-mule-user--MQ-Series-and-RFH2-Heading-tf567815.html#a10909456
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email