[jira] [Commented] (QPID-4591) mechanism to detect when messages are overwritten in ring-type queues
[ https://issues.apache.org/jira/browse/QPID-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666050#comment-13666050 ] Robbie Gemmell commented on QPID-4591: -- New python tests excluded from runs against the Java broker in http://svn.apache.org/r1485953 mechanism to detect when messages are overwritten in ring-type queues - Key: QPID-4591 URL: https://issues.apache.org/jira/browse/QPID-4591 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: 0.18 Reporter: Ernest Allen Assignee: Gordon Sim Fix For: Future Attachments: bz691411.patch1 A way to determine when a ring queue is full and old messages are being deleted. Also need a way to determine when the ring queue is no longer full. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4591) mechanism to detect when messages are overwritten in ring-type queues
[ https://issues.apache.org/jira/browse/QPID-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666094#comment-13666094 ] Gordon Sim commented on QPID-4591: -- (oops, sorry Robbie!) mechanism to detect when messages are overwritten in ring-type queues - Key: QPID-4591 URL: https://issues.apache.org/jira/browse/QPID-4591 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: 0.18 Reporter: Ernest Allen Assignee: Gordon Sim Fix For: Future Attachments: bz691411.patch1 A way to determine when a ring queue is full and old messages are being deleted. Also need a way to determine when the ring queue is no longer full. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4591) mechanism to detect when messages are overwritten in ring-type queues
[ https://issues.apache.org/jira/browse/QPID-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666125#comment-13666125 ] Robbie Gemmell commented on QPID-4591: -- Not to worry, only noticed this morning that they were failing as we had previously broken the test job itself :) mechanism to detect when messages are overwritten in ring-type queues - Key: QPID-4591 URL: https://issues.apache.org/jira/browse/QPID-4591 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: 0.18 Reporter: Ernest Allen Assignee: Gordon Sim Fix For: Future Attachments: bz691411.patch1 A way to determine when a ring queue is full and old messages are being deleted. Also need a way to determine when the ring queue is no longer full. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release 0.22
I don't really object to including this. Can we have someone with batch script skills take a quick look at it? Justin On Thu, May 23, 2013 at 6:28 PM, Oleksandr Rudyy oru...@gmail.com wrote: Justin, I hope it is still not too late to request the inclusion into 0.22 of a minor fix for Windows batch script to start Java Broker ( http://svn.apache.org/r1485859 QPID-4881). We introduced new command line arguments requiring to pass an equal character as part of the argument but the batch script splits the command line argument with 'equal' into two arguments and removes equal character. Such arguments have to be quoted but processing of quoted arguments resulted in the errors. The changes fixed the processing of quoted arguments. It is a minor issue and there are some workarounds but I would like to request the inclusion of the fix as it is quite trivial. Kind Regards, Alex On 23 May 2013 22:40, Ken Giusti kgiu...@redhat.com wrote: Justin, A new RC, you say? Well, I'll just leave this little tidbit here, ya know, just in case: https://issues.apache.org/jira/browse/QPID-4883 /backs slowly away from my keyboard - Original Message - From: Justin Ross jr...@apache.org To: dev@qpid.apache.org Sent: Thursday, May 23, 2013 10:34:58 AM Subject: Re: [VOTE] Release 0.22 This vote is withdrawn. We'll have a new RC later today. The only new change will be the cmake build fix. Once that's available, I'll start a new vote thread. Justin On Wed, May 22, 2013 at 5:14 PM, Justin Ross jr...@apache.org wrote: Okay, we'll fix it tomorrow. On May 22, 2013 4:09 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, May 22, 2013 at 01:54:50PM -0400, Justin Ross wrote: RC5 contains the proposed final bits for Qpid 0.22. If you favor making the RC5 bits into our official release, vote +1. If you have reason to believe RC5 is not ready for release, vote -1. I will close this vote on Monday, 22 May. I know that's a little brief, but I have some vacation time coming up soon, and I'm hoping to finish the release before I leave. The patches for 4344 were applied in reverse on this branch and, with the last cherry-pick, the bindings/CMakeLists.txt broke the CMake changes. The conditional check for Swig 1.3.32 is still in the file and needs to be deleted to fix CMake. This is totally my fault. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4883) C++ Broker may crash if client provides SSL certificate without CommonName entry.
[ https://issues.apache.org/jira/browse/QPID-4883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666186#comment-13666186 ] Justin Ross commented on QPID-4883: --- Reviewed by Gordon. Approved for 0.22. C++ Broker may crash if client provides SSL certificate without CommonName entry. - Key: QPID-4883 URL: https://issues.apache.org/jira/browse/QPID-4883 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.23 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.23 Broker does not check for a null pointer return value from the Certificate parsing routines. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4855) [AMQP 1.0] compilation error on older compilers
[ https://issues.apache.org/jira/browse/QPID-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666202#comment-13666202 ] Justin Ross commented on QPID-4855: --- I asked Gordon to merge this to the 0.22 branch. The change is minimal, and it fixes a build failure on rhel 5, still in wide use. Approved for 0.22. [AMQP 1.0] compilation error on older compilers --- Key: QPID-4855 URL: https://issues.apache.org/jira/browse/QPID-4855 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.23 E.g. Description of problem: [ 41%] Building CXX object src/CMakeFiles/amqpc.dir/qpid/messaging/amqp/ConnectionHandle.o cd /builddir/build/BUILD/qpid-0.22/cpp/src /usr/bin/c++ -Damqpc_EXPORTS -DHAVE_CONFIG_H -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -O2 -g -fPIC -I/builddir/build/BUILD/qpid-0.22/cpp/src -I/builddir/build/BUILD/qpid-0.22/cpp/src/../include -pthread -I/usr/usr/include -o CMakeFiles/amqpc.dir/qpid/messaging/amqp/ConnectionHandle.o -c /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/ConnectionHandle.cpp cc1plus: warnings being treated as errors /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory: In destructor 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::Sasl]': /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:42: instantiated from 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::messaging::amqp::Sasl]' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:58: instantiated from here /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: possible problem detected in invocation of delete operator: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: invalid use of undefined type 'struct qpid::Sasl' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:29: warning: forward declaration of 'struct qpid::Sasl' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined. /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory: In destructor 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::sys::SecurityLayer]': /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:42: instantiated from 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::messaging::amqp::Sasl]' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:58: instantiated from here /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: possible problem detected in invocation of delete operator: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: invalid use of undefined type 'struct qpid::sys::SecurityLayer' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:31: warning: forward declaration of 'struct qpid::sys::SecurityLayer' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined. make[2]: *** [src/CMakeFiles/amqpc.dir/qpid/messaging/amqp/ConnectionContext.o] Error 1 make[2]: *** Waiting for unfinished jobs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[VOTE] Subversion to JIRA integration
Hi all, As some of you will already know, a mail was sent to committers@a.o earlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [ ] No [ ] PROTON: Yes [ ] No [ ] Robbie
Re: [VOTE] Subversion to JIRA integration
On 05/24/2013 12:03 PM, Robbie Gemmell wrote: Hi all, As some of you will already know, a mail was sent to committers@a.o earlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [X] No [ ] - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Subversion to JIRA integration
QPID: Yes [X ] No [ ] PROTON: Yes [ X] No [ ] On Fri, May 24, 2013 at 7:03 AM, Robbie Gemmell robbie.gemm...@gmail.comwrote: Hi all, As some of you will already know, a mail was sent to committers@a.oearlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [ ] No [ ] PROTON: Yes [ ] No [ ] Robbie
[jira] [Updated] (QPID-4855) [AMQP 1.0] compilation error on older compilers
[ https://issues.apache.org/jira/browse/QPID-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated QPID-4855: - Fix Version/s: (was: 0.23) 0.22 Merged to 0.22: http://svn.apache.org/viewvc?view=revisionrevision=1486009 [AMQP 1.0] compilation error on older compilers --- Key: QPID-4855 URL: https://issues.apache.org/jira/browse/QPID-4855 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.22 E.g. Description of problem: [ 41%] Building CXX object src/CMakeFiles/amqpc.dir/qpid/messaging/amqp/ConnectionHandle.o cd /builddir/build/BUILD/qpid-0.22/cpp/src /usr/bin/c++ -Damqpc_EXPORTS -DHAVE_CONFIG_H -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -O2 -g -fPIC -I/builddir/build/BUILD/qpid-0.22/cpp/src -I/builddir/build/BUILD/qpid-0.22/cpp/src/../include -pthread -I/usr/usr/include -o CMakeFiles/amqpc.dir/qpid/messaging/amqp/ConnectionHandle.o -c /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/ConnectionHandle.cpp cc1plus: warnings being treated as errors /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory: In destructor 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::Sasl]': /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:42: instantiated from 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::messaging::amqp::Sasl]' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:58: instantiated from here /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: possible problem detected in invocation of delete operator: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: invalid use of undefined type 'struct qpid::Sasl' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:29: warning: forward declaration of 'struct qpid::Sasl' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined. /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory: In destructor 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::sys::SecurityLayer]': /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:42: instantiated from 'std::auto_ptr_Tp::~auto_ptr() [with _Tp = qpid::messaging::amqp::Sasl]' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:58: instantiated from here /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: possible problem detected in invocation of delete operator: /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: warning: invalid use of undefined type 'struct qpid::sys::SecurityLayer' /builddir/build/BUILD/qpid-0.22/cpp/src/qpid/messaging/amqp/Sasl.h:31: warning: forward declaration of 'struct qpid::sys::SecurityLayer' /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/memory:259: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined. make[2]: *** [src/CMakeFiles/amqpc.dir/qpid/messaging/amqp/ConnectionContext.o] Error 1 make[2]: *** Waiting for unfinished jobs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 4
Some of the issues you raise will be addressed in an upcoming update mail, so I won't address them here. On Sun, May 19, 2013 at 9:00 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: I think it was Jakub who previously mentioned the lack of links to trunk documentation. I too find their absence noticable as they are the only documentation links I tend to use outside of testing the releases. 15 minutes after I wrote that, I just accidentally came across links to trunk documentation for the Java broker and Programming (but not C++ broker) books hidden away in More Resources, taking me on to the next point which I wrote before this sentence existed. I like the idea of trunk documentation, but only if it's actually something kept up to date. I left the links to the Java broker and Programming books because I know you want them, but the others are currently more often stale than fresh. Once we do have nightly builds for the docs, I'm all in favor of this. Linking the above points together it might also be nice to have a 'nightly release' page. We generate nightly builds for the Java components and push out the maven artifacts to the snapshots repo, doing the equivalent for all the components would probably help improve the release process if we made it easier for people to test things whenever they like rather than always waiting for the next RC to drop before discovering things aren't as expected. For now, I've left this as a small section under More Resources. That's simply because at this point we don't have enough content there for it to merit its own page. Send me the specifics for the snapshot repo, and I'll work them in. It would be my preference to treat trunk documentation as just another kind of nightly build, with a prominent section next to other nightly artifacts and a link from the documentation page. I noticed several links out to the wiki, e.g: From the developers page: https://cwiki.apache.org/qpid/qpid-project-etiquette-guide.html From the source code page: https://cwiki.apache.org/qpid/getting-started-guide.html From the Java Broker component page 'features': https://cwiki.apache.org/qpid/configure-operational-status-logging.html https://cwiki.apache.org/qpid/configure-broker-and-client-heartbeating.html https://cwiki.apache.org/qpid/configure-the-virtual-hosts-via-virtualhostsxml.html From the Java Broker component page 'documentation' : https://cwiki.apache.org/qpid/qpid-java-build-how-to.html https://cwiki.apache.org/qpid/getting-started-guide.html https://cwiki.apache.org/qpid/qpid-java-faq.html https://cwiki.apache.org/qpid/qpid-troubleshooting-guide.html https://cwiki.apache.org/qpid/java-broker-design.html https://cwiki.apache.org/qpid/qpid-java-documentation.html The content from some of these has been on the main website for years, others are now part of the source controlled documentation, and most of them are partially or entirely out of date. I think we should avoid linking out to the wiki where possible, particularly for end user documentation. It disrupts the flow of using the site, looks pretty poor in comparison, is often kind of slow, and is mostly out of date at this point. We have been and should continue to look to get as much of the actual user documentation we consider current into the source-controlled documentation we keep to help ensure it is kept relevant to the specific releases, rather than collect lots of cruft that will go stale the way the old wiki based site clearly has over the years. I would like to see us finish transitioning any remaining useful user documentation that remains only on the wiki over to the website or source controlled docs and then pretty much entirely nuke the wiki from orbit and proceed with only the things it makes sense to keep there. Then if we are linking out to wiki content I would probably link to the actual wiki itself and not the transformed HTML copy of it (which we should probably get deleted some day to clear out old stale pages since it doesn't seem to remove things when you delete wiki pages). This is interesting. I have been operating from the other side of this, thinking the next thing I would turn to is cleaning up the content of the wiki and making it more presentable. I like the wiki for developer documents well enough, and I don't mind being the one who owns the problem of keeping the wiki in shape. For user documentation, I agree. Indeed, most of the user doc is tied to a release and belongs under source control. In general, I've tried to link out to the wiki (or jira) for user documentation only when I couldn't find the equivalent information in the formal docs. Any corrections would be very much appreciated, now, or in the future when content is migrated. I had a quick look at the source and had a couple of questions: Am I right in thinking you now need to perform 2 generation steps to get from the docbook source to having output that can be put
Re: [VOTE] Subversion to JIRA integration
QPID: Yes [X ] No [ ] PROTON: Yes [ X] No [ ] On 24 May 2013 12:03, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi all, As some of you will already know, a mail was sent to committers@a.oearlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [ ] No [ ] PROTON: Yes [ ] No [ ] Robbie
[jira] [Commented] (QPID-4881) [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows)
[ https://issues.apache.org/jira/browse/QPID-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666224#comment-13666224 ] Robbie Gemmell commented on QPID-4881: -- Updated docs/help to use quotes for the argument, as will be required in Windows when using qpid-server.bat: http://svn.apache.org/r1486017 [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows) -- Key: QPID-4881 URL: https://issues.apache.org/jira/browse/QPID-4881 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.22, 0.23 Reporter: Keith Wall Assignee: Alex Rudyy Priority: Minor Attachments: broket-batch-script-fixes.diff Trying to use a command such using the new argument fails in the following manner. Y:\src\qpid\qpid\java\build.\bin\qpid-server.bat --initial-config-path Y:\ha_test\config.json --config-property nodenum=5 Warning: Qpid classpath not set. CLASSPATH set to Y:\src\qpid\qpid\java\build\li b\qpid-all.jar;Y:\src\qpid\qpid\java\build\lib\plugins\*;Y:\src\qpid\qpid\java\build\lib\opt\* Info: QPID_JAVA_GC not set. Defaulting to JAVA_GC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError Info: QPID_JAVA_MEM not set. Defaulting to JAVA_MEM -Xmx1024m Exception during startup: java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum at org.apache.qpid.server.Main.execute(Main.java:226) at org.apache.qpid.server.Main.init(Main.java:134) at org.apache.qpid.server.Main.main(Main.java:125) Y:\src\qpid\qpid\java\build It appears to be related to the processing of the argument list by the qpid-server.bat file. It is choking on arguments containing =. User can workaround by providing the property values as system properties (e.g via QPID_OPTS: set QPID_OPTS=-Dname=value), or by invoking the Main class directly without the qpid-server.bat script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4881) [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows)
[ https://issues.apache.org/jira/browse/QPID-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-4881: - Summary: [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows) (was: New --config-property argument cannot be used with qpid-server.bat (windows)) [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows) -- Key: QPID-4881 URL: https://issues.apache.org/jira/browse/QPID-4881 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.22, 0.23 Reporter: Keith Wall Assignee: Alex Rudyy Priority: Minor Attachments: broket-batch-script-fixes.diff Trying to use a command such using the new argument fails in the following manner. Y:\src\qpid\qpid\java\build.\bin\qpid-server.bat --initial-config-path Y:\ha_test\config.json --config-property nodenum=5 Warning: Qpid classpath not set. CLASSPATH set to Y:\src\qpid\qpid\java\build\li b\qpid-all.jar;Y:\src\qpid\qpid\java\build\lib\plugins\*;Y:\src\qpid\qpid\java\build\lib\opt\* Info: QPID_JAVA_GC not set. Defaulting to JAVA_GC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError Info: QPID_JAVA_MEM not set. Defaulting to JAVA_MEM -Xmx1024m Exception during startup: java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum at org.apache.qpid.server.Main.execute(Main.java:226) at org.apache.qpid.server.Main.init(Main.java:134) at org.apache.qpid.server.Main.main(Main.java:125) Y:\src\qpid\qpid\java\build It appears to be related to the processing of the argument list by the qpid-server.bat file. It is choking on arguments containing =. User can workaround by providing the property values as system properties (e.g via QPID_OPTS: set QPID_OPTS=-Dname=value), or by invoking the Main class directly without the qpid-server.bat script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release 0.22
I had a look and it seems reasonable, fixing the issue to the extent possible without substantial change and no apparent impact in other usage of the script which was tested. Windows users will need to quote the value, so I have committed another tiny change to update the docs/help to reflect that. Robbie On 24 May 2013 11:40, Justin Ross justin.r...@gmail.com wrote: I don't really object to including this. Can we have someone with batch script skills take a quick look at it? Justin On Thu, May 23, 2013 at 6:28 PM, Oleksandr Rudyy oru...@gmail.com wrote: Justin, I hope it is still not too late to request the inclusion into 0.22 of a minor fix for Windows batch script to start Java Broker ( http://svn.apache.org/r1485859 QPID-4881). We introduced new command line arguments requiring to pass an equal character as part of the argument but the batch script splits the command line argument with 'equal' into two arguments and removes equal character. Such arguments have to be quoted but processing of quoted arguments resulted in the errors. The changes fixed the processing of quoted arguments. It is a minor issue and there are some workarounds but I would like to request the inclusion of the fix as it is quite trivial. Kind Regards, Alex On 23 May 2013 22:40, Ken Giusti kgiu...@redhat.com wrote: Justin, A new RC, you say? Well, I'll just leave this little tidbit here, ya know, just in case: https://issues.apache.org/jira/browse/QPID-4883 /backs slowly away from my keyboard - Original Message - From: Justin Ross jr...@apache.org To: dev@qpid.apache.org Sent: Thursday, May 23, 2013 10:34:58 AM Subject: Re: [VOTE] Release 0.22 This vote is withdrawn. We'll have a new RC later today. The only new change will be the cmake build fix. Once that's available, I'll start a new vote thread. Justin On Wed, May 22, 2013 at 5:14 PM, Justin Ross jr...@apache.org wrote: Okay, we'll fix it tomorrow. On May 22, 2013 4:09 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, May 22, 2013 at 01:54:50PM -0400, Justin Ross wrote: RC5 contains the proposed final bits for Qpid 0.22. If you favor making the RC5 bits into our official release, vote +1. If you have reason to believe RC5 is not ready for release, vote -1. I will close this vote on Monday, 22 May. I know that's a little brief, but I have some vacation time coming up soon, and I'm hoping to finish the release before I leave. The patches for 4344 were applied in reverse on this branch and, with the last cherry-pick, the bindings/CMakeLists.txt broke the CMake changes. The conditional check for Swig 1.3.32 is still in the file and needs to be deleted to fix CMake. This is totally my fault. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4881) [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows)
[ https://issues.apache.org/jira/browse/QPID-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666229#comment-13666229 ] Justin Ross commented on QPID-4881: --- Reviewed by Robbie. Approved for 0.22. [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows) -- Key: QPID-4881 URL: https://issues.apache.org/jira/browse/QPID-4881 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.22, 0.23 Reporter: Keith Wall Assignee: Alex Rudyy Priority: Minor Attachments: broket-batch-script-fixes.diff Trying to use a command such using the new argument fails in the following manner. Y:\src\qpid\qpid\java\build.\bin\qpid-server.bat --initial-config-path Y:\ha_test\config.json --config-property nodenum=5 Warning: Qpid classpath not set. CLASSPATH set to Y:\src\qpid\qpid\java\build\li b\qpid-all.jar;Y:\src\qpid\qpid\java\build\lib\plugins\*;Y:\src\qpid\qpid\java\build\lib\opt\* Info: QPID_JAVA_GC not set. Defaulting to JAVA_GC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError Info: QPID_JAVA_MEM not set. Defaulting to JAVA_MEM -Xmx1024m Exception during startup: java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum at org.apache.qpid.server.Main.execute(Main.java:226) at org.apache.qpid.server.Main.init(Main.java:134) at org.apache.qpid.server.Main.main(Main.java:125) Y:\src\qpid\qpid\java\build It appears to be related to the processing of the argument list by the qpid-server.bat file. It is choking on arguments containing =. User can workaround by providing the property values as system properties (e.g via QPID_OPTS: set QPID_OPTS=-Dname=value), or by invoking the Main class directly without the qpid-server.bat script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4881) [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows)
[ https://issues.apache.org/jira/browse/QPID-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666249#comment-13666249 ] Alex Rudyy commented on QPID-4881: -- The batch and documentation/help fixes (r1485859, r1486017) are merged into 0.22 branch in revisions http://svn.apache.org/r1486029 and http://svn.apache.org/r1486031 accordingly. [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows) -- Key: QPID-4881 URL: https://issues.apache.org/jira/browse/QPID-4881 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.22, 0.23 Reporter: Keith Wall Assignee: Alex Rudyy Priority: Minor Attachments: broket-batch-script-fixes.diff Trying to use a command such using the new argument fails in the following manner. Y:\src\qpid\qpid\java\build.\bin\qpid-server.bat --initial-config-path Y:\ha_test\config.json --config-property nodenum=5 Warning: Qpid classpath not set. CLASSPATH set to Y:\src\qpid\qpid\java\build\li b\qpid-all.jar;Y:\src\qpid\qpid\java\build\lib\plugins\*;Y:\src\qpid\qpid\java\build\lib\opt\* Info: QPID_JAVA_GC not set. Defaulting to JAVA_GC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError Info: QPID_JAVA_MEM not set. Defaulting to JAVA_MEM -Xmx1024m Exception during startup: java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum at org.apache.qpid.server.Main.execute(Main.java:226) at org.apache.qpid.server.Main.init(Main.java:134) at org.apache.qpid.server.Main.main(Main.java:125) Y:\src\qpid\qpid\java\build It appears to be related to the processing of the argument list by the qpid-server.bat file. It is choking on arguments containing =. User can workaround by providing the property values as system properties (e.g via QPID_OPTS: set QPID_OPTS=-Dname=value), or by invoking the Main class directly without the qpid-server.bat script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4881) [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows)
[ https://issues.apache.org/jira/browse/QPID-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-4881. -- Resolution: Fixed Fix Version/s: 0.22 [Java Broker] new --config-property argument cannot be used with qpid-server.bat (windows) -- Key: QPID-4881 URL: https://issues.apache.org/jira/browse/QPID-4881 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.22, 0.23 Reporter: Keith Wall Assignee: Alex Rudyy Priority: Minor Fix For: 0.22 Attachments: broket-batch-script-fixes.diff Trying to use a command such using the new argument fails in the following manner. Y:\src\qpid\qpid\java\build.\bin\qpid-server.bat --initial-config-path Y:\ha_test\config.json --config-property nodenum=5 Warning: Qpid classpath not set. CLASSPATH set to Y:\src\qpid\qpid\java\build\li b\qpid-all.jar;Y:\src\qpid\qpid\java\build\lib\plugins\*;Y:\src\qpid\qpid\java\build\lib\opt\* Info: QPID_JAVA_GC not set. Defaulting to JAVA_GC -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError Info: QPID_JAVA_MEM not set. Defaulting to JAVA_MEM -Xmx1024m Exception during startup: java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum java.lang.IllegalArgumentException: Configuration property argument is not of the format name=value: nodenum at org.apache.qpid.server.Main.execute(Main.java:226) at org.apache.qpid.server.Main.init(Main.java:134) at org.apache.qpid.server.Main.main(Main.java:125) Y:\src\qpid\qpid\java\build It appears to be related to the processing of the argument list by the qpid-server.bat file. It is choking on arguments containing =. User can workaround by providing the property values as system properties (e.g via QPID_OPTS: set QPID_OPTS=-Dname=value), or by invoking the Main class directly without the qpid-server.bat script. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release 0.22
The batch and doc/hep changes have been merged into 0.22 branch. On 24 May 2013 12:40, Robbie Gemmell robbie.gemm...@gmail.com wrote: I had a look and it seems reasonable, fixing the issue to the extent possible without substantial change and no apparent impact in other usage of the script which was tested. Windows users will need to quote the value, so I have committed another tiny change to update the docs/help to reflect that. Robbie On 24 May 2013 11:40, Justin Ross justin.r...@gmail.com wrote: I don't really object to including this. Can we have someone with batch script skills take a quick look at it? Justin On Thu, May 23, 2013 at 6:28 PM, Oleksandr Rudyy oru...@gmail.com wrote: Justin, I hope it is still not too late to request the inclusion into 0.22 of a minor fix for Windows batch script to start Java Broker ( http://svn.apache.org/r1485859 QPID-4881). We introduced new command line arguments requiring to pass an equal character as part of the argument but the batch script splits the command line argument with 'equal' into two arguments and removes equal character. Such arguments have to be quoted but processing of quoted arguments resulted in the errors. The changes fixed the processing of quoted arguments. It is a minor issue and there are some workarounds but I would like to request the inclusion of the fix as it is quite trivial. Kind Regards, Alex On 23 May 2013 22:40, Ken Giusti kgiu...@redhat.com wrote: Justin, A new RC, you say? Well, I'll just leave this little tidbit here, ya know, just in case: https://issues.apache.org/jira/browse/QPID-4883 /backs slowly away from my keyboard - Original Message - From: Justin Ross jr...@apache.org To: dev@qpid.apache.org Sent: Thursday, May 23, 2013 10:34:58 AM Subject: Re: [VOTE] Release 0.22 This vote is withdrawn. We'll have a new RC later today. The only new change will be the cmake build fix. Once that's available, I'll start a new vote thread. Justin On Wed, May 22, 2013 at 5:14 PM, Justin Ross jr...@apache.org wrote: Okay, we'll fix it tomorrow. On May 22, 2013 4:09 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, May 22, 2013 at 01:54:50PM -0400, Justin Ross wrote: RC5 contains the proposed final bits for Qpid 0.22. If you favor making the RC5 bits into our official release, vote +1. If you have reason to believe RC5 is not ready for release, vote -1. I will close this vote on Monday, 22 May. I know that's a little brief, but I have some vacation time coming up soon, and I'm hoping to finish the release before I leave. The patches for 4344 were applied in reverse on this branch and, with the last cherry-pick, the bindings/CMakeLists.txt broke the CMake changes. The conditional check for Swig 1.3.32 is still in the file and needs to be deleted to fix CMake. This is totally my fault. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Subversion to JIRA integration
QPID: Yes [ X ] No [ ] PROTON: Yes [ X ] No [ ] -- Rob On 24 May 2013 13:03, Robbie Gemmell robbie.gemm...@gmail.com wrote: Hi all, As some of you will already know, a mail was sent to committers@a.oearlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [ ] No [ ] PROTON: Yes [ ] No [ ] Robbie
Re: Website update 4
On 24 May 2013 13:30, Justin Ross justin.r...@gmail.com wrote: Some of the issues you raise will be addressed in an upcoming update mail, so I won't address them here. On Sun, May 19, 2013 at 9:00 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: [.. snip ..] I had a quick look at the source and had a couple of questions: Am I right in thinking you now need to perform 2 generation steps to get from the docbook source to having output that can be put up on the site? This seems a little cumbersome, especially given the current single generation step seems to make people too lazy to publish their changes on the site as it is (though I guess we should just get around to automating this with a build on the ASF Buildbot instances and link to that). Sort of. In general, for release content, there's a special generation step. That's really a per-release task, however, not something that many developers would typically do. The idea is that the release manager would do the generation with each new release. I've spent a good deal of time to make this easy (much easier than it's been in the past), probably because it's one of the jobs I've had to do with each release. Also, I guess I should say that the two steps are easily collapsed: make gen-release RELEASE=0.22 render. Trunk documentation would, as you suggest, best be solved by automated builds. So I'm at a bit of a loss as to why a two step document generation process would be a good idea. Is there something that is now being done that cannot be done using the docbook - html XSL transforms? I'm not the greatest fan of docbook, but adding in a secondary transform on top of an existing transform seems a little odd. If docbook cannot give us the output we need, why are we still using docbook? -- Rob
Re: [VOTE] Subversion to JIRA integration
QPID: Yes [x ] No [ ] On Fri, May 24, 2013 at 7:03 AM, Robbie Gemmell robbie.gemm...@gmail.comwrote: Hi all, As some of you will already know, a mail was sent to committers@a.oearlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [ ] No [ ] PROTON: Yes [ ] No [ ] Robbie
Issue collectors
Right now, the experience for users attempting to raise a jira isn't great. The create jira link fails and asks you to sign up for an account. I'd like to consider dropping that requirement. Jira offers issue collectors as a way to provide anonymous issue reporting. If you drill down to the add issue collector UI in our instance, you get the following warnings: Issues in this project can be viewed by anonymous users. Issue collectors allow for issues to be created anonymously. This means your JIRA instance could be abused by a spammer who can create issues that are available publicly. That's a good point. I think it's worth trying, and we can disable it if spam becomes a problem. (And I wonder if there's a captcha somewhere in there.) If your JIRA instance is not accessible via the public internet feel free to ignore this message. Otherwise it is recommended that you update this project's permissions such that anonymous users are not allowed to browse issues. What do you think they mean by the otherwise, disable anonymous browsing part? Initially this didn't make sense to me. Now I figure this is meant for private orgs with a jira instance on the public internet, which wouldn't apply to us. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4884) [AMQP 1.0] segfault when using x-declare within a node
Gordon Sim created QPID-4884: Summary: [AMQP 1.0] segfault when using x-declare within a node Key: QPID-4884 URL: https://issues.apache.org/jira/browse/QPID-4884 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 4
On Fri, May 24, 2013 at 8:37 AM, Rob Godfrey Sort of. In general, for release content, there's a special generation step. That's really a per-release task, however, not something that many developers would typically do. The idea is that the release manager would do the generation with each new release. I've spent a good deal of time to make this easy (much easier than it's been in the past), probably because it's one of the jobs I've had to do with each release. Also, I guess I should say that the two steps are easily collapsed: make gen-release RELEASE=0.22 render. Trunk documentation would, as you suggest, best be solved by automated builds. So I'm at a bit of a loss as to why a two step document generation process would be a good idea. Is there something that is now being done that cannot be done using the docbook - html XSL transforms? I'm not the greatest fan of docbook, but adding in a secondary transform on top of an existing transform seems a little odd. If docbook cannot give us the output we need, why are we still using docbook? Agreed about docbook; I'm not a fan, and I'd love to move away from it. It's more like an import step. The docbook content is (sensibly) maintained under the main qpid source tree. The web content is (sensibly) maintained under the website source. On the website, we fuse the two together for the release docs, mating the website template (with its navigation) to the body html from docbook. Indeed, I favor removing the site template stuff from the docbook scripts under the qpid source tree. I currently scrub it out. There's another less important reason. Docbook generates lousy html, so I sanitize it (to xhtml) to make things like link checking work nicely. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4885) C++ examples install to the wrong location
Darryl L. Pierce created QPID-4885: -- Summary: C++ examples install to the wrong location Key: QPID-4885 URL: https://issues.apache.org/jira/browse/QPID-4885 Project: Qpid Issue Type: Bug Components: Build Tools Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce The files all install to /usr[/local]/share/examples, but should install to /usr[/local]/share/qpid/examples -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 4
On Fri, May 24, 2013 at 8:56 AM, Justin Ross justin.r...@gmail.com wrote: On Fri, May 24, 2013 at 8:37 AM, Rob Godfrey Sort of. In general, for release content, there's a special generation step. That's really a per-release task, however, not something that many developers would typically do. The idea is that the release manager would do the generation with each new release. I've spent a good deal of time to make this easy (much easier than it's been in the past), probably because it's one of the jobs I've had to do with each release. Also, I guess I should say that the two steps are easily collapsed: make gen-release RELEASE=0.22 render. Trunk documentation would, as you suggest, best be solved by automated builds. So I'm at a bit of a loss as to why a two step document generation process would be a good idea. Is there something that is now being done that cannot be done using the docbook - html XSL transforms? I'm not the greatest fan of docbook, but adding in a secondary transform on top of an existing transform seems a little odd. If docbook cannot give us the output we need, why are we still using docbook? Agreed about docbook; I'm not a fan, and I'd love to move away from it. Markdown is a more friendly (and less clunky format) and the doc is readable on it's own. There ware ways to convert docbook to Markdown. So maybe we should look at that option. What do u think ? It's more like an import step. The docbook content is (sensibly) maintained under the main qpid source tree. The web content is (sensibly) maintained under the website source. On the website, we fuse the two together for the release docs, mating the website template (with its navigation) to the body html from docbook. Indeed, I favor removing the site template stuff from the docbook scripts under the qpid source tree. I currently scrub it out. There's another less important reason. Docbook generates lousy html, so I sanitize it (to xhtml) to make things like link checking work nicely. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 4
That's something I have looked at a little. I intend to do a deeper investigation after 0.22 and the big site update. On Fri, May 24, 2013 at 9:28 AM, Rajith Attapattu rajit...@gmail.com wrote: On Fri, May 24, 2013 at 8:56 AM, Justin Ross justin.r...@gmail.com wrote: On Fri, May 24, 2013 at 8:37 AM, Rob Godfrey Sort of. In general, for release content, there's a special generation step. That's really a per-release task, however, not something that many developers would typically do. The idea is that the release manager would do the generation with each new release. I've spent a good deal of time to make this easy (much easier than it's been in the past), probably because it's one of the jobs I've had to do with each release. Also, I guess I should say that the two steps are easily collapsed: make gen-release RELEASE=0.22 render. Trunk documentation would, as you suggest, best be solved by automated builds. So I'm at a bit of a loss as to why a two step document generation process would be a good idea. Is there something that is now being done that cannot be done using the docbook - html XSL transforms? I'm not the greatest fan of docbook, but adding in a secondary transform on top of an existing transform seems a little odd. If docbook cannot give us the output we need, why are we still using docbook? Agreed about docbook; I'm not a fan, and I'd love to move away from it. Markdown is a more friendly (and less clunky format) and the doc is readable on it's own. There ware ways to convert docbook to Markdown. So maybe we should look at that option. What do u think ? It's more like an import step. The docbook content is (sensibly) maintained under the main qpid source tree. The web content is (sensibly) maintained under the website source. On the website, we fuse the two together for the release docs, mating the website template (with its navigation) to the body html from docbook. Indeed, I favor removing the site template stuff from the docbook scripts under the qpid source tree. I currently scrub it out. There's another less important reason. Docbook generates lousy html, so I sanitize it (to xhtml) to make things like link checking work nicely. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
RE: [VOTE] Subversion to JIRA integration
QPID Yes [X] No [ ] PROTON: Yes [X] No [ ] -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: Friday, May 24, 2013 7:04 AM To: dev@qpid.apache.org; pro...@qpid.apache.org Subject: [VOTE] Subversion to JIRA integration Hi all, As some of you will already know, a mail was sent to committers@a.o earlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [ ] No [ ] PROTON: Yes [ ] No [ ] Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Subversion to JIRA integration
On Fri, May 24, 2013 at 12:03:32PM +0100, Robbie Gemmell wrote: Hi all, As some of you will already know, a mail was sent to committers@a.o earlier outlining some of the newer services ASF infra offer that we may not know about. One in particular stuck out for me, a service to populate JIRAs with information about relavant commits to Subversion or Git. I have always missed the Subversion integration within JIRA since it had to be disabled (it seemingly doesn't work very well with repositories of the size found at the ASF), so I would love to get something back in this area. You can find the details here: http://www.apache.org/dev/svngit2jira.html I would like to request this for both the QPID and PROTON JIRA instances. They indicate they would like agreement before enabling it, as unlike the older integration it generates a bit of traffic by actually posting comments on the JIRAs, so please vote now: QPID: Yes [X] No [ ] PROTON: Yes [X] No [ ] I had this in a previous project with our TRAC/Subversion integrated and it was very nice. It's nice to be able to go from a ticket to the commit(s) associated with it and see what's going on. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgppagp0CTZJ0.pgp Description: PGP signature
Re: [VOTE] Subversion to JIRA integration
QPID: Yes [X] No [ ] - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4886) Pass non-const reference to Message in QueueObserver functions.
Alan Conway created QPID-4886: - Summary: Pass non-const reference to Message in QueueObserver functions. Key: QPID-4886 URL: https://issues.apache.org/jira/browse/QPID-4886 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: 0.23 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.23 The HA plugin needs to modify a message in QueueObserver::enqueued to attach a HA ID to it. Other plugins may need to similarly annotate messages at QueueObserver call points. Need to remove the const qualifier for Message arguments to QueueObserver methods to enable this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4875) [Java] The parsing logic for certificate subjects doesn't work properly in all cases
[
https://issues.apache.org/jira/browse/QPID-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666337#comment-13666337
]
Michal Zerola commented on QPID-4875:
-
Hello,
I have created the patch which integrates the functionality from SSLUtil and
ExternalSaslServer into the new static method of SSLUtil:
*public static String getIdFromSubject(String subject)*
At the same time I have implemented DN parsing which fixes the problem with
e.g. injected CN inside OU field.
Please take a look at the attached patch.
Thanks,
Michal
[Java] The parsing logic for certificate subjects doesn't work properly in
all cases
Key: QPID-4875
URL: https://issues.apache.org/jira/browse/QPID-4875
Project: Qpid
Issue Type: Bug
Components: Java Broker, Java Client, Java Common
Reporter: JAkub Scholz
Priority: Minor
Fix For: Future
Attachments: cert_parsing.patch
The Java code seems to contain two places where the certificate subjects are
being parsed. One is used in the client:
{{common/src/main/java/org/apache/qpid/transport/network/security/ssl/SSLUtil.java}}
and the second is used in the broker:
{{broker/src/main/java/org/apache/qpid/server/security/auth/sasl/external/ExternalSaslServer.java}}
Both are actually doing the same - extracting the CN and DC components from
the subject and creating the username. It should be reconsidered whether we
want to reuse the SSLUtil functionality from the common part of the code in
the broker code as well.
However, a bigger problem is that the implementation in both places are not
working correctly in all situations. One can very easily create a certificate
with a subject / DN like this:
{{C=FR,O=SUNGARD,OU=CLEARVISION CN=GLKXV_GLKXVALBBDBGEN1}}
such certificate actually doesn't contain a CN. But both current
implementations will still identify the CN as {{GLKXV_GLKXVALBBDBGEN1}} in
the code. I would expect that this will happen only in very rare cases, but
it should still be handled properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4687) Add uninstall make target to cmake build
[ https://issues.apache.org/jira/browse/QPID-4687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-4687. --- Resolution: Fixed Fix Version/s: (was: 0.22) 0.23 Fixed in r1463202 Add uninstall make target to cmake build Key: QPID-4687 URL: https://issues.apache.org/jira/browse/QPID-4687 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.22 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.23 Add an uninstall target to remove files installed by the install target. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4875) [Java] The parsing logic for certificate subjects doesn't work properly in all cases
[
https://issues.apache.org/jira/browse/QPID-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
JAkub Scholz updated QPID-4875:
---
Description:
The Java code seems to contain two places where the certificate subjects are
being parsed. One is used in the client:
{{common/src/main/java/org/apache/qpid/transport/network/security/ssl/SSLUtil.java}}
and the second is used in the broker:
{{broker/src/main/java/org/apache/qpid/server/security/auth/sasl/external/ExternalSaslServer.java}}
Both are actually doing the same - extracting the CN and DC components from the
subject and creating the username. It should be reconsidered whether we want to
reuse the SSLUtil functionality from the common part of the code in the broker
code as well.
However, a bigger problem is that the implementation in both places are not
working correctly in all situations. One can very easily create a certificate
with a subject / DN like this:
{{C=CZ,O=Scholz,OU=JAKUB CN=USER1}}
such certificate actually doesn't contain a CN. But both current
implementations will still identify the CN as {{USER1}} in the code. I would
expect that this will happen only in very rare cases, but it should still be
handled properly.
was:
The Java code seems to contain two places where the certificate subjects are
being parsed. One is used in the client:
{{common/src/main/java/org/apache/qpid/transport/network/security/ssl/SSLUtil.java}}
and the second is used in the broker:
{{broker/src/main/java/org/apache/qpid/server/security/auth/sasl/external/ExternalSaslServer.java}}
Both are actually doing the same - extracting the CN and DC components from the
subject and creating the username. It should be reconsidered whether we want to
reuse the SSLUtil functionality from the common part of the code in the broker
code as well.
However, a bigger problem is that the implementation in both places are not
working correctly in all situations. One can very easily create a certificate
with a subject / DN like this:
{{C=CR,O=Scholz,OU=JAKUB CN=USER1}}
such certificate actually doesn't contain a CN. But both current
implementations will still identify the CN as {{USER1}} in the code. I would
expect that this will happen only in very rare cases, but it should still be
handled properly.
[Java] The parsing logic for certificate subjects doesn't work properly in
all cases
Key: QPID-4875
URL: https://issues.apache.org/jira/browse/QPID-4875
Project: Qpid
Issue Type: Bug
Components: Java Broker, Java Client, Java Common
Reporter: JAkub Scholz
Priority: Minor
Fix For: Future
Attachments: cert_parsing.patch
The Java code seems to contain two places where the certificate subjects are
being parsed. One is used in the client:
{{common/src/main/java/org/apache/qpid/transport/network/security/ssl/SSLUtil.java}}
and the second is used in the broker:
{{broker/src/main/java/org/apache/qpid/server/security/auth/sasl/external/ExternalSaslServer.java}}
Both are actually doing the same - extracting the CN and DC components from
the subject and creating the username. It should be reconsidered whether we
want to reuse the SSLUtil functionality from the common part of the code in
the broker code as well.
However, a bigger problem is that the implementation in both places are not
working correctly in all situations. One can very easily create a certificate
with a subject / DN like this:
{{C=CZ,O=Scholz,OU=JAKUB CN=USER1}}
such certificate actually doesn't contain a CN. But both current
implementations will still identify the CN as {{USER1}} in the code. I would
expect that this will happen only in very rare cases, but it should still be
handled properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: QPID-4886: Pass non-const reference to Message in QueueObserver functions.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/ --- Review request for qpid, Gordon Sim and Kenneth Giusti. Description --- QPID-4886: Pass non-const reference to Message in QueueObserver functions. The HA plugin needs to modify a message in QueueObserver::enqueued to attach a HA ID to it. Other plugins may need to similarly annotate messages at QueueObserver call points. Need to remove the const qualifier for Message arguments to QueueObserver methods to enable this. Diffs - /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.h 1486017 /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.h 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueObserver.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.h 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueReplicator.cpp 1486017 Diff: https://reviews.apache.org/r/11378/diff/ Testing --- make test Thanks, Alan Conway
Re: Review Request: QPID-4886: Pass non-const reference to Message in QueueObserver functions.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/#review20996 --- This makes me a little nervous, specifically around modification while the message is being concurrently read by some other thread. At present the observers are only called from queue while lock is held but can we rule out any other concurrent access? Having the queue be the only place where the message can be modified (modifications elsewhere requiring a copy) seems like a good practice. With regard to annotations, the observeEnqueue() method is only called after the message has been written to disk, so any modifications at that point would certainly not be durable. - Gordon Sim On May 24, 2013, 2:16 p.m., Alan Conway wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/ --- (Updated May 24, 2013, 2:16 p.m.) Review request for qpid, Gordon Sim and Kenneth Giusti. Description --- QPID-4886: Pass non-const reference to Message in QueueObserver functions. The HA plugin needs to modify a message in QueueObserver::enqueued to attach a HA ID to it. Other plugins may need to similarly annotate messages at QueueObserver call points. Need to remove the const qualifier for Message arguments to QueueObserver methods to enable this. Diffs - /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.h 1486017 /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.h 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueObserver.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.h 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueReplicator.cpp 1486017 Diff: https://reviews.apache.org/r/11378/diff/ Testing --- make test Thanks, Alan Conway
Re: Review Request: QPID-4886: Pass non-const reference to Message in QueueObserver functions.
On May 24, 2013, 2:35 p.m., Gordon Sim wrote: This makes me a little nervous, specifically around modification while the message is being concurrently read by some other thread. At present the observers are only called from queue while lock is held but can we rule out any other concurrent access? Having the queue be the only place where the message can be modified (modifications elsewhere requiring a copy) seems like a good practice. With regard to annotations, the observeEnqueue() method is only called after the message has been written to disk, so any modifications at that point would certainly not be durable. Perhaps a better solution would be to have a new callback for things outside the queue that wish to modify the message. This can be done at specific points (before writing to disk and before making it available to consumers) that are easier to reason about with regard to concurrent access. What do you think? Would that work for your case? - Gordon --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/#review20996 --- On May 24, 2013, 2:16 p.m., Alan Conway wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/ --- (Updated May 24, 2013, 2:16 p.m.) Review request for qpid, Gordon Sim and Kenneth Giusti. Description --- QPID-4886: Pass non-const reference to Message in QueueObserver functions. The HA plugin needs to modify a message in QueueObserver::enqueued to attach a HA ID to it. Other plugins may need to similarly annotate messages at QueueObserver call points. Need to remove the const qualifier for Message arguments to QueueObserver methods to enable this. Diffs - /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.h 1486017 /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.h 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueObserver.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.h 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueReplicator.cpp 1486017 Diff: https://reviews.apache.org/r/11378/diff/ Testing --- make test Thanks, Alan Conway
Re: Review Request: QPID-4886: Pass non-const reference to Message in QueueObserver functions.
On May 24, 2013, 2:35 p.m., Gordon Sim wrote: This makes me a little nervous, specifically around modification while the message is being concurrently read by some other thread. At present the observers are only called from queue while lock is held but can we rule out any other concurrent access? Having the queue be the only place where the message can be modified (modifications elsewhere requiring a copy) seems like a good practice. With regard to annotations, the observeEnqueue() method is only called after the message has been written to disk, so any modifications at that point would certainly not be durable. Gordon Sim wrote: Perhaps a better solution would be to have a new callback for things outside the queue that wish to modify the message. This can be done at specific points (before writing to disk and before making it available to consumers) that are easier to reason about with regard to concurrent access. What do you think? Would that work for your case? +1 something like Gordon's suggestion - if possible. The notion that an Observer can actually modify in addition to simply observing isn't intuitive and overloads the original intent more than I think it should. - Kenneth --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/#review20996 --- On May 24, 2013, 2:16 p.m., Alan Conway wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/ --- (Updated May 24, 2013, 2:16 p.m.) Review request for qpid, Gordon Sim and Kenneth Giusti. Description --- QPID-4886: Pass non-const reference to Message in QueueObserver functions. The HA plugin needs to modify a message in QueueObserver::enqueued to attach a HA ID to it. Other plugins may need to similarly annotate messages at QueueObserver call points. Need to remove the const qualifier for Message arguments to QueueObserver methods to enable this. Diffs - /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.h 1486017 /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.h 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueObserver.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.h 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueReplicator.cpp 1486017 Diff: https://reviews.apache.org/r/11378/diff/ Testing --- make test Thanks, Alan Conway
[jira] [Resolved] (QPID-4885) C++ examples install to the wrong location
[ https://issues.apache.org/jira/browse/QPID-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved QPID-4885. Resolution: Fixed Fix Version/s: 0.23 Fixed the install directory. C++ examples install to the wrong location -- Key: QPID-4885 URL: https://issues.apache.org/jira/browse/QPID-4885 Project: Qpid Issue Type: Bug Components: Build Tools Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.23 The files all install to /usr[/local]/share/examples, but should install to /usr[/local]/share/qpid/examples -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 4
On 24 May 2013 12:30, Justin Ross justin.r...@gmail.com wrote: Some of the issues you raise will be addressed in an upcoming update mail, so I won't address them here. On Sun, May 19, 2013 at 9:00 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: I think it was Jakub who previously mentioned the lack of links to trunk documentation. I too find their absence noticable as they are the only documentation links I tend to use outside of testing the releases. 15 minutes after I wrote that, I just accidentally came across links to trunk documentation for the Java broker and Programming (but not C++ broker) books hidden away in More Resources, taking me on to the next point which I wrote before this sentence existed. I like the idea of trunk documentation, but only if it's actually something kept up to date. I left the links to the Java broker and Programming books because I know you want them, but the others are currently more often stale than fresh. Once we do have nightly builds for the docs, I'm all in favor of this. Linking the above points together it might also be nice to have a 'nightly release' page. We generate nightly builds for the Java components and push out the maven artifacts to the snapshots repo, doing the equivalent for all the components would probably help improve the release process if we made it easier for people to test things whenever they like rather than always waiting for the next RC to drop before discovering things aren't as expected. For now, I've left this as a small section under More Resources. That's simply because at this point we don't have enough content there for it to merit its own page. Part of me think that if we had a page that looked a bit bare then maybe we would be better about putting more stuff on it when people see it and wonder where the missing bits are. Hiding it away where people won't see it gives less incentive and also means that the stuff that already is there won't get used to the extent it could. Send me the specifics for the snapshot repo, and I'll work them in. https://repository.apache.org/content/repositories/snapshots/ It would be my preference to treat trunk documentation as just another kind of nightly build, with a prominent section next to other nightly artifacts and a link from the documentation page. I was thinking along the lines of 'nightly release' page(s)...such that by the time it comes to the point to release the component(s) it should to some extent effectively be a case of making a copy of what has already been published previously for the component(s). I noticed several links out to the wiki, e.g: From the developers page: https://cwiki.apache.org/qpid/qpid-project-etiquette-guide.html From the source code page: https://cwiki.apache.org/qpid/getting-started-guide.html From the Java Broker component page 'features': https://cwiki.apache.org/qpid/configure-operational-status-logging.html https://cwiki.apache.org/qpid/configure-broker-and-client-heartbeating.html https://cwiki.apache.org/qpid/configure-the-virtual-hosts-via-virtualhostsxml.html From the Java Broker component page 'documentation' : https://cwiki.apache.org/qpid/qpid-java-build-how-to.html https://cwiki.apache.org/qpid/getting-started-guide.html https://cwiki.apache.org/qpid/qpid-java-faq.html https://cwiki.apache.org/qpid/qpid-troubleshooting-guide.html https://cwiki.apache.org/qpid/java-broker-design.html https://cwiki.apache.org/qpid/qpid-java-documentation.html The content from some of these has been on the main website for years, others are now part of the source controlled documentation, and most of them are partially or entirely out of date. I think we should avoid linking out to the wiki where possible, particularly for end user documentation. It disrupts the flow of using the site, looks pretty poor in comparison, is often kind of slow, and is mostly out of date at this point. We have been and should continue to look to get as much of the actual user documentation we consider current into the source-controlled documentation we keep to help ensure it is kept relevant to the specific releases, rather than collect lots of cruft that will go stale the way the old wiki based site clearly has over the years. I would like to see us finish transitioning any remaining useful user documentation that remains only on the wiki over to the website or source controlled docs and then pretty much entirely nuke the wiki from orbit and proceed with only the things it makes sense to keep there. Then if we are linking out to wiki content I would probably link to the actual wiki itself and not the transformed HTML copy of it (which we should probably get deleted some day to clear out old stale pages since it doesn't seem to remove things when you delete wiki pages). This is interesting. I have been operating from the other side of
Re: [VOTE] Subversion to JIRA integration
On Fri, 2013-05-24 at 12:03 +0100, Robbie Gemmell wrote: ... I also note it'd be nice to get the info in there retrospectively too. Andrew QPID: Yes [ X ] No [ ] PROTON: Yes [ X ] No [ ] Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Issue collectors
On Fri, 2013-05-24 at 08:46 -0400, Justin Ross wrote: ... If your JIRA instance is not accessible via the public internet feel free to ignore this message. Otherwise it is recommended that you update this project's permissions such that anonymous users are not allowed to browse issues. What do you think they mean by the otherwise, disable anonymous browsing part? Initially this didn't make sense to me. Now I figure this is meant for private orgs with a jira instance on the public internet, which wouldn't apply to us. I think what they're talking about here is the motivation for blog spam - search engine optimisation. So if a spammer can post a bug, and it is anonymously available on the internet then it can be found by search engines and push whatever URL they are trying to drive traffic to. Or at least this is my understanding of why spammers try to post links to blogs etc. So if the url isn't publicly available then there is no point in the posting in the first place from their pov. In this vein it might make sense to not allow anonymously posted bugs to be available anonymously. Anyone have any other understanding(s)? Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 4
On Fri, May 24, 2013 at 11:05 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: Part of me think that if we had a page that looked a bit bare then maybe we would be better about putting more stuff on it when people see it and wonder where the missing bits are. Hiding it away where people won't see it gives less incentive and also means that the stuff that already is there won't get used to the extent it could. Okay, I'll split it out. It would be my preference to treat trunk documentation as just another kind of nightly build, with a prominent section next to other nightly artifacts and a link from the documentation page. I was thinking along the lines of 'nightly release' page(s)...such that by the time it comes to the point to release the component(s) it should to some extent effectively be a case of making a copy of what has already been published previously for the component(s). Okay, that seems like a fine approach. For what it's worth, it's a little annoying from the scripting standpoint because you need to conditionally link to trunk or a branch, and you need to conditionalize other stuff as well, such as download links. Right now the scripts count on there being tags in svn and artifacts up on dist. But that's not the big piece of work. To really make a nightly release look just like a numbered release, we have a fair bit of work to do yet to automate builds. I might be the exception, but when I bother myself to write new docs I tend to want them on the site and publish them immediately. There's no blocking problem with doing this. The trunk docs can be generated and pushed in a different fashion. There's no terribly great need to add the site nav around the trunk docs, though I agree it would be nice once the above mentioned scripting is sorted out. Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Website update 5
http://people.apache.org/~jross/transom/2013-05-24/ Previous versions: Update 4: http://people.apache.org/~jross/transom/2013-05-10/ http://qpid.2158936.n2.nabble.com/Website-update-4-tt7592756.html Update 3: http://people.apache.org/~jross/transom/2013-04-16/ http://qpid.2158936.n2.nabble.com/Website-update-3-tt7591573.html Update 2: http://people.apache.org/~jross/transom/2013-04-03/ http://qpid.2158936.n2.nabble.com/Website-update-2-tt7591046.html Update 1: http://people.apache.org/~jross/transom/2013-03-26/ http://qpid.2158936.n2.nabble.com/Website-update-tt7590444.html Head version: http://people.apache.org/~jross/transom/head/ Bigger changes: - Added a top-level documentation index - Eased navigation from the more resources page - Added a compatibility matrix to the component index - Added a nightly builds section to more resources - Adjusted font sizes down another step - Moved JCA under APIs instead of servers and tools - Added more help text to the list subscribe tables - Refreshed the active committers list - Restored books to chunked output - Added more ways to contribute to the get involved page Thanks for your continued feedback! Justin - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Subversion to JIRA integration
QPID: Yes [X] No [ ] PROTON: Yes [X] No [ ] -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Website update 5
On Fri, 2013-05-24 at 11:38 -0400, Justin Ross wrote: http://people.apache.org/~jross/transom/2013-05-24/ On the C++ broker page it may be worth mentioning experimental JMS style selectors (in 0.22, improved in 0.24, not compatible with the actual qpid JMS implementation yet though). Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4888) [AMQP 1.0] link naming is not handled correctly
Gordon Sim created QPID-4888: Summary: [AMQP 1.0] link naming is not handled correctly Key: QPID-4888 URL: https://issues.apache.org/jira/browse/QPID-4888 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.23 The client does not let the name of the link be controlled, but always defaults it to the name of the node (which doesn't meet uniqueness criteria). The broker uses the link-, source- and target- names as the key to the managment objects and uses the link- and source- name for subscriptions queues when the source refers to an exchange. The link name is only guaranteed to be unique within the scope of a clients container id. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4884) [AMQP 1.0] segfault when using x-declare within a node
[ https://issues.apache.org/jira/browse/QPID-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-4884. -- Resolution: Fixed Fixed by http://svn.apache.org/viewvc?view=revisionrevision=1486113 [AMQP 1.0] segfault when using x-declare within a node -- Key: QPID-4884 URL: https://issues.apache.org/jira/browse/QPID-4884 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.23 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4888) [AMQP 1.0] link naming is not handled correctly
[ https://issues.apache.org/jira/browse/QPID-4888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-4888. -- Resolution: Fixed Fixed by http://svn.apache.org/viewvc?view=revisionrevision=1486115 [AMQP 1.0] link naming is not handled correctly --- Key: QPID-4888 URL: https://issues.apache.org/jira/browse/QPID-4888 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.22 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.23 The client does not let the name of the link be controlled, but always defaults it to the name of the node (which doesn't meet uniqueness criteria). The broker uses the link-, source- and target- names as the key to the managment objects and uses the link- and source- name for subscriptions queues when the source refers to an exchange. The link name is only guaranteed to be unique within the scope of a clients container id. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4889) Swig descriptors are installed twice
Darryl L. Pierce created QPID-4889: -- Summary: Swig descriptors are installed twice Key: QPID-4889 URL: https://issues.apache.org/jira/browse/QPID-4889 Project: Qpid Issue Type: Bug Components: Build Tools Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce The following swig descriptor files are installed: mcpierce@mcpierce-laptop:x86_64 (master) $ rpm -ql qpid-cpp-client-devel | grep \.i /usr/include/qmf/qmf2.i /usr/include/qmf/qmfengine.i /usr/include/qpid/qpid.i /usr/include/qpid/swig_perl_typemaps.i /usr/include/qpid/swig_python_typemaps.i /usr/include/qpid/swig_ruby_typemaps.i /usr/share/qpid/qpid/qpid.i /usr/share/qpid/qpid/swig_perl_typemaps.i /usr/share/qpid/qpid/swig_python_typemaps.i /usr/share/qpid/qpid/swig_ruby_typemaps.i As can be seen, the files installed to /usr/share/qpid are not needed since tehy're already provided under /usr/include/qpid. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: QPID-4886: Pass non-const reference to Message in QueueObserver functions.
On May 24, 2013, 2:35 p.m., Gordon Sim wrote: This makes me a little nervous, specifically around modification while the message is being concurrently read by some other thread. At present the observers are only called from queue while lock is held but can we rule out any other concurrent access? Having the queue be the only place where the message can be modified (modifications elsewhere requiring a copy) seems like a good practice. With regard to annotations, the observeEnqueue() method is only called after the message has been written to disk, so any modifications at that point would certainly not be durable. Gordon Sim wrote: Perhaps a better solution would be to have a new callback for things outside the queue that wish to modify the message. This can be done at specific points (before writing to disk and before making it available to consumers) that are easier to reason about with regard to concurrent access. What do you think? Would that work for your case? Kenneth Giusti wrote: +1 something like Gordon's suggestion - if possible. The notion that an Observer can actually modify in addition to simply observing isn't intuitive and overloads the original intent more than I think it should. Agreed, I'll post an updated approach. - Alan --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/#review20996 --- On May 24, 2013, 2:16 p.m., Alan Conway wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11378/ --- (Updated May 24, 2013, 2:16 p.m.) Review request for qpid, Gordon Sim and Kenneth Giusti. Description --- QPID-4886: Pass non-const reference to Message in QueueObserver functions. The HA plugin needs to modify a message in QueueObserver::enqueued to attach a HA ID to it. Other plugins may need to similarly annotate messages at QueueObserver call points. Need to remove the const qualifier for Message arguments to QueueObserver methods to enable this. Diffs - /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.h 1486017 /trunk/qpid/cpp/src/qpid/broker/MessageGroupManager.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.h 1486017 /trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1486017 /trunk/qpid/cpp/src/qpid/broker/QueueObserver.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.h 1486017 /trunk/qpid/cpp/src/qpid/broker/ThresholdAlerts.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.h 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueGuard.cpp 1486017 /trunk/qpid/cpp/src/qpid/ha/QueueReplicator.cpp 1486017 Diff: https://reviews.apache.org/r/11378/diff/ Testing --- make test Thanks, Alan Conway
