[
https://issues.apache.org/activemq/browse/AMQNET-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allan Schrum updated AMQNET-138:
--------------------------------
Attachment: AMQNET-138-741292.diff
I agree and your idea is a better approach. Unfortunately, the code in
TcpTransportFactory.cs (near line 173) currently uses the scheme from the URI
to determine STOMP versus OPENWIRE, and the qualifiers are checked later.
The attached patch supports the current method, but also allows for your
suggested approach. I have added a check for "wireFormat" as a query parameter.
This is done before the wire protocol is chosen and before the
wireFormat-specific parameters are checked. It is case insensitive as the query
parameters are stored in a StringDictionary. If the value is "stomp" then the
Stomp wireFormat is used. Otherwise it is the default.
Please let me know if this works. If it does then Jim can apply the patch (if
it meets his approval criteria) to the trunk.
> Unable to select STOMP protocol
> -------------------------------
>
> Key: AMQNET-138
> URL: https://issues.apache.org/activemq/browse/AMQNET-138
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ Client
> Affects Versions: 1.1
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Fix For: 1.1
>
> Attachments: AMQNET-138-741292.diff
>
>
> User reported issue with using the STOMP protocol due to recent changes made
> to NMS. See the following Nabble conversation for details:
> http://www.nabble.com/Changes-to-C--client-in-5.2---Can%27t-connect-via-STOMP...-td21549608.html
> When we went to actually connect to our server (stomp://192.168.0.1:61616 or
> whatnot, same as always), we get the following errors:
> 19/01/2009 1:36:08 PM WRN Transmitter.Setup:: The transport stomp is not
> supported.
> at
> Apache.NMS.ActiveMQ.Transport.TransportFactory.AddTransportFactory(String
> scheme)
> at Apache.NMS.ActiveMQ.Transport.TransportFactory.findTransportFactory(Uri
> location)
> at Apache.NMS.ActiveMQ.ConnectionFactory.CreateConnection(String userName,
> String password)
> at FAInterface.Transmitter.Setup_R()
> This seems to be a client code issue as if we use our old DLL we can connect
> to both 4.1 and 5.2 brokers. What are we missing?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
