[
https://issues.apache.org/jira/browse/WSCOMMONS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12839402#action_12839402
]
Andreas Veithen commented on WSCOMMONS-525:
-------------------------------------------
Let's test your solution on a concrete use case. Assume that I have a JAX-WS
service that I would like to invoke over JMS using object messages. Since the
JAX-WS databinding uses (JAXB generated) POJOs, it is a natural choice to use
these objects directly in ObjectMessages. This is possible, provided that the
generated classes are made serializable, which can be easily achieved using a
JAXB customization. The JAX-WS implementation in Axis2 has an OMDataSource
implementation that is backed by a JAXB generated POJO. Thus, to implement the
use case, the JMS transport needs to be configured such that it takes the
object from the ObjectMessage, creates an OMSourcedElement using the
aforementioned OMDataSource implementation, wraps that in a SOAPEnvelope and
adds it to the MessageContext. Of course, in addition to that, we would have to
make sure that if the JAX-WS implementation encounters such an OMSourcedElement
in the body, it retrieves the JAXB object without going again through the
databinding step. This is probably already the case, but if it's not, it would
be a natural change. Note that except from the deserialization done by the JMS
provider, no other transformation of the payload is required here and the
object retrieved from the ObjectMessage would be directly provided to the
service implementation.
How would your solution support this use case?
> 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.
