Github user tabish121 commented on a diff in the pull request:
https://github.com/apache/qpid-proton-j/pull/20#discussion_r234811453
--- Diff:
proton-j/src/main/java/org/apache/qpid/proton/codec/CompositeReadableBuffer.java
---
@@ -834,22 +834,39 @@ public boolean equals(Object
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-proton-j/pull/20
@franz1981 Looks good so far, would like to see the formatting changed to
match the remainder of the code. The reset is a good catch, that is a bug in
the current code
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/26
Yes, that test is exposing some issues in the 5.x broker which is unrelated
to this change.
---
-
To unsubscribe, e-mail: dev
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/23
Possible race in the test, seems unrelated
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/23
You should open a new JIRA to track this and use the JIRA entry in the
commit title in order to link the two. Refer to the commits in the log already
for a proper example
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/19
I spent some time reviewing netty code and getting a handle on how this
would change the current behavior. From what I can see this should be safe to
apply. The tests all pass from a local
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/17
You need to squash the commits and force push so that it is contained in
one commit, thanks.
---
-
To unsubscribe, e-mail
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/17
I believe the correct fix is to call PropertyUtil.parseQuery(remoteURI)
instead and it will do the right thing, although we can't know until you
provide some tests to validate
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/12
@michaelandrepearce
The Epoll warning has been reported to Netty a few days ago, see
[Issue:7120](https://github.com/netty/netty/issues/7120) which was reported by
someone using
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/12
Agree with @gemmellr on this, the checks are better provided to Netty for
inclusion in the next release so that they can be maintained and matured along
with the Epoll and KQueue implementations
Github user tabish121 commented on a diff in the pull request:
https://github.com/apache/qpid-jms/pull/9#discussion_r127257588
--- Diff:
qpid-jms-client/src/test/java/org/apache/qpid/jms/sasl/CramMD5MechanismTest.java
---
@@ -85,4 +115,21 @@ public String getName
Github user tabish121 commented on a diff in the pull request:
https://github.com/apache/qpid-jms/pull/9#discussion_r127257712
--- Diff:
qpid-jms-client/src/main/java/org/apache/qpid/jms/sasl/CramMD5Mechanism.java ---
@@ -86,6 +86,14 @@ public String getName
Github user tabish121 commented on a diff in the pull request:
https://github.com/apache/qpid-jms/pull/9#discussion_r127257449
--- Diff:
qpid-jms-client/src/test/java/org/apache/qpid/jms/sasl/AbstractScramSHAMechanismTestBase.java
---
@@ -137,4 +139,25 @@ public void
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-jms/pull/6
Agree with Robbie on this one, in general if your example requires more
than a couple minutes for the reader to digest then you start to lose them.
Syncing up with the other examples listed seems
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-proton-j/pull/6
Personally this doesn't seem a necessary addition to me. I prefer to keep
the management of the encoder and decoder instances in the Qpid JMS code and
wouldn't use this myself. It adds
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-proton-j/pull/5
@clebertsuconic while that may be true, since your initial PR didn't
reference either issue, none of that discussion gets logged into the JIRA which
is the bit you seem to be missing
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-proton-j/pull/5
Please follow the same recommendations that you'd make for someone
submitting a PR to Artemis. If you raise the PR with the JIRA key in the
title, a bot will raise a note against the JIRA
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-proton-j/pull/5
So you've created two JIRAs but only created one pull request on not
reference either JIRA in it?
---
If your project is set up for it, you can reply to this email and have your
reply
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-proton-j/pull/5
There seems to be changes in the MessageImpl that don't have anything to do
with the issue at hand and probably would deserve their own JIRA.
---
If your project is set up for it, you can
Github user tabish121 commented on the issue:
https://github.com/apache/qpid-proton/pull/82
Would suggest removing the author tags from the new files, they are
discouraged by the ASF
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user tabish121 commented on the pull request:
https://github.com/apache/qpid-jms/pull/2#issuecomment-204055703
I did add the BND plugin to proton-j recently in order to generate bundle
information in the next release, a review from someone more versed in OSGi
would be good
21 matches
Mail list logo
