[
https://issues.apache.org/jira/browse/CXF-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627183#action_12627183
]
Daniel Kulp commented on CXF-1774:
----------------------------------
Quick comment:
with the JNDI lookup mechanism, the JMS transport can be used in non-spring
configurations. I'd be slightly reluctant to lose that ability.
Also note that the SOAP/JMS spec specifically requires support for using JNDI
lookups. Thus, we would need it if implementing that spec.
http://www.w3.org/Submission/SOAPJMS/#binding-properties
> JMS Transport: Remove JNDI lookups for ConnectionFactory, targetDestination
> and replyDestination
> ------------------------------------------------------------------------------------------------
>
> Key: CXF-1774
> URL: https://issues.apache.org/jira/browse/CXF-1774
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.1.2
> Reporter: Christian Schneider
> Fix For: 2.2
>
>
> Currently you have to configure all jms settings via JNDI. targetDestination
> is the only config property that already can additionally be configured as a
> string.
> I think the JNDI stuff does not belong into the JMS transport.
> ConnectionFactory should simply be configured as a refrence to a bean of type
> jms ConnectionFactory. So the user of cxf is free to either setup the
> ConnectionFactory locally or look it up via Spring´s great JNDI support.
> The same is true for targetDestination and replyDestination. They should
> simply be injected. The JNDI logic should be deleted from JMS transport.
> Additionally it should be possible for targetDestination and replyDestination
> to set them as simple strings as this is the most common way they will be
> used by people.
> Fixing this will make the JMS Transport code simpler and at the same time the
> CXF users will get greater flexibility in the configuration.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
