You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by neek <ne...@nickfenwick.com> on 2012/07/23 06:11:17 UTC
AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
I see that one of the changes going into ActiveMQ 5.6 was Stomp 1.1 support:
https://issues.apache.org/jira/browse/AMQ-3449
Could this have changed the Stomp protocol supported in ActiveMQ such that
my Stomp 1.0 PHP client can no longer communicate with it? This sounds like
a regression, and so seems unlikely, however the specs at
http://stomp.github.com/stomp-specification-1.0.html#STOMP_Frames and
http://stomp.github.com/stomp-specification-1.1.html#STOMP_Frames clearly
show a difference and ActiveMQ 5.6 seems to be breaking Stomp 1.0
compatibility.
This is supported by https://issues.apache.org/jira/browse/AMQ-3823 which
clearly states that no whitespace (ws) should be trimmed from headers. This
makes an old Stomp 1.0 client completely incompatible with ActiveMQ and its
Stomp 1.1 implementation. It seems there's no version handshaking going on
in the Stomp protocol, so old clients have no way of working against new
servers because the server has no way of gracefully falling back to the old
protocol.
I did a bunch of painful debugging that I'll omit here as the situation
seems clear.
Where should we get a PHP Stomp 1.1 client from? I don't see one bundled
with ActiveMQ and the usual suspects (http://activemq.apache.org/php.html,
http://stomp.fusesource.org/index.html,
http://stomp.github.com/implementations.html) don't offer any fresh leads.
I see a comment on https://issues.apache.org/jira/browse/AMQ-3836 saying
that the PHP client has been updated, but I don't see where to find this
client.
I'm falling back to ActiveMQ 5.5 for now. A big red warning flag about
breaking Stomp 1.0 compatibility would have been appreciated. Perhaps there
was one and I missed it?
Nick
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654230.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by neek <ne...@nickfenwick.com>.
tabish121@gmail.com wrote
>
> On Mon, 2012-07-23 at 11:23 +0100, Gary Tully wrote:
>> So the root problem is the php client having space between the ':'
>> header key value separator that used to be trimmed.
>
Thank you both for your responses. I did read somewhere about trimming, and
a decision was made that no trimming should be done, in case values are sent
that were supposed to include either leading or trailing whitespace. In the
case of login and password headers this may sound whacky, but I'd support
the premise for all others. The Stomp 1.0 and 1.1 specs I linked to above
clearly show the 1.0 spec including a space and the 1.1 spec not including a
space, but I haven't read them in detail to see if this is considered
optional or if a trimming preference can be specified during connection.
>From the 1.1 spec:
> The STOMP 1.0 specification included many example frames with padding in
> the headers and many servers and clients were implemented to trim or pad
> header values. This causes problems if applications want to send headers
> that SHOULD not get trimmed. In STOMP 1.1, clients and servers MUST never
> trim or pad headers with spaces.
>
Sounds to me that this immediately breaks 1.0 clients talking to a 1.1
server i.e. the Stomp protocol is not backwardly compatible. The 1.0 client
will probably send "login: username" and the 1.1 server MUST interpret this
as a username of " username" just as I experienced. Thus, it is critical
that the server recognise the spec being used by the client and process it
accordingly.
tabish121@gmail.com wrote
>
> On Mon, 2012-07-23 at 11:23 +0100, Gary Tully wrote:
>> Seems like there is a need to make the 1.1 compliant behavior
>> introduced in https://issues.apache.org/jira/browse/AMQ-3823
>> configurable.
>> As in, have the option to force 1.0 (or existing amq) behavior when
>> the 1.1 version header is not present in a connect.
>> In fact, that seems like a sensible default.
>
Ah, I know very little about these protocols, if there's a 1.1 version
header (the 'handshaking' I thought was missing in my comments above) then
great, the server can tell whether the client is a 1.0 or 1.1 client. One
would think it could then gracefully degrade its protocol support to 1.0,
given that AMQ had working 1.0 support in 5.5.
A 1.0 CONNECT would look like:
CONNECT
login: <username>
passcode:<passcode>
A 1.1 CONNECT would look like:
CONNECT
accept-version:1.0,1.1,2.0
host:stomp.github.org
It's trivial for the server to detect a missing 'accept-version' header and
presume that it's a 1.0 protocol client.
It certainly amazes me that the AMQ merge that supports 1.1 seems to have
simply thrown 1.0 support out the window. Is this really the case?
tabish121@gmail.com wrote
>
> Even though its a bit vague, the Stomp 1.0 spec also requires that key /
> header values allow for space padding just as the 1.1 spec does, you can
> see this by examining the BNF for each spec. If we are going to claim
> spec compliance then we probably shouldn't default to non-spec complaint
> behavior. We could make it configurable but it seems like the right
> thing to do is to use an updated client that is also spec complaint
> instead of introducing yet another configuration option into the already
> large and not so well documented set of options we already have.
>
I'm a little confused by these comments.. the client I had was spec
compliant, with Stomp 1.0. The problem as I see it is that AMQ has been
updated to no longer support Stomp 1.0. In a perfect world, one should now
be able to use both the 1.0 client or 1.1 client against AMQ 5.6 and have
both work, everything be spec compliant, and no-one be crying into their
beer. If the 1.1 spec allows for a connection header indicating the
protocol version number, it seems sensible to me to default to 1.0 spec
unless that header is present, and use the spec it indicates if it is
present.
Tim gave me the url to a git repo for the latest PHP Stomp client:
git://github.com/dejanb/stomp-php.git
>From a cursory inspection, this code lacks the space after the colon in
Frame.php and so does seem to formulate 1.1 frames. Can this code please be
linked to from the activemq 'php' link, or anywhere else? Or the fusesource
site at http://stomp.fusesource.org/download.html ? I did a fair bit of
digging around earlier and it just seemed like the internet had never heard
of Stomp 1.1 for PHP, except that ActiveMQ had been updated and broken all
available PHP Stomp clients.
I'll try using that github client tomorrow and hope it interoperates with
AMQ 5.6 properly, hopefully I can post back with results soon. I presume my
existing PHP code, that uses the old 1.0 client, will break in 'interesting'
ways, so we'll see what happens.
Nick
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654262.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by Timothy Bish <ta...@gmail.com>.
On Mon, 2012-07-23 at 11:23 +0100, Gary Tully wrote:
> So the root problem is the php client having space between the ':'
> header key value separator that used to be trimmed.
>
> Seems like there is a need to make the 1.1 compliant behavior
> introduced in https://issues.apache.org/jira/browse/AMQ-3823
> configurable.
> As in, have the option to force 1.0 (or existing amq) behavior when
> the 1.1 version header is not present in a connect.
> In fact, that seems like a sensible default.
>
Even though its a bit vague, the Stomp 1.0 spec also requires that key /
header values allow for space padding just as the 1.1 spec does, you can
see this by examining the BNF for each spec. If we are going to claim
spec compliance then we probably shouldn't default to non-spec complaint
behavior. We could make it configurable but it seems like the right
thing to do is to use an updated client that is also spec complaint
instead of introducing yet another configuration option into the already
large and not so well documented set of options we already have.
>
> On 23 July 2012 05:11, neek <ne...@nickfenwick.com> wrote:
> > I see that one of the changes going into ActiveMQ 5.6 was Stomp 1.1 support:
> > https://issues.apache.org/jira/browse/AMQ-3449
> >
> > Could this have changed the Stomp protocol supported in ActiveMQ such that
> > my Stomp 1.0 PHP client can no longer communicate with it? This sounds like
> > a regression, and so seems unlikely, however the specs at
> > http://stomp.github.com/stomp-specification-1.0.html#STOMP_Frames and
> > http://stomp.github.com/stomp-specification-1.1.html#STOMP_Frames clearly
> > show a difference and ActiveMQ 5.6 seems to be breaking Stomp 1.0
> > compatibility.
> >
> > This is supported by https://issues.apache.org/jira/browse/AMQ-3823 which
> > clearly states that no whitespace (ws) should be trimmed from headers. This
> > makes an old Stomp 1.0 client completely incompatible with ActiveMQ and its
> > Stomp 1.1 implementation. It seems there's no version handshaking going on
> > in the Stomp protocol, so old clients have no way of working against new
> > servers because the server has no way of gracefully falling back to the old
> > protocol.
> >
> > I did a bunch of painful debugging that I'll omit here as the situation
> > seems clear.
> >
> > Where should we get a PHP Stomp 1.1 client from? I don't see one bundled
> > with ActiveMQ and the usual suspects (http://activemq.apache.org/php.html,
> > http://stomp.fusesource.org/index.html,
> > http://stomp.github.com/implementations.html) don't offer any fresh leads.
> > I see a comment on https://issues.apache.org/jira/browse/AMQ-3836 saying
> > that the PHP client has been updated, but I don't see where to find this
> > client.
> >
> > I'm falling back to ActiveMQ 5.5 for now. A big red warning flag about
> > breaking Stomp 1.0 compatibility would have been appreciated. Perhaps there
> > was one and I missed it?
> >
> > Nick
> >
> >
> >
> > --
> > View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654230.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
>
--
Tim Bish
Sr Software Engineer | FuseSource Corp
tim.bish@fusesource.com | www.fusesource.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by Dejan Bosanac <de...@nighttale.net>.
I just tested latest php client
git clone git://github.com/dejanb/stomp-php.git
with 5.7-SNAPSHOT
If you start broker with
bin/activemq console xbean:conf/activemq-stomp.xml
and then that example
cd stomp-php/src/examples
php transformation.php
I get
Sending array: Array
(
[city] => Belgrade
[name] => Dejan
)
Received array: Array
(
[city] => Belgrade
[name] => Dejan
)
BTW snapshot was built from the trunk, so you can get your sources
here http://activemq.apache.org/source.html
You might also wanna take a look at StompTest
https://fisheye6.atlassian.com/browse/activemq/trunk/activemq-core/src/test/java/org/apache/activemq/transport/stomp/StompTest.java?hb=true
as it has covered many use cases (including message transformation)
Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dejanb@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Thu, Jul 26, 2012 at 7:31 AM, neek <ne...@nickfenwick.com> wrote:
> The source didn't seem to be available in that 5.7-SNAPSHOT so it wasn't
> easy to debug.
>
> On a more positive note, after much messing about this morning, I've
> used the latest PHP client with ActiveMQ 5.6 (the one that I couldn't
> get working with the 1.0 PHP client) and it works.
>
> I do have to use the old style body format for the messages, e.g.:
>
> """"" START CAPTURE
> CONNECT
> login:zencart
> passcode:premierrange
>
> .CONNECTED
> heart-beat:0,0
> session:ID:uberneek-52546-1343274524763-8:3
> server:ActiveMQ/5.6.0
> version:1.0
>
> .
> SEND
> transformation:jms-map-json
> destination:/queue/integration.account_update
>
> {"map":{"entry":[{"string":["update_type","address"]},{"string":["customers_id","824"]},{"string":["entry_gender","m"]},{"string":["entry_company",""]},{"string":["entry_firstname","nnn"]},{"string":["entry_lastname","fff"]},{"string":["entry_street_address","ddd"]},{"string":["entry_suburb","fff"]},{"string":["entry_postcode","ddd"]},{"string":["entry_city","ddd"]},{"string":["entry_state","ddd"]},{"string":["countries_iso_code_2","GB"]}]}}.DISCONNECT
> """"" END CAPTURE
>
> However that "version:1.0" coming back from AMQ 5.6 is worrying.
> Debugging shows that ProtocolConverter.java is seeing no
> "accept-version" header from the client and thus defaults to 1.0
> protocol. I don't see anything in the stomp-php module that would set
> this header, so cannot see how it would ever send 1.1.
>
> The 1.1 spec at
> http://stomp.github.com/stomp-specification-1.1.html#Connecting
> indicates the client should sent a "accept-version:1.1" header.. so I
> feel I'm wasting my time with a duff client, here.
>
> Further investigation:
>
> Sticking with the latest php client, sending the format I see used in
> the example files in the new PHP client, e.g.
> src/examples/transformation.php where it sends a body of
> "array("city"=>"Belgrade", "name"=>"Dejan");" doesn't work:
>
> """"" START CAPTURE
> CONNECT
> login:zencart
> passcode:premierrange
>
> .CONNECTED
> heart-beat:0,0
> session:ID:uberneek-52546-1343274524763-8:4
> server:ActiveMQ/5.6.0
> version:1.0
>
> .
> SEND
> transformation:jms-map-json
> destination:/queue/integration.account_update
>
> {"test":"foo","othertest":1234}.DISCONNECT
>
> .
> """"" END CAPTURE
>
> Thrown on the server side, it seems to be trying to use the first map
> key "test" as a class name, the same slot I had "map" in the above
> capture that succeeded. I put in some more useful logging into
> JmsFrameTranslator to print details of the Throwable that is otherwise
> just sent back in the response frame as a message only:
>
> Jul 26, 2012 11:57:53 AM
> org.apache.activemq.transport.stomp.JmsFrameTranslator convertFrame
> SEVERE: Exception creating message:test
> com.thoughtworks.xstream.mapper.CannotResolveClassException: test
> at
> com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:56)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:74)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
> at
> com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:45)
> at
> com.thoughtworks.xstream.core.util.HierarchicalStreams.readClassType(HierarchicalStreams.java:29)
> at
> com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:133)
> at
> com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1052)
> at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1024)
> at
> org.apache.activemq.transport.stomp.JmsFrameTranslator.createMapMessage(JmsFrameTranslator.java:196)
> at
> org.apache.activemq.transport.stomp.JmsFrameTranslator.convertFrame(JmsFrameTranslator.java:86)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.convertMessage(ProtocolConverter.java:720)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.onStompSend(ProtocolConverter.java:236)
> at
> org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:164)
> at
> org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:76)
> at
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
> at
> org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:222)
> at
> org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:204)
> at java.lang.Thread.run(Thread.java:722)
>
> Following this, my consumer is invoked, but is given a
> org.apache.activemq.command.ActiveMQTextMessage instead of a MapMessage,
> so I presume the unmarshalling failed to unmarshall the "test" class
> name it saw and defaulted to creating a basic text message. I see the
> same behaviour with the 5.7-SNAPSHOT server.
>
> Conclusions so far: the php client is broken and doesn't properly
> advertise that it supports the 1.1 spec, so the server always defaults
> to 1.0 protocol. Thus, using my old code that sends 1.0 format messages
> is working fine with AMQ 5.6 The same code against 5.7-SNAPSHOT fails,
> as covered in my previous post, and I don't know why without access to
> the source code.
>
> Nick
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654397.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by neek <ne...@nickfenwick.com>.
The source didn't seem to be available in that 5.7-SNAPSHOT so it wasn't
easy to debug.
On a more positive note, after much messing about this morning, I've
used the latest PHP client with ActiveMQ 5.6 (the one that I couldn't
get working with the 1.0 PHP client) and it works.
I do have to use the old style body format for the messages, e.g.:
""""" START CAPTURE
CONNECT
login:zencart
passcode:premierrange
.CONNECTED
heart-beat:0,0
session:ID:uberneek-52546-1343274524763-8:3
server:ActiveMQ/5.6.0
version:1.0
.
SEND
transformation:jms-map-json
destination:/queue/integration.account_update
{"map":{"entry":[{"string":["update_type","address"]},{"string":["customers_id","824"]},{"string":["entry_gender","m"]},{"string":["entry_company",""]},{"string":["entry_firstname","nnn"]},{"string":["entry_lastname","fff"]},{"string":["entry_street_address","ddd"]},{"string":["entry_suburb","fff"]},{"string":["entry_postcode","ddd"]},{"string":["entry_city","ddd"]},{"string":["entry_state","ddd"]},{"string":["countries_iso_code_2","GB"]}]}}.DISCONNECT
""""" END CAPTURE
However that "version:1.0" coming back from AMQ 5.6 is worrying.
Debugging shows that ProtocolConverter.java is seeing no
"accept-version" header from the client and thus defaults to 1.0
protocol. I don't see anything in the stomp-php module that would set
this header, so cannot see how it would ever send 1.1.
The 1.1 spec at
http://stomp.github.com/stomp-specification-1.1.html#Connecting
indicates the client should sent a "accept-version:1.1" header.. so I
feel I'm wasting my time with a duff client, here.
Further investigation:
Sticking with the latest php client, sending the format I see used in
the example files in the new PHP client, e.g.
src/examples/transformation.php where it sends a body of
"array("city"=>"Belgrade", "name"=>"Dejan");" doesn't work:
""""" START CAPTURE
CONNECT
login:zencart
passcode:premierrange
.CONNECTED
heart-beat:0,0
session:ID:uberneek-52546-1343274524763-8:4
server:ActiveMQ/5.6.0
version:1.0
.
SEND
transformation:jms-map-json
destination:/queue/integration.account_update
{"test":"foo","othertest":1234}.DISCONNECT
.
""""" END CAPTURE
Thrown on the server side, it seems to be trying to use the first map
key "test" as a class name, the same slot I had "map" in the above
capture that succeeded. I put in some more useful logging into
JmsFrameTranslator to print details of the Throwable that is otherwise
just sent back in the response frame as a message only:
Jul 26, 2012 11:57:53 AM
org.apache.activemq.transport.stomp.JmsFrameTranslator convertFrame
SEVERE: Exception creating message:test
com.thoughtworks.xstream.mapper.CannotResolveClassException: test
at
com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:56)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:74)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)
at
com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:45)
at
com.thoughtworks.xstream.core.util.HierarchicalStreams.readClassType(HierarchicalStreams.java:29)
at
com.thoughtworks.xstream.core.TreeUnmarshaller.start(TreeUnmarshaller.java:133)
at
com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.unmarshal(AbstractTreeMarshallingStrategy.java:32)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1052)
at com.thoughtworks.xstream.XStream.unmarshal(XStream.java:1024)
at
org.apache.activemq.transport.stomp.JmsFrameTranslator.createMapMessage(JmsFrameTranslator.java:196)
at
org.apache.activemq.transport.stomp.JmsFrameTranslator.convertFrame(JmsFrameTranslator.java:86)
at
org.apache.activemq.transport.stomp.ProtocolConverter.convertMessage(ProtocolConverter.java:720)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompSend(ProtocolConverter.java:236)
at
org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:164)
at
org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:76)
at
org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:222)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:204)
at java.lang.Thread.run(Thread.java:722)
Following this, my consumer is invoked, but is given a
org.apache.activemq.command.ActiveMQTextMessage instead of a MapMessage,
so I presume the unmarshalling failed to unmarshall the "test" class
name it saw and defaulted to creating a basic text message. I see the
same behaviour with the 5.7-SNAPSHOT server.
Conclusions so far: the php client is broken and doesn't properly
advertise that it supports the 1.1 spec, so the server always defaults
to 1.0 protocol. Thus, using my old code that sends 1.0 format messages
is working fine with AMQ 5.6 The same code against 5.7-SNAPSHOT fails,
as covered in my previous post, and I don't know why without access to
the source code.
Nick
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654397.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by Dejan Bosanac <de...@nighttale.net>.
It seems like you're having problems parsing your content. I would
make sure for starters that you have XStream and Jettison in your
broker's classpath.
Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dejanb@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Wed, Jul 25, 2012 at 5:39 PM, neek <ne...@nickfenwick.com> wrote:
> On 07/25/2012 08:21 PM, dejanb [via ActiveMQ] wrote:
>> Can you try the latest snapshot and confirm it works for you
>>
>> https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.7-SNAPSHOT/
>>
>
> Looks like progress. My old stomp 1.0 client can connect, login and
> send a message to ActiveMQ 5.7-SNAPSHOT.
>
> Unfortunately it then throws:
>
> [java] Jul 25, 2012 10:00:59 PM
> org.apache.activemq.transport.stomp.ProtocolConverter handleException
> [java] WARNING: Exception occurred processing:
> [java] SEND
> [java] amq-msg-type:MapMessage
> [java] transformation:jms-map-json
> [java] destination:/queue/integration.account_update
> [java] transformation-error:org/xmlpull/v1/XmlPullParserException
> [java]
> [java]
> {"map":{"entry":[{"string":["update_type","ad...2","GB"]}]}}:
> org.apache.activemq.transport.stomp.ProtocolException: Unsupported
> message type 'MapMessage'
>
> I've seen this before and don't think I ever worked a way around it.
>
> To try to get around this, I updated my PHP client to the latest from
> the github repo, and dropped it into my client e-commerce site lib
> directory, and put together a basic test using the
> stomp-php/src/examples/transformation.php as a guide. (the 'namespace',
> 'use' and 'auto_loader' stuff is completely foreign to me, and I wasted
> some time trying to get it to work .. the require_once and
> FuseSource\Stomp\Stomp syntax runs, at least)
>
> ini_set('include_path', ini_get('include_path') .
> PATH_SEPARATOR . 'lib' . PATH_SEPARATOR . 'lib/FuseSource');
> require_once("Stomp/Stomp.php");
> require_once("Stomp/Frame.php");
> require_once("Stomp/Message.php");
> require_once("Stomp/Message/Map.php");
> // make a connection to ActiveMQ
> if ($dbg) error_log("Making connection to " .
> ACTIVEMQ_STOMP_URL . "...");
> $con = new FuseSource\Stomp\Stomp(ACTIVEMQ_STOMP_URL);
> // connect
> $con->connect(ACTIVEMQ_USERNAME, ACTIVEMQ_PASSWORD);
>
> // real data $body = array('map' => array('entry' => $entries));
> $body = array('test' => 'foo', 'othertest' => 1234); // dummy data
>
> $header = array('transformation' => 'jms-map-json');
> $mapMessage = new FuseSource\Stomp\Message\Map($body, $header);
> if ($dbg) error_log("Calling send...");
> $con->send("/queue/integration.account_update", $mapMessage,
> array());
>
> This caused the server to receive a message, but it's not of type
> javax.jms.MapMessage:
>
> [java] Jul 25, 2012 10:30:29 PM
> ltd.yavin.liveauction.jms.GenericConsumer onMessage
> [java] INFO: XXX message class
> org.apache.activemq.command.ActiveMQTextMessage: ActiveMQTextMessage
> {commandId = 3, responseRequired = false, messageId =
> ID:uberneek-33640-1343230073443-8:3:-1:1:1, originalDestination = null,
> originalTransactionId = null, producerId =
> ID:uberneek-33640-1343230073443-8:3:-1:1, destination =
> queue://integration.account_update, transactionId = null, expiration =
> 0, timestamp = 1343230229732, arrival = 0, brokerInTime = 1343230229732,
> brokerOutTime = 1343230229733, correlationId = null, replyTo = null,
> persistent = false, type = null, priority = 4, groupID = null,
> groupSequence = 0, targetConsumerId = null, compressed = false, userID =
> null, content = null, marshalledProperties = null, dataStructure = null,
> redeliveryCounter = 0, size = 1059, properties =
> {transformation-error=org/xmlpull/v1/XmlPullParserException,
> transformation=jms-map-json}, readOnlyProperties = true, readOnlyBody =
> true, droppable = false, text = {"test":"foo","othertest":1234}}
>
> My server then rejects the message, because it's coded to only accept
> MapMessage objects.
>
> I can see the conversation going over the wire via wireshark:
>
> CONNECT
> login:zencart
> passcode:premierrange
>
> .CONNECTED
> heart-beat:0,0
> session:ID:uberneek-33640-1343230073443-8:4
> server:ActiveMQ/5.7-SNAPSHOT
> version:1.0
>
> .
> SEND
> transformation:jms-map-json
> destination:/queue/integration.account_update
>
> {"test":"foo","othertest":1234}.DISCONNECT
>
> .
>
> Assuming I'm going to stick with the new client and use Stomp 1.1, can
> you suggest why the message being sent isn't recognised as a MapMessage
> on the server side?
>
> I'm sure part of the point here was to show that 5.7-SNAPSHOT can
> communicate with the old 1.0 Stomp client. This failed for me but I'm
> not sure if you want me to do further debugging, as it failed within the
> activemq code and I presume you can reproduce that error on your system
> and debug far better than I can.
>
> Nick
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654357.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by neek <ne...@nickfenwick.com>.
On 07/25/2012 08:21 PM, dejanb [via ActiveMQ] wrote:
> Can you try the latest snapshot and confirm it works for you
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.7-SNAPSHOT/
>
Looks like progress. My old stomp 1.0 client can connect, login and
send a message to ActiveMQ 5.7-SNAPSHOT.
Unfortunately it then throws:
[java] Jul 25, 2012 10:00:59 PM
org.apache.activemq.transport.stomp.ProtocolConverter handleException
[java] WARNING: Exception occurred processing:
[java] SEND
[java] amq-msg-type:MapMessage
[java] transformation:jms-map-json
[java] destination:/queue/integration.account_update
[java] transformation-error:org/xmlpull/v1/XmlPullParserException
[java]
[java]
{"map":{"entry":[{"string":["update_type","ad...2","GB"]}]}}:
org.apache.activemq.transport.stomp.ProtocolException: Unsupported
message type 'MapMessage'
I've seen this before and don't think I ever worked a way around it.
To try to get around this, I updated my PHP client to the latest from
the github repo, and dropped it into my client e-commerce site lib
directory, and put together a basic test using the
stomp-php/src/examples/transformation.php as a guide. (the 'namespace',
'use' and 'auto_loader' stuff is completely foreign to me, and I wasted
some time trying to get it to work .. the require_once and
FuseSource\Stomp\Stomp syntax runs, at least)
ini_set('include_path', ini_get('include_path') .
PATH_SEPARATOR . 'lib' . PATH_SEPARATOR . 'lib/FuseSource');
require_once("Stomp/Stomp.php");
require_once("Stomp/Frame.php");
require_once("Stomp/Message.php");
require_once("Stomp/Message/Map.php");
// make a connection to ActiveMQ
if ($dbg) error_log("Making connection to " .
ACTIVEMQ_STOMP_URL . "...");
$con = new FuseSource\Stomp\Stomp(ACTIVEMQ_STOMP_URL);
// connect
$con->connect(ACTIVEMQ_USERNAME, ACTIVEMQ_PASSWORD);
// real data $body = array('map' => array('entry' => $entries));
$body = array('test' => 'foo', 'othertest' => 1234); // dummy data
$header = array('transformation' => 'jms-map-json');
$mapMessage = new FuseSource\Stomp\Message\Map($body, $header);
if ($dbg) error_log("Calling send...");
$con->send("/queue/integration.account_update", $mapMessage,
array());
This caused the server to receive a message, but it's not of type
javax.jms.MapMessage:
[java] Jul 25, 2012 10:30:29 PM
ltd.yavin.liveauction.jms.GenericConsumer onMessage
[java] INFO: XXX message class
org.apache.activemq.command.ActiveMQTextMessage: ActiveMQTextMessage
{commandId = 3, responseRequired = false, messageId =
ID:uberneek-33640-1343230073443-8:3:-1:1:1, originalDestination = null,
originalTransactionId = null, producerId =
ID:uberneek-33640-1343230073443-8:3:-1:1, destination =
queue://integration.account_update, transactionId = null, expiration =
0, timestamp = 1343230229732, arrival = 0, brokerInTime = 1343230229732,
brokerOutTime = 1343230229733, correlationId = null, replyTo = null,
persistent = false, type = null, priority = 4, groupID = null,
groupSequence = 0, targetConsumerId = null, compressed = false, userID =
null, content = null, marshalledProperties = null, dataStructure = null,
redeliveryCounter = 0, size = 1059, properties =
{transformation-error=org/xmlpull/v1/XmlPullParserException,
transformation=jms-map-json}, readOnlyProperties = true, readOnlyBody =
true, droppable = false, text = {"test":"foo","othertest":1234}}
My server then rejects the message, because it's coded to only accept
MapMessage objects.
I can see the conversation going over the wire via wireshark:
CONNECT
login:zencart
passcode:premierrange
.CONNECTED
heart-beat:0,0
session:ID:uberneek-33640-1343230073443-8:4
server:ActiveMQ/5.7-SNAPSHOT
version:1.0
.
SEND
transformation:jms-map-json
destination:/queue/integration.account_update
{"test":"foo","othertest":1234}.DISCONNECT
.
Assuming I'm going to stick with the new client and use Stomp 1.1, can
you suggest why the message being sent isn't recognised as a MapMessage
on the server side?
I'm sure part of the point here was to show that 5.7-SNAPSHOT can
communicate with the old 1.0 Stomp client. This failed for me but I'm
not sure if you want me to do further debugging, as it failed within the
activemq code and I presume you can reproduce that error on your system
and debug far better than I can.
Nick
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654357.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by Dejan Bosanac <de...@nighttale.net>.
Can you try the latest snapshot and confirm it works for you
https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.7-SNAPSHOT/
Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dejanb@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Tue, Jul 24, 2012 at 4:42 PM, neek <ne...@nickfenwick.com> wrote:
>
> dejanb wrote
>>
>> +1 from me as well. I'll reopen
>> https://issues.apache.org/jira/browse/AMQ-3823 and work on this. Also
>> will take this opportunity to get our php client up to date.
>>
>
> Great, thanks to everyone who has responded. I've not got round to trying
> the new Stomp client from github yet so nothing to report.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654309.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by neek <ne...@nickfenwick.com>.
dejanb wrote
>
> +1 from me as well. I'll reopen
> https://issues.apache.org/jira/browse/AMQ-3823 and work on this. Also
> will take this opportunity to get our php client up to date.
>
Great, thanks to everyone who has responded. I've not got round to trying
the new Stomp client from github yet so nothing to report.
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654309.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by Dejan Bosanac <de...@nighttale.net>.
+1 from me as well. I'll reopen
https://issues.apache.org/jira/browse/AMQ-3823 and work on this. Also
will take this opportunity to get our php client up to date.
Regards
--
Dejan Bosanac
Senior Software Engineer | FuseSource Corp.
dejanb@fusesource.com | fusesource.com
skype: dejan.bosanac | twitter: @dejanb
blog: http://www.nighttale.net
ActiveMQ in Action: http://www.manning.com/snyder/
On Mon, Jul 23, 2012 at 9:36 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> +1
>
> We can detect 1.0 clients and we should continue to trim the headers in 1.0
> case. That way we avoid break clients.
>
> On Mon, Jul 23, 2012 at 6:23 AM, Gary Tully <ga...@gmail.com> wrote:
>
>> So the root problem is the php client having space between the ':'
>> header key value separator that used to be trimmed.
>>
>> Seems like there is a need to make the 1.1 compliant behavior
>> introduced in https://issues.apache.org/jira/browse/AMQ-3823
>> configurable.
>> As in, have the option to force 1.0 (or existing amq) behavior when
>> the 1.1 version header is not present in a connect.
>> In fact, that seems like a sensible default.
>>
>>
>> On 23 July 2012 05:11, neek <ne...@nickfenwick.com> wrote:
>> > I see that one of the changes going into ActiveMQ 5.6 was Stomp 1.1
>> support:
>> > https://issues.apache.org/jira/browse/AMQ-3449
>> >
>> > Could this have changed the Stomp protocol supported in ActiveMQ such
>> that
>> > my Stomp 1.0 PHP client can no longer communicate with it? This sounds
>> like
>> > a regression, and so seems unlikely, however the specs at
>> > http://stomp.github.com/stomp-specification-1.0.html#STOMP_Frames and
>> > http://stomp.github.com/stomp-specification-1.1.html#STOMP_Framesclearly
>> > show a difference and ActiveMQ 5.6 seems to be breaking Stomp 1.0
>> > compatibility.
>> >
>> > This is supported by https://issues.apache.org/jira/browse/AMQ-3823which
>> > clearly states that no whitespace (ws) should be trimmed from headers.
>> This
>> > makes an old Stomp 1.0 client completely incompatible with ActiveMQ and
>> its
>> > Stomp 1.1 implementation. It seems there's no version handshaking going
>> on
>> > in the Stomp protocol, so old clients have no way of working against new
>> > servers because the server has no way of gracefully falling back to the
>> old
>> > protocol.
>> >
>> > I did a bunch of painful debugging that I'll omit here as the situation
>> > seems clear.
>> >
>> > Where should we get a PHP Stomp 1.1 client from? I don't see one bundled
>> > with ActiveMQ and the usual suspects (
>> http://activemq.apache.org/php.html,
>> > http://stomp.fusesource.org/index.html,
>> > http://stomp.github.com/implementations.html) don't offer any fresh
>> leads.
>> > I see a comment on https://issues.apache.org/jira/browse/AMQ-3836 saying
>> > that the PHP client has been updated, but I don't see where to find this
>> > client.
>> >
>> > I'm falling back to ActiveMQ 5.5 for now. A big red warning flag about
>> > breaking Stomp 1.0 compatibility would have been appreciated. Perhaps
>> there
>> > was one and I missed it?
>> >
>> > Nick
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654230.html
>> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> http://fusesource.com
>> http://blog.garytully.com
>>
>
>
>
> --
>
> **
>
> *Hiram Chirino*
>
> *Software Fellow | FuseSource Corp.*
>
> *chirino@fusesource.com | fusesource.com*
>
> *skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
> *
>
> *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
>
> *
> *
>
> *
> *
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by Hiram Chirino <hi...@hiramchirino.com>.
+1
We can detect 1.0 clients and we should continue to trim the headers in 1.0
case. That way we avoid break clients.
On Mon, Jul 23, 2012 at 6:23 AM, Gary Tully <ga...@gmail.com> wrote:
> So the root problem is the php client having space between the ':'
> header key value separator that used to be trimmed.
>
> Seems like there is a need to make the 1.1 compliant behavior
> introduced in https://issues.apache.org/jira/browse/AMQ-3823
> configurable.
> As in, have the option to force 1.0 (or existing amq) behavior when
> the 1.1 version header is not present in a connect.
> In fact, that seems like a sensible default.
>
>
> On 23 July 2012 05:11, neek <ne...@nickfenwick.com> wrote:
> > I see that one of the changes going into ActiveMQ 5.6 was Stomp 1.1
> support:
> > https://issues.apache.org/jira/browse/AMQ-3449
> >
> > Could this have changed the Stomp protocol supported in ActiveMQ such
> that
> > my Stomp 1.0 PHP client can no longer communicate with it? This sounds
> like
> > a regression, and so seems unlikely, however the specs at
> > http://stomp.github.com/stomp-specification-1.0.html#STOMP_Frames and
> > http://stomp.github.com/stomp-specification-1.1.html#STOMP_Framesclearly
> > show a difference and ActiveMQ 5.6 seems to be breaking Stomp 1.0
> > compatibility.
> >
> > This is supported by https://issues.apache.org/jira/browse/AMQ-3823which
> > clearly states that no whitespace (ws) should be trimmed from headers.
> This
> > makes an old Stomp 1.0 client completely incompatible with ActiveMQ and
> its
> > Stomp 1.1 implementation. It seems there's no version handshaking going
> on
> > in the Stomp protocol, so old clients have no way of working against new
> > servers because the server has no way of gracefully falling back to the
> old
> > protocol.
> >
> > I did a bunch of painful debugging that I'll omit here as the situation
> > seems clear.
> >
> > Where should we get a PHP Stomp 1.1 client from? I don't see one bundled
> > with ActiveMQ and the usual suspects (
> http://activemq.apache.org/php.html,
> > http://stomp.fusesource.org/index.html,
> > http://stomp.github.com/implementations.html) don't offer any fresh
> leads.
> > I see a comment on https://issues.apache.org/jira/browse/AMQ-3836 saying
> > that the PHP client has been updated, but I don't see where to find this
> > client.
> >
> > I'm falling back to ActiveMQ 5.5 for now. A big red warning flag about
> > breaking Stomp 1.0 compatibility would have been appreciated. Perhaps
> there
> > was one and I missed it?
> >
> > Nick
> >
> >
> >
> > --
> > View this message in context:
> http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654230.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
>
> --
> http://fusesource.com
> http://blog.garytully.com
>
--
**
*Hiram Chirino*
*Software Fellow | FuseSource Corp.*
*chirino@fusesource.com | fusesource.com*
*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*
*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
*
*
*
*
Re: AMQ 5.6 breaks Stomp 1.0 clients, was: Re: 5.5 to 5.6 upgrade,
stomp client suddenly gets "User name [ xyz] or password is invalid."
Posted by Gary Tully <ga...@gmail.com>.
So the root problem is the php client having space between the ':'
header key value separator that used to be trimmed.
Seems like there is a need to make the 1.1 compliant behavior
introduced in https://issues.apache.org/jira/browse/AMQ-3823
configurable.
As in, have the option to force 1.0 (or existing amq) behavior when
the 1.1 version header is not present in a connect.
In fact, that seems like a sensible default.
On 23 July 2012 05:11, neek <ne...@nickfenwick.com> wrote:
> I see that one of the changes going into ActiveMQ 5.6 was Stomp 1.1 support:
> https://issues.apache.org/jira/browse/AMQ-3449
>
> Could this have changed the Stomp protocol supported in ActiveMQ such that
> my Stomp 1.0 PHP client can no longer communicate with it? This sounds like
> a regression, and so seems unlikely, however the specs at
> http://stomp.github.com/stomp-specification-1.0.html#STOMP_Frames and
> http://stomp.github.com/stomp-specification-1.1.html#STOMP_Frames clearly
> show a difference and ActiveMQ 5.6 seems to be breaking Stomp 1.0
> compatibility.
>
> This is supported by https://issues.apache.org/jira/browse/AMQ-3823 which
> clearly states that no whitespace (ws) should be trimmed from headers. This
> makes an old Stomp 1.0 client completely incompatible with ActiveMQ and its
> Stomp 1.1 implementation. It seems there's no version handshaking going on
> in the Stomp protocol, so old clients have no way of working against new
> servers because the server has no way of gracefully falling back to the old
> protocol.
>
> I did a bunch of painful debugging that I'll omit here as the situation
> seems clear.
>
> Where should we get a PHP Stomp 1.1 client from? I don't see one bundled
> with ActiveMQ and the usual suspects (http://activemq.apache.org/php.html,
> http://stomp.fusesource.org/index.html,
> http://stomp.github.com/implementations.html) don't offer any fresh leads.
> I see a comment on https://issues.apache.org/jira/browse/AMQ-3836 saying
> that the PHP client has been updated, but I don't see where to find this
> client.
>
> I'm falling back to ActiveMQ 5.5 for now. A big red warning flag about
> breaking Stomp 1.0 compatibility would have been appreciated. Perhaps there
> was one and I missed it?
>
> Nick
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/5-5-to-5-6-upgrade-stomp-client-suddenly-gets-User-name-xyz-or-password-is-invalid-tp4654229p4654230.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
--
http://fusesource.com
http://blog.garytully.com