QPID-3401 New class structure for address refactoring
Review Request #2366 - Created Oct. 12, 2011 and discarded
This patch contains the new class structure used for retrieving information from addressing and creating destinations and managing it's lifecycle. How this code is tied to the main client is illustrated with the patch put up for review at https://reviews.apache.org/r/2364/ A basic class diagram for this can be found here [ https://issues.apache.org/jira/secure/attachment/12498753/class_diagram.png ] In summary the goals are, =========================== 1. Provide a proper abstraction of Queue and Topic concepts 2. Provide an address format based implementation of Queue and Topic 3. Hide the implementatio of the life cycle of a destination (create, delete, createSubscription, deleteSubscription) 4. Create a top level AddressBasedDestination class (extending from AMQDestination), 4.1 To separate the address based details from AMQQueue, AMQTopic ..etc 4.2 To bridge btw the new code and the AMQDestination interface 4. Improve the code that retrievs data from an address (a.k.a AddressHelper) 5. Provide a fix for QPID-3265, QPID-3317, QPID-3271 6. Implement the above with minimum disruption to regular client code.
Changes are verified using the existing tests in AddressBasedDestinationTest.java I am planning to add more coverage and possibly refactor the above class to cover more cases with less code.
Posted (Oct. 13, 2011, 4:36 p.m.)
I assume this and similar mean resolveAddress? Also, is there any particular reason why you can't go ahead and attempt address resolution here? Or is this actually a case of an unresolvABLE address, when destination is null? In the client, resolveAddress, create and azzert would be called sequentially, normally, right?
Posted (Oct. 14, 2011, 4:17 p.m.)
There are a number of operations performed based on the Destination during client execution, e.g. during Consumer creation and closing, Producer creation and closing amongst others. Each of these might be implemented differently depending on the destination syntax and settings in use, and then further differences can emerge based on any protocol-specific requirements. Currently, everywhere differences relating to the syntax in use occur we generally have an if-else statement. This is not a maintainable implementation approach, and needs to be abstracted away by a common Destination model that allows grouping of syntax specific operations into separate classes rather than spreading decisions throughout the code. The design alterations here improve on some of the deficiencies of the previous implementation (e.g. the policy validation no longer being within the main session etc implementation code), but in other ways seems worse. For example, it appears to result in us having Destination implementations that are both syntax AND protocol specific, and which have, and require, intimate knowledge of the Session implementation. This does not seem like progress and still leaves us with all the if-else statements throughout the client. Also, it seems that as AddressBasedDestination is not abstract, it will now be possible for our Destination objects to contain a delegate which implement either the JMS Topic or Queue interfaces, but not implement it themselves. In order to eliminate the if-else statements for behaviour which varies depending on the destination syntax, we can isolate that code in specific delegate classes for use with Destination objects. Such delegates would implement a shared interface that declares the varying address related operations, and could exist for both BindingURL and Address based Destinations. The different behaviours could be contained within the destination delegates, however specific implementations of operations such as queue creation, queue deletion, subscription creation, would be would found within the protocol-specific session implementations that actually perform these operations. The class diagram at https://issues.apache.org/jira/secure/attachment/12499057/model2.gif depicts what some of such a Destination model would look like. AMQDestination would be refactored such that BindingURL specific functionality and Address specific functionality was moved to subclasses, with all 3 being abstract, and these used as the basis for implementations of the Queue and Topic interfaces specific to each URL syntax. Additionally, if would be nice to have immutable destination object in order to resolve current issues with thread safety which in turn will allow storing and reusing them via JNDI.