awslabs
Custom message attribute types cause JMS Exception
If any of the message attributes have a custom data type set, this results in their data type coming in with the sqs message as "SimpleType.CustomType" Thus if you select "String" and enter "Color", the data type is "String.Color" If you select "Number.int" and add "age", you get "Number.int.age".
The getObjectValue method on the SQSMessage class is parsing for exact match of data type, where it should be looking for startsWith.
The result is that parsing of the message attributes throws a JMS Exception, and the message bounces back to the queue instead of being processed.
for that matter, a perfectly valid data type for a message attribute is merely "Number", and that also appears to throw a JMS exception and make the message unreadable.
Is there somewhere that this pattern of data types is defined? I was able to create a message attribute with the data type of "fluffy bunny". This library has very strict requirements for what values it will accept as a data type, and I don't know why. if anything, just return as a string and leave the value alone.
aha https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-attributes.html#message-attributes-data-types-validation
Based on this, the fact that your library does not support "Number" is a failing. And, the fact that you are specifically supporting things like "Number.int" and "Number.float" is likely outside the scope of an Amazon library, and really something that ought be up to the given client.
From that page:
Binary – Binary type attributes can store any binary data, for example, compressed data, encrypted data, or images.
Number – Numbers are positive or negative integers or floating point numbers. Numbers have sufficient range and precision to encompass most of the possible values that integers, floats, and doubles typically support. A number can have up to 38 digits of precision, and it can be between 10^-128 and 10^+126. Leading and trailing zeroes are trimmed.
String – Strings are Unicode with UTF-8 binary encoding. For more information, see ASCII Printable Characters.
You can append a custom type label to any supported data type to create custom data types. This capability is similar to type traits in programming languages. For example, if you have an application that needs to know which type of number is being sent in the message, you can create custom types similar to the following: Number.byte, Number.short, Number.int, and Number.float. Another example using the binary data type is to use Binary.gif and Binary.png to distinguish among different image file types in a message or batch of messages. The appended data is optional and opaque to Amazon SQS, which means that the appended data isn't interpreted, validated, or used by Amazon SQS. The Custom Type extension has the same restrictions on allowed characters as the message body.
I would argue that it should be outside of the scope of this library to interpret custom data types. Leave that to the client.
So, just change the last light of getObjectValue from a throw JMS exception to return value.