You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "indika priyantha kumara (JIRA)" <ji...@apache.org> on 2010/03/16 07:44:27 UTC

[jira] Issue Comment Edited: (WSCOMMONS-525) Supporting JMS Object Messages

    [ https://issues.apache.org/jira/browse/WSCOMMONS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845732#action_12845732 ] 

indika priyantha kumara edited comment on WSCOMMONS-525 at 3/16/10 6:44 AM:
----------------------------------------------------------------------------

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 with message formatter. It has to access 'ObjectDataSourceEncoder' directly. 

If I am not going to use builder / message formatter, then, I have 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 




      was (Author: indika):
    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.