This seems to be resulting in segfaults running the tests on Windows:
https://ci.appveyor.com/project/ke4qqq/qpid-proton/build/0.10-SNAPSHOT-master.122
1: proton_tests.message.CodecTest.testRoundTrip
pass
1: proton_tests.message.CodecTest.testRoundTripWithTimes
I just ran a maven-only clean build locally with no problems.
You should have PN_MILLIS_MAX defined in
proton-j/src/main/resources/ctypes.py, and this should be imported from
proton-j/src/main/resources/cproton.py. Can you verify that this is as
expected?
--Rafael
On Mon, Jul 6, 2015 at 5:50
The recent changes on Proton-J seemed to have created some issues:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/1032/console
The module currently requries Java 7 to compile, which is a slightly
out of sync with the compiler source+target still being set to Java 6
(which the
On 07/06/2015 10:52 AM, Robbie Gemmell wrote:
This seems to be resulting in segfaults running the tests on Windows:
https://ci.appveyor.com/project/ke4qqq/qpid-proton/build/0.10-SNAPSHOT-master.122
1: proton_tests.message.CodecTest.testRoundTrip
pass
1:
[
https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-927:
---
Assignee: (was: Gordon Sim)
The new test was reported to have segfaulted on windows:
[
https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-927:
--
Fix Version/s: (was: 0.10)
absolute-expiry-time and creation-time are encoded as 0 if not set
Were you running it after having previously used the cmake build in
the same terminal?
I do indeed have the definition in ctypes, with the cproton file
importing everything from ctypes. The maven build failed when I ran it
directly in my git-clean'ed checkout. It then passed when run
indirectly
Can you try doing an mvn clean and seeing if it is still an issue?
A class entirely missing like that is usually due to mvn not recompiling
everything that is impacted by a given change.
--Rafael
On Mon, Jul 6, 2015 at 8:11 AM, Gordon Sim g...@redhat.com wrote:
All the ProtonJInterop tests
On 07/06/2015 11:04 AM, Gordon Sim wrote:
On 07/06/2015 10:52 AM, Robbie Gemmell wrote:
This seems to be resulting in segfaults running the tests on Windows:
https://ci.appveyor.com/project/ke4qqq/qpid-proton/build/0.10-SNAPSHOT-master.122
1: proton_tests.message.CodecTest.testRoundTrip
All the ProtonJInterop tests fail for me, and the python-test then
hangs. The error for each is something like:
2: proton_tests.reactor_interop.ReactorInteropTest. \
2: Error: Could not find or load main class
org.apache.qpid.proton.ProtonJInterop
2: test_protonc_to_protonj_1
[
https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14614915#comment-14614915
]
ASF subversion and git services commented on PROTON-927:
Commit
That seemed to do the trick. Running the maven build in a clean
checkout in clean terminal now works, so long as you use a version of
Java able to build the recent source; the compilation issue is still
there otherwise:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-c/
Can you do a git pull and give it another shot?
I believe what is happening is that when maven launches the jython tests,
it doesn't seem to include the jython shim in the class path. For some
reason, this isn't an issue of the .class files that jython generates are
hanging around in the source
On 07/06/2015 01:24 PM, Rafael Schloming wrote:
Can you try doing an mvn clean and seeing if it is still an issue?
I see the same thing after mvn clean
On 6 July 2015 at 14:17, Gordon Sim g...@redhat.com wrote:
On 07/06/2015 01:24 PM, Rafael Schloming wrote:
Can you try doing an mvn clean and seeing if it is still an issue?
I see the same thing after mvn clean
Does cleaning the checkout as a whole make any difference?
To preview what
Is this change allowing clients to skip the SASL layer when connecting
to servers that have enabled the SASL layer? If so, how is the new
default behaviour disabled?
The existing but unimplemented 'allowSkip' method previously intended
to enable such behaviour still doesn't do anything, so is
Andrew Stitcher created PROTON-934:
--
Summary: Build tests fail if Java is not available
Key: PROTON-934
URL: https://issues.apache.org/jira/browse/PROTON-934
Project: Qpid Proton
Issue
[
https://issues.apache.org/jira/browse/PROTON-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-201:
---
Assignee: Cliff Jansen (was: Andrew Stitcher)
Provide a C++ Messenger and Message class
[
https://issues.apache.org/jira/browse/PROTON-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14615592#comment-14615592
]
ASF subversion and git services commented on PROTON-933:
Commit
On Mon, 2015-07-06 at 11:30 -0400, Rafael Schloming wrote:
I wired in allowSkip in a very minimal way just to restore the ability to
force the old behaviour. It would be a fairly trivial to change the name of
course,
I'm not sure if that really applies as the method is on a different
object
On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really should be a compile time
exception, which
I think means you must have stale class files *somewhere*. You
could try
doing a find checkout -name *.class
On 6 July 2015 at 16:51, Andrew Stitcher astitc...@redhat.com wrote:
On Mon, 2015-07-06 at 11:30 -0400, Rafael Schloming wrote:
I wired in allowSkip in a very minimal way just to restore the ability to
force the old behaviour. It would be a fairly trivial to change the name of
course,
I'm
On Mon, 2015-07-06 at 13:14 -0400, Andrew Stitcher wrote:
On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
...
The old toggle only used to define whether sasl was required or not
(which it historically was once you enabled the sasl layer, and the
toggle was never implemented in
Andrew Stitcher created PROTON-933:
--
Summary: Cyrus SASL GSSAPI plugin can error if sent long buffers.
Key: PROTON-933
URL: https://issues.apache.org/jira/browse/PROTON-933
Project: Qpid Proton
[
https://issues.apache.org/jira/browse/PROTON-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-933.
Resolution: Fixed
Fix Version/s: 0.10
Cyrus SASL GSSAPI plugin can error if sent
[
https://issues.apache.org/jira/browse/PROTON-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14615620#comment-14615620
]
Andrew Stitcher commented on PROTON-201:
[~cliffjansen], I believe this is
On 6 July 2015 at 18:14, Andrew Stitcher astitc...@redhat.com wrote:
On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
...
The old toggle only used to define whether sasl was required or not
(which it historically was once you enabled the sasl layer, and the
toggle was never
On 6 July 2015 at 16:48, Gordon Sim g...@redhat.com wrote:
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really should be a compile time exception, which
I think means you must have stale class files *somewhere*. You could try
doing a find checkout -name *.class
On Mon, 2015-07-06 at 17:31 +0100, Gordon Sim wrote:
On 07/06/2015 05:22 PM, aconway wrote:
On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really should be a compile time
exception, which
I think
FWIW, my changes in this area really represent the minimum diff necessary
to get the reactor branch to land. None of this is related to the reactor
changes per se, it just so happens the reactor tests include several tests
that check interop between proton-c and proton-j and these tests keep
On 06/07/15 12:35 -0400, Ken Giusti wrote:
Hi all,
I remember recently that there was a rumor that we may be able to start the
release of 0.10 at the end of june.
Now that my july 4th long weekend has worn off - what's left to be done before
we can cut an alpha?
Yup, I shot a request and
On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
...
The old toggle only used to define whether sasl was required or not
(which it historically was once you enabled the sasl layer, and the
toggle was never implemented in proton-j), whereas IIRC the new
'requireAuth' governs that but
Hi all,
I remember recently that there was a rumor that we may be able to start the
release of 0.10 at the end of june.
Now that my july 4th long weekend has worn off - what's left to be done before
we can cut an alpha?
--
-K
On 6 July 2015 at 18:24, aconway acon...@redhat.com wrote:
On Mon, 2015-07-06 at 17:31 +0100, Gordon Sim wrote:
On 07/06/2015 05:22 PM, aconway wrote:
On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really
On 07/06/2015 05:22 PM, aconway wrote:
On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote:
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really should be a compile time
exception, which
I think means you must have stale class files *somewhere*. You
could try
doing
+1
The only issue that has me worried here is the sasl interop story between
proton-c and proton-j. I can cut a release later today just to give us
something to poke at, but there may still be sasl work needed.
--Rafael
On Mon, Jul 6, 2015 at 9:57 AM, Flavio Percoco fla...@redhat.com wrote:
On 6 July 2015 at 18:28, Andrew Stitcher astitc...@redhat.com wrote:
On Mon, 2015-07-06 at 13:14 -0400, Andrew Stitcher wrote:
On Mon, 2015-07-06 at 17:48 +0100, Robbie Gemmell wrote:
...
The old toggle only used to define whether sasl was required or not
(which it historically was once
I'd like to see something in the release to do with the session
outgoing-window problems that mean the new JMS client can't currently
send to ServiceBus.
As mentioend elsewhere earlier, a very basic change that leaves the
current default behaviour as it stands but would enable me to
configure the
On Mon, 2015-07-06 at 11:28 -0700, Rafael Schloming wrote:
+1
The only issue that has me worried here is the sasl interop story between
proton-c and proton-j. I can cut a release later today just to give us
something to poke at, but there may still be sasl work needed.
I have a blocking fix
On 6 July 2015 at 18:57, Rafael Schloming r...@alum.mit.edu wrote:
FWIW, my changes in this area really represent the minimum diff necessary
to get the reactor branch to land. None of this is related to the reactor
changes per se,
Yes, it almost seems like a change in default behaviour of a
As promised, here is the first alpha for 0.10. It's posted in the usual
places:
Source code is here:
http://people.apache.org/~rhs/qpid-proton-0.10-alpha1/
Java binaries are here:
https://repository.apache.org/content/repositories/orgapacheqpid-1036
Please check it out and follow up
[
https://issues.apache.org/jira/browse/PROTON-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14615189#comment-14615189
]
ASF subversion and git services commented on PROTON-925:
Commit
[
https://issues.apache.org/jira/browse/PROTON-930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14615190#comment-14615190
]
ASF subversion and git services commented on PROTON-930:
Commit
On 07/06/2015 04:08 PM, Rafael Schloming wrote:
Any sort of missing class really should be a compile time exception, which
I think means you must have stale class files *somewhere*. You could try
doing a find checkout -name *.class just as a sanity check.
I have deleted all the .class files
On Mon, Jul 6, 2015 at 9:52 AM, Robbie Gemmell robbie.gemm...@gmail.com
wrote:
Is this change allowing clients to skip the SASL layer when connecting
to servers that have enabled the SASL layer? If so, how is the new
default behaviour disabled?
Yes, it was necessary to allow the tests to
Github user ted-ross commented on the pull request:
https://github.com/apache/qpid-proton/pull/39#issuecomment-118902728
I'd like to see this pull request move forward. On Dan's points above:
1) I agree with Andrew that using __LINE__ as an error code should be
changed to
I wired in allowSkip in a very minimal way just to restore the ability to
force the old behaviour. It would be a fairly trivial to change the name of
course, however it appears there are a bunch of other related changes that
go along with it, e.g. adding a bunch of accessors and fixing the error
Any sort of missing class really should be a compile time exception, which
I think means you must have stale class files *somewhere*. You could try
doing a find checkout -name *.class just as a sanity check. Also, it's
possible something in your local maven repo is somehow coming into play,
maybe
On 07/06/2015 02:23 PM, Robbie Gemmell wrote:
On 6 July 2015 at 14:17, Gordon Sim g...@redhat.com wrote:
On 07/06/2015 01:24 PM, Rafael Schloming wrote:
Can you try doing an mvn clean and seeing if it is still an issue?
I see the same thing after mvn clean
Does cleaning the checkout as
49 matches
Mail list logo
