[jira] Updated: (WSCOMMONS-467) JMSSender executes unnecessary JNDI lookups

["Ruwan Linton (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WSCOMMONS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ruwan Linton updated WSCOMMONS-467:
-----------------------------------

    Fix Version/s:     (was: Transports 1.0)
                   Transports 1.1

I had a look at the issue, but I cannot find a straight forward fix for this... yet. It is true that in certain cases it leads to duplicate JNDI lookups but we cannot simply get rid of the JNDI lookup at the constructor since it affects some conditions.

Within this release time frame I will not be able to work on this, and hence we have to postpone this to 1.1 release.

> 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
>             Fix For: Transports 1.1
>
>
> 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.