search

soi-toolkit / soi-toolkit-google-code

Automatically exported from code.google.com/p/soi-toolkit
0 stars 0 forks source link

The name of jmsToStr and strToJms transformers are confusing #246

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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"/>

Original issue reported on code.google.com by par.wena...@gmail.com on 11 Apr 2012 at 1:14

GoogleCodeExporter commented 9 years ago 
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 :-)

2. 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 :-)

Original comment by magnus.l...@gmail.com on 17 May 2012 at 7:14

GoogleCodeExporter commented 9 years ago 
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?

Original comment by par.wena...@gmail.com on 20 May 2012 at 7:19

GoogleCodeExporter commented 9 years ago 
Move all closed v0.5.1 issues to v0.6.0

Original comment by magnus.l...@gmail.com on 26 Jul 2012 at 4:24

GoogleCodeExporter commented 9 years ago 
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?

Original comment by magnus.l...@gmail.com on 7 Nov 2012 at 1:35

GoogleCodeExporter commented 9 years ago 
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"

Original comment by par.wena...@gmail.com on 7 Nov 2012 at 2:03

GoogleCodeExporter commented 9 years ago 
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?

Original comment by magnus.l...@gmail.com on 8 Nov 2012 at 8:50

GoogleCodeExporter commented 9 years ago 
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.

Original comment by par.wena...@gmail.com on 9 Nov 2012 at 9:25

GoogleCodeExporter commented 9 years ago

Original comment by hakan.dahl@gmail.com on 23 Feb 2014 at 3:25