[
https://issues.apache.org/jira/browse/CXF-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627201#action_12627201
]
Christian Schneider commented on CXF-1774:
------------------------------------------
What I don´t like about the current code is that for example he JMSConduit
initializes its own configs in the init method. I think this should be done via
dependency injection. What I would imagine is a JMSConduit and JMSDestination
that does not actively load configurations or do JNDI lookups. If we need these
things inside the JMS transport code for WSDL support and non Spring configs we
should externalize it into a factory class.
So I would for example only leave the resolved targetDestination and
replyDestination inside JMSConduit. Then these could be flexibly injected by
different factory mechanismns. For example the JMSTransportFactory could
initialize the conduit based on URL parameters (like in Camel) or via a Conduit
configuration or from the WSDL.
I think the Spring config could also be improved. I don´t like that the Conduit
is configured separately from the Client or Endpoint. I would define things
like the ConnectionFactory in the Client config element perhaps in a jms
subelement. So it would be much easier for users to understand how to do it.
> 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.
