[
https://issues.apache.org/jira/browse/WSCOMMONS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707829#action_12707829
]
Andreas Veithen commented on WSCOMMONS-467:
-------------------------------------------
There is another issue (initially reported by Keith Bohnenberger [1]) which is
closely related: getJMSConnectionFactory supports the
transport.jms.ConnectionFactory so that one could use the following type of
endpoint reference:
jms:/dynamicQueues/SimpleStockQuoteService?transport.jms.ConnectionFactory=default
However, in that case the JMSOutTransportInfo constructor will fail because it
is unable to create the InitialContext (which it shouldn't try to do in the
first place).
[1] http://markmail.org/message/iex6jeo7liouzqd5
> JMSSender executes unnecessary JNDI lookups
> -------------------------------------------
>
> Key: WSCOMMONS-467
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-467
> Project: WS-Commons
> Issue Type: Bug
> Components: Transport
> Reporter: Andreas Veithen
> Priority: Minor
>
> JMSSender contains the following code:
> jmsOut = new JMSOutTransportInfo(targetAddress);
> // do we have a definition for a connection factory to use for this address?
> jmsConnectionFactory = getJMSConnectionFactory(jmsOut);
> if (jmsConnectionFactory != null) {
> messageSender = new JMSMessageSender(jmsConnectionFactory, targetAddress);
> } else {
> ...
> }
> The constructor of JMSOutTransportInfo will create a new InitialContext and
> lookup the destination from JNDI. If a connection factory definition is found
> (jmsConnectionFactory != null), this is unnecessary because the
> JMSMessageSender constructor will also create a new InitialContext (or reuse
> a cached one) and carry out the JNDI lookup again.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
