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

indika priyantha kumara commented on WSCOMMONS-525:
---------------------------------------------------

Andreas .. thanks for all feedback 

I am going do the proposed change per my last comment. 

ObjectDataSourceDecoder and ObjectDataSourceEncoder can be given as service 
parameters or transport parameters. Even they will be able to provide as a 
message context property (may be useful for synapse) ...

OMElement is the domain object and ObjectDataSource is the external object 

External object to domain object - ObjectDataSourceDecoder (like XML Decoder - 
XML to bean)
Domain object to external object - ObjectDataSourceEncoder (like XMLEncoder - 
bean to XML)

I also believe use of ObjectMessageBuilder / ObjectMessageFormatter is correct 
as it preserve the conceptual integrity. For this, we can use 
'application/java-serialized-object' and configure through content-type rules. 

BTW, this is the first version of the Object Message Support ... So; I believe 
this is good enough for the first cut ... We can change as appropriate at later 
with discussions 
In the first version, all code will be inside the JMS transport and later we 
can move those into most appropriate places... (As require).

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.

Reply via email to