[
https://issues.apache.org/jira/browse/QPID-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248226#comment-13248226
]
[email protected] commented on QPID-3401:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4658/#review6737
-----------------------------------------------------------
This looks like a good start, but I am rather concerned at the continued
complete lack of any unit tests for the destination code. Whilst a lot of the
clients destination handling issues have been related to the 'if BURL else'
control flows, there have still been numerous cases where it was things like
the Address string parser ("false" vs "False" for example) or the behaviour of
a particular part of the Addressing Syntax implementation that caused the
issues. This stuff is one of the most isolated and easily unit testable
segments of code the client will ever have, and it really needs to be
thoroughly unit tested to help ensure its correctness and more so to aid its
maintainability going forward.
This may be related to your mention of whitespace issues you couldn't get rid
of but some of the files are absolutely riddled with leading tabs, which I
thought ReviewBoard highlighted but it doesn't seem to be doing. "CTRL+A
CTRL+I" is your friend when using Eclipse (if you have the couple of
use-spaces-for-tabs type options set correctly).
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/DestinationStringParser.java
<https://reviews.apache.org/r/4658/#comment14702>
BURLs include support for setting various options much like the Address
strings, its not clear to me that this really supports them?
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java
<https://reviews.apache.org/r/4658/#comment14687>
Naming convention violation.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java
<https://reviews.apache.org/r/4658/#comment14689>
Would initialising this to the 'defaultDestSyntax' value directly above it
not make more sense?
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java
<https://reviews.apache.org/r/4658/#comment14688>
Unless there is a particular need, we should use getters to access these
rather than having the fields themselves protected.
Naming convention violations.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java
<https://reviews.apache.org/r/4658/#comment14690>
This would be better located neat the top of the file close to what it
statically initialises.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java
<https://reviews.apache.org/r/4658/#comment14691>
Its possibly time we had a constant somewhere for the BURL: and ADDR:
prefixes rather than using literals everywhere. It would make their usage
easier to navigate if nothing else.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidQueue.java
<https://reviews.apache.org/r/4658/#comment14695>
Requires a matching hashCode implementation.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidQueue.java
<https://reviews.apache.org/r/4658/#comment14701>
Should we really be catching all exceptions, or just the ones we expect to
occur? Is this something we would want to log?
If this is to handle the declared JMSException on the getQueueName()
implementation then perhaps we could just remove that, because the
implementation doesn't look like it can actually throw a JMSException.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryQueue.java
<https://reviews.apache.org/r/4658/#comment14692>
Naming convention
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java
<https://reviews.apache.org/r/4658/#comment14696>
Naming convention.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java
<https://reviews.apache.org/r/4658/#comment14693>
Remove commented out code?
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTopic.java
<https://reviews.apache.org/r/4658/#comment14694>
Requires a matching hashCode implementation.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/Address.java
<https://reviews.apache.org/r/4658/#comment14697>
Naming convention
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Link.java
<https://reviews.apache.org/r/4658/#comment14700>
Using 'protected' for a reason?
Naming convention.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Node.java
<https://reviews.apache.org/r/4658/#comment14699>
Using 'protected' for a reason?
- Robbie
On 2012-04-05 15:03:30, rajith attapattu wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/4658/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-04-05 15:03:30)
bq.
bq.
bq. Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, Rafael
Schloming, and Rob Godfrey.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. The following patch is based on the various discussions we've had on the
dev list about restructing our destination implementation.
bq. As the first phase this patch only includes the new class heirachy. For
the second phase we will tackle the integration into the code base.
bq.
bq. A summary of the desgin is as follows,
bq.
bq. 1. Once initialized with the destination string, the destination objects
are immutable.
bq. 2. There are 2 concrete implementations in the form of QpidTopic and
QpidQueue.
bq. 3. Destinations will be desginated as "Queues" and "Topics" by the users
in the jndi file. This prevents us from having to automagically decide the type.
bq. 4. Both BURL and Address strings are parsed and adapted into a common data
structure. Internally the code will work with this data structure.
bq. 5. The Destination impl does not depend on any other classes, thus
allowing it be used with the current code or the new client.
bq.
bq. (There are 2 oe 3 white space errors that I can't seem to get rid of. It
seems they are comming from the diff process).
bq.
bq.
bq. This addresses bug QPID-3401.
bq. https://issues.apache.org/jira/browse/QPID-3401
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/DestinationStringParser.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidQueue.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryQueue.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTopic.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/TemporaryDestinationProvider.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/Address.java
1309769
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/AddressException.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Link.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Node.java
PRE-CREATION
bq.
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/util/AddressHelper.java
PRE-CREATION
bq.
bq. Diff: https://reviews.apache.org/r/4658/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq.
bq. Thanks,
bq.
bq. rajith
bq.
bq.
> Refactor address resolution code
> --------------------------------
>
> Key: QPID-3401
> URL: https://issues.apache.org/jira/browse/QPID-3401
> Project: Qpid
> Issue Type: Improvement
> Components: Java Client
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Labels: addressing
> Fix For: Future
>
> Attachments: QPID-3401-systests.patch, QPID-3401.patch,
> class_diagram.png, model2.gif
>
>
> After some thought it seems that the following JIRA's would benefit from some
> reworking of the address resolution code as the original design had a few
> flaws based on incorrect understanding of the address syntax.
> QPID-3265
> QPID-3317
> QPID-3271
> The redesign would be minimal and not very disruptive. The goal is to fix
> certain design flaws in the current code, rather than a complete redesign. I
> am planning to reuse as much code as possible to ensure we don't throw away
> tested code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
