[
https://issues.apache.org/jira/browse/WSCOMMONS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845732#action_12845732
]
indika priyantha kumara commented on WSCOMMONS-525:
---------------------------------------------------
I actually thought to use a content type because there was a content type
validation, and a message without content type is identified as invalid and
throws an axis fault. However, later I felt because of conceptual integrity,
it is better to use a message builder / formatter (instead of some utility
methods)
Within the builder, load the 'ObjectDataSourceDecoder' instance and create an
OMElement from 'ObjectDataSource'. This Builder does not support
processDocument(InputStream inputStream, String s, MessageContext
messageContext)
Within the formatter, load the 'ObjectDataSourceEncoder' and create a
ObjectDataSource' using it and then take an input stream of write to the output
stream. This is only useful, if the object should be sent using non-jms
transport....Usually as a XML.
JMS Sender cannot work message formatter. It had to access
'ObjectDataSourceEncoder' directly.
If I am not going to use builder / message formatter, then, I had to add some
utility methods and need a way to bypass content type validation, also sending
object as a XML though other transport, may need code changes in each
transport. Because of these and the conceptual integrity, I preferred to use
message builder / formatter.
Andreas, shall I go with builder / formatter as a first cut and if it is
hugely undesirable and there is a better approach , let's do it later. I am
open for any changes and it is perfectly OK .
Thanks
Indika
> Supporting JMS Object Messages
> ------------------------------
>
> Key: WSCOMMONS-525
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-525
> Project: WS-Commons
> Issue Type: Improvement
> Components: Transport
> Affects Versions: Transports 1.0
> Reporter: indika priyantha kumara
> Fix For: Transports 1.1
>
> Attachments: jms-object-msg.patch
>
>
> I have attached herewith a patch to support Object Messages. What I did is as
> follows
> 1) Add a content type rule as follows
> <parameter name="transport.jms.ContentType">
> <rules>
>
> <objectMessage>application/java-serialized-object</objectMessage>
> </rules>
> </parameter>
> Even there is no content type for Java object messages, I have to specify one
> due to fact the JMS message receiver validates the content type. Furthermore,
> if there is content type, we can specify message builder / formatters.
> 2) When an Object message is received, it is wrapped with an
> ObjectDataSource and processed by the ObjectMessageBuilder. Within the
> ObjectMessageBuilder , if the content type is
> ''application/java-serialized-object" , It just wraps the ObjectDataSource
> using a DataHandler. The actual object can be accessed directly through the
> ObjectDataSource. This is useful for Apache Synapse as a mediator can access
> the object directly and do whatever it needs. If the content type is
> something other than ''application/java-serialized-object", selects the
> correct builder for the content type and build the java object with it by
> giving object as an XML stream. I here used XML Encoder... I will change it
> later.
> 3) When sending Object Messages, within the JMS transport, the object
> can be directly accessed from the ObjectDataSource. For other transport, if
> it is useful, ObjectMessageFormatter can be used.At later, I can improve
> ObjectDataSource to rerun the representation of Object based on the content
> type. E.g. XML, byte, etc... representations
> Any feedback is welcome. I will improve as per any suggestions and update the
> patch
> Thanks Indika
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
