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.
