Bug 711196 - Setting port / host / etc variables for connection factory doesn't do anything
Summary: Setting port / host / etc variables for connection factory doesn't do anything
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-java
Version: 1.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: messaging-bugs
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-06 19:22 UTC by Joel Tosi
Modified: 2021-03-16 12:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Joel Tosi 2011-06-06 19:22:30 UTC
Description of problem:
When creating a connection factory, you have the option of setting the connection information through setters or through the constructor with an AMQConnectionURL.  Using the setter methods isn't fully implemented in the sense that internal calls use the connectionDetails reference and this isn't updated when the setter methods are used. 

While working with a tool to write the information to LDAP, I encountered this issue as I was trying to dynamically provide the LDAP information piecemeal.

Version-Release number of selected component (if applicable):
1.3


How reproducible:
Create a AMQConnectionFactory object, set values using setter methods, then try binding to an LDAP context - this calls getReference which throws an NPE because it is looking at the local connectionDetails variable - which is of course null.  So using the setter methods doesn't matter at all.

Steps to Reproduce:
AMQConnectionFactory factory = new AMQConnectionFactory();
factory.setHost("someHost");
factory.setPort(11111);
factory.setDefaultUsername("username");
factory.setDefaultPassword("password");
factory.getReference().
  
Actual results:
NullPointerException

Expected results:
No NullPointerException, reference handled properly


Additional info:
I would be more than happy to provide a sample change if you are interested, just let me know.  It looks slightly hairy because of the prevelance of connectionDetails.  Perhaps not allow the setters and just go with the a ConnectionURL constructor and a multi-parameter constructor for building the URL?

Comment 1 Weston M. Price 2011-06-07 13:12:42 UTC
I agree that the setters should probably be removed as they make this class inherently unsafe. We should really require that a connection string be used all the time via the constructor and remove the other constructors as well.


Note You need to log in before you can comment on or make changes to this bug.