The name of jmsToStr and strToJms transformers are confusing

[hdahl]

Original issue 246 created by soi-toolkit on 2012-04-11T13:14:19.000Z:

What steps will reproduce the problem?

1. soitoolkit-mule-jms-connector-commons.xml names transformers jmsToStr and strToJms, but they should be named jmsToObj and objToJms. The transformers do work with objects and not strings, so the naming is confusing.

   What is the expected output? What do you see instead?

What version of the product are you using? On what operating system? 0.5.0

Please provide any additional information below.

<jms:jmsmessage-to-object-transformer name="jmsToStr" /> <custom-transformer name="strToJms" class="org.soitoolkit.commons.mule.jms.ObjectToJMSMessageTransformer"/>

add:

<jms:jmsmessage-to-object-transformer name="jmsToObj" /> <custom-transformer name="objToJms" class="org.soitoolkit.commons.mule.jms.ObjectToJMSMessageTransformer"/>

[hdahl]

Comment #1 originally posted by soi-toolkit on 2012-05-17T07:14:32.000Z:

Yes, they are :-) ...when looked at in isolation...

Initially we actually used the names "jmsToObj and objToJms" but after some usage and some discussions we changed the names to "jmsToStr and strToJms".

The reasons for doing that are the following:

1. They are very often used together with jaxb transformers to actually transform between jaxb-objects and jms-messages with a xml-string payload. E.g. transformer-refs="objToXml strToJms" and transformer-refs="jmsToStr xmlToObj".

With the names "jmsToObj and objToJms" this looked like: transformer-refs="objToXml objToJms" and transformer-refs="jmsToObj xmlToObj".

...and that really made developers confused :-)

1. In almost all usecases "jmsToStr and strToJms" transformers are actually used to transform between jms payloads and strings and no other types of objects. In fact we encourrage to only use string payloads in jms messages for interoperability (e.g. with .Net messaging clients and so on)

In summary: The transformed are named for their prime (and major) use case and not for what they technically/theoretically can be used for (but advised against).

With this in mind the names are hopefully not that confusing :-)

[hdahl]

Comment #2 originally posted by soi-toolkit on 2012-05-20T19:19:18.000Z:

Just to clarify a bit: The confusing part is that I have a transformer ( strToJms ) that seems to expect a String but works fine with other types of objects as well. I would expect an exception if such a transformer receives a message payload that is not a String. In the same way I would expect jmsToStr to produce a string as result. Now the result actually depends on the type of JMS message (MapMessage => HashMap, ByteMessage => byte[] etc.

I might not see the whole picture here, but would it not be a good way to enforce the encouraged use of strings in JMS messages by using a payload type check in the transformers? Maybe pre-define both jmsToStr and jmsToObj and strToJms and objToJms where the "str-ones" type check for string and TextMessage?

[hdahl]

Comment #3 originally posted by soi-toolkit on 2012-07-26T16:24:04.000Z:

Move all closed v0.5.1 issues to v0.6.0

[hdahl]

Comment #4 originally posted by soi-toolkit on 2012-11-07T13:35:38.000Z:

There is only one thing constant and that is change...

We have now started to use BytesMessage and byte[] and see an increasing use of it meaning that TextMessage and Strings are not the main types used with JMS in soi-toolkit ant more.

Given this change the current rational for the names jmsToStr and strToJms (as described earlier) is no longer valid.

Lets simply change to jmsToObj and objToJms.

Construct such as: transformer-refs="objToXml objToJms" and transformer-refs="jmsToObj xmlToObj" will for sure still be confusing but it's maybe better to change the jaxb-transformers name to "jaxbToXml" instead of "objToXml" and "xmlToJaxb" to make it a bit less confusing?

E.g.: transformer-refs="jaxbToXml objToJms" and transformer-refs="jmsToObj xmlToJaxb"

What say you?

[hdahl]

Comment #5 originally posted by soi-toolkit on 2012-11-07T14:03:47.000Z:

I obviously like the change to objToJms and jmsToObj. How about using objToXmlStr and xmlStrToObj or jaxbToXmlStr and xmlStrToJaxb? That would make it more clear that it is a xml string that is accepted/produced and not some DOM tree or other XML representation.

E.g.: transformer-refs="jaxbToXmlStr objToJms" and transformer-refs="jmsToObj xmlStrToJaxb"

[hdahl]

Comment #6 originally posted by soi-toolkit on 2012-11-08T08:50:44.000Z:

I don't think the name xmlStrToJaxb is a very good name actually, Since the xml-to-jaxb-transformer takes a lot of inputs, not just Strings.

That is actually required for the BytesMessage approach to work, i.e. that it is Jaxb-runtime that determines the encoding reading the processing instruction in the beginning of the xml payload and not we as programmers when we create the String.

So byte[], XmlStreamReader or a plain InputStream is preferred to use together with BytesMessage instead of Strings and TextMessage when working with XML payloads and JMS.

Note: The jaxb-to-xml transformer can of course still create Strings when it marshals an jaxb-object since it is in full control of the encoding :-)

Ok?

[hdahl]

Comment #7 originally posted by soi-toolkit on 2012-11-09T09:25:22.000Z:

Ok, I missed that the XmlToJaxbObjectTransformer can take different types of input, so I agree that xmlStrToJaxb is a bad choice. I would go for xmlToJaxb as you suggested in the first place. Regarding the name of the jaxbToXml transformer I think you could argue for both jaxbToXml and jaxbToXmlStr. The first to keep symmetry and the second to stress the output type.

[hdahl]

Comment #8 originally posted by soi-toolkit on 2014-02-23T15:25:07.000Z:

<empty>