[
https://issues.apache.org/jira/browse/SYNAPSE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645321#action_12645321
]
Andreas Veithen commented on SYNAPSE-424:
-----------------------------------------
I think we should take advantage of this issue to make the JMS transport more
flexible so that it can interoperate with a wider range of existing JMS based
applications. In particular, for incoming messages, we should allow the user
* to freely configure the JMS property used to determine the content type,
* to force a given content type (this is already supported),
* to define the default content type (if none is given in the message), maybe
even per message type (TextMessage and BytesMessage).
It should be noted that in order to allow a single Axis2 instance to interact
with different applications, these options must be configurable at the service
level (maybe with default values configurable at the transport level). If we
want to satisfy these requirement, we should implement a simple rule based
configuration model, more precisely, something like this:
<parameter name="transport.jms.ContentType">
<jmsProperty>Content-Type</jmsProperty>
<jmsProperty>ContentType</jmsProperty>
<default>application/xml</default>
</parameter>
Or with different default content types per message type:
<parameter name="transport.jms.ContentType">
<textMessage>text/plain</textMessage>
<bytesMessage>application/octet-stream</bytesMessage>
</parameter>
I think that this is reasonably simple, but yet very powerful and it should
cover a wide variety of use cases.
We should also allow to specify the JMS property to use for the content type of
outgoing messages. In my opinion this should be done by defining an additional
parameter in the EPRs. This is a bit ugly because it makes the jms:/ URIs even
longer, but I think it's the only consistent way to do this. The
JMSListener#getEPRsForService method would then calculate this parameter based
on the first "jmsProperty" rule for the service.
> JMS transport uses JMS properties in a way that violates the JMS
> specifications
> -------------------------------------------------------------------------------
>
> Key: SYNAPSE-424
> URL: https://issues.apache.org/jira/browse/SYNAPSE-424
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Environment: N/A
> Reporter: Andreas Veithen
> Attachments: commons_jms.patch
>
>
> According to section 3.5.1 of the JMS specification (version 1.1), "Property
> names must obey the rules for a message selector identifier." According to
> section 3.8.1.1 on selectors, "An identifier is an unlimited-length character
> sequence that must begin with a Java identifier start character; all
> following characters must be Java identifier part characters." The JMS
> transport's use of a property named "Content-Type" is in violation of this
> specification.
> Note that some JMS providers (such as qpid) accept illegal identifiers while
> others (such as WebSphere's SIBus client) don't.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
