Re: Review Request: Recreation of JCA Resource Adapter review
On 2011-07-15 15:40:16, Robbie Gemmell wrote: The apparent JBoss 'dependency' for this seems less than ideal. I don't think we should/can accept something into the Qpid code base when it hasn't even been attempted to use it with a product that is actually Apache Licence compatible. I think this really needs to be able to work fully out the box with something like Geronimo, with additional rather than sole configuration supplied for JBoss AS. It probably gets round the letter of the licence, since although the example actually imports some JBoss annotations it probably gets away with it because it doesn't look to be built by default (correct?), whereas the adapter itself either has the bits turned off that are JBoss dependent and/or uses reflection to avoid the imports. That doesn't really seem to change the fact you don't appear to be able to use all of the 'optional' features without JBoss though, which is probably still in violation of the spirit of the licence. It still appears that there is absolutely zero test coverage for this? We keep talking about trying to improve our test situation as a project, but particularly in the Java tree, and additions like this are not helpful. The code continues to violate the field naming convention we use on the Java components ( https://cwiki.apache.org/qpid/java-coding-standards.html ), although in contrast to earlier versions this diff actually has a mixture of field naming conventions, making it inconsistent as well. Andrew Stitcher wrote: A quick answer to a couple of things - The adapter has actually been used with multiple application servers including JBoss and Websphere. Also I believe that the TCK testing actually uses Sun/Oracles reference app server (I didn't do the TCK testing myself). It's not at all clear to me why the licensing of the App server matters for this code as the resource adapter should work for all. So you're only talking about the default configuration, why shouldn't the default configuration be JBoss? Its license is LGPL which is compatible with the Apache License, but I'm not even sure that this is relevant. I thought we hashed out the testing issue before on the dev list - in short there is little coherent/useful that you could add to unit tests for the JCA as it's nearly all straight delegation to the JMS client. And including an appserver into our java tree just to do unit testing seems fantastic overhead. There appears to be little in between. The example code provides a reasonable smoke test (given that you've installed an app server) which I believe is as good as any unit tests would be. Weston Price wrote: There is no real 'dependency' on JBoss, the sample configuration file is there to provide a convenient starting point for that particular application server but does necessitate it's use. The adapter has been tested in Weblogic as well as in Websphere. Since both these application servers do not require an XML configuration file, none has been provided. In sum the *-ds.xml file, is provided as a convenience, not a requirement. There is one specific JBoss annotation on QpidListener that is there simply to which RAR file is in use. This is a requirement of JBoss but can be removed in favor of an ejb-jar.xml file if you think this would be more acceptable. The adapter itself has no dependency on JBoss, it is a standard resource adapter that conforms to the 1.5 JCA specification and as such is application server agnostic. OK, so my confusion over whether multiple application servers had been used in its development may have been linked to there being 3 README files included in the diff that outright note (or at least suggest) otherwise. LGPL 2.1 is a Category X Excluded licence according to the ASF legal pages (http://www.apache.org/legal/3party.html), i.e. it is not Apache Licence compatible, which is why the licencing is of interest particularly when there are imports present or features that only seem to be implemented for one product. The example at least would seem to fall into requiring consideration of the 'options for excluded works' sections as a result (http://www.apache.org/legal/3party.html#options), and for the adapter itself possibly the 'optional' XA features around transactions that appear to only have JBoss specific implementation. IANAL though, so it might be best if we cleared things with legal@. Regardless of any actual legal requirements though, whilst I think we all can guess why JBoss AS is of interest here I still think that if the adapter is considered truly generic then it deserves some configuration/example and the ability to function fully with something something else, such as Geronimo (that obviously is Apache Licence compatible). On the testing, I'd say there looked to be quite a lot of stuff that
Re: Review Request: Recreation of JCA Resource Adapter review
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/441/#review1093 --- /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAConnectionMetaData.java https://reviews.apache.org/r/441/#comment2226 I seem to recall Rajith doing some work around this area. Is 'Bug' fixed? If so, and this is being left for compatibility purposes with old versions, possibly some comments should be added to say so, preventing later inadvertent cleanup? - Robbie On 2011-07-14 22:39:37, Andrew Stitcher wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/441/ --- (Updated 2011-07-14 22:39:37) Review request for qpid, Gordon Sim, Andrew Kennedy, Robbie Gemmell, rajith attapattu, and Weston Price. Summary --- Review for a qpid JCA resource adapter. So far no build infrastructure is included. I'd also like an opinion as to whether java/jca is the appropriate name for this (I'm thinking perhaps java/ra would be more usual). Any and all comments welcome. This addresses bug QPID-3044. https://issues.apache.org/jira/browse/QPID-3044 Diffs - /trunk/qpid/java/lib/geronimo-j2ee-connector_1.5_spec-2.0.0.jar UNKNOWN /trunk/qpid/java/lib/geronimo-jta_1.1_spec-1.1.1.jar UNKNOWN /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/inflow/QpidMessageHandler.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/tm/JBossTransactionManagerLocator.java PRE-CREATION /trunk/qpid/java/jca/src/main/resources/META-INF/ra.xml PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/inflow/QpidActivationSpec.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidConnectionFactoryProxy.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidDestinationProxy.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidQueue.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidTopic.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/inflow/QpidActivation.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/AdminObjectFactory.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidBindingURL.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/Util.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidResourceAdapter.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAStreamMessage.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRATextMessage.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRATopicPublisher.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRATopicSubscriber.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAXAResource.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRASessionFactory.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRASessionFactoryImpl.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAQueueBrowser.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAQueueReceiver.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAQueueSender.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRASession.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAObjectMessage.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAProperties.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMetaData.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMessageProducer.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMessageListener.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMessageConsumer.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMessage.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMapMessage.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAManagedConnectionFactory.java PRE-CREATION /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAManagedConnection.java PRE-CREATION
[jira] [Commented] (QPID-3044) Implement JCA Adapter for Java JMS client
[ https://issues.apache.org/jira/browse/QPID-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066871#comment-13066871 ] jirapos...@reviews.apache.org commented on QPID-3044: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/441/#review1093 --- /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAConnectionMetaData.java https://reviews.apache.org/r/441/#comment2226 I seem to recall Rajith doing some work around this area. Is 'Bug' fixed? If so, and this is being left for compatibility purposes with old versions, possibly some comments should be added to say so, preventing later inadvertent cleanup? - Robbie On 2011-07-14 22:39:37, Andrew Stitcher wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/441/ bq. --- bq. bq. (Updated 2011-07-14 22:39:37) bq. bq. bq. Review request for qpid, Gordon Sim, Andrew Kennedy, Robbie Gemmell, rajith attapattu, and Weston Price. bq. bq. bq. Summary bq. --- bq. bq. Review for a qpid JCA resource adapter. bq. bq. So far no build infrastructure is included. bq. bq. I'd also like an opinion as to whether java/jca is the appropriate name for this (I'm thinking perhaps java/ra would be more usual). bq. bq. Any and all comments welcome. bq. bq. bq. This addresses bug QPID-3044. bq. https://issues.apache.org/jira/browse/QPID-3044 bq. bq. bq. Diffs bq. - bq. bq./trunk/qpid/java/lib/geronimo-j2ee-connector_1.5_spec-2.0.0.jar UNKNOWN bq./trunk/qpid/java/lib/geronimo-jta_1.1_spec-1.1.1.jar UNKNOWN bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/inflow/QpidMessageHandler.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/tm/JBossTransactionManagerLocator.java PRE-CREATION bq./trunk/qpid/java/jca/src/main/resources/META-INF/ra.xml PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/inflow/QpidActivationSpec.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidConnectionFactoryProxy.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidDestinationProxy.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidQueue.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidTopic.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/inflow/QpidActivation.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/AdminObjectFactory.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/admin/QpidBindingURL.java PRE-CREATION bq./trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/Util.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidResourceAdapter.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAStreamMessage.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRATextMessage.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRATopicPublisher.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRATopicSubscriber.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAXAResource.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRASessionFactory.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRASessionFactoryImpl.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAQueueBrowser.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAQueueReceiver.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAQueueSender.java PRE-CREATION bq./trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRASession.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAObjectMessage.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAProperties.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMetaData.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMessageProducer.java PRE-CREATION bq. /trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAMessageListener.java PRE-CREATION bq.
[jira] [Commented] (QPID-3044) Implement JCA Adapter for Java JMS client
[ https://issues.apache.org/jira/browse/QPID-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066870#comment-13066870 ] jirapos...@reviews.apache.org commented on QPID-3044: - bq. On 2011-07-15 15:40:16, Robbie Gemmell wrote: bq. The apparent JBoss 'dependency' for this seems less than ideal. I don't think we should/can accept something into the Qpid code base when it hasn't even been attempted to use it with a product that is actually Apache Licence compatible. I think this really needs to be able to work fully out the box with something like Geronimo, with additional rather than sole configuration supplied for JBoss AS. bq. bq. It probably gets round the letter of the licence, since although the example actually imports some JBoss annotations it probably gets away with it because it doesn't look to be built by default (correct?), whereas the adapter itself either has the bits turned off that are JBoss dependent and/or uses reflection to avoid the imports. That doesn't really seem to change the fact you don't appear to be able to use all of the 'optional' features without JBoss though, which is probably still in violation of the spirit of the licence. bq. bq. It still appears that there is absolutely zero test coverage for this? We keep talking about trying to improve our test situation as a project, but particularly in the Java tree, and additions like this are not helpful. bq. bq. The code continues to violate the field naming convention we use on the Java components ( https://cwiki.apache.org/qpid/java-coding-standards.html ), although in contrast to earlier versions this diff actually has a mixture of field naming conventions, making it inconsistent as well. bq. bq. Andrew Stitcher wrote: bq. A quick answer to a couple of things - bq. bq. The adapter has actually been used with multiple application servers including JBoss and Websphere. Also I believe that the TCK testing actually uses Sun/Oracles reference app server (I didn't do the TCK testing myself). bq. bq. It's not at all clear to me why the licensing of the App server matters for this code as the resource adapter should work for all. So you're only talking about the default configuration, why shouldn't the default configuration be JBoss? Its license is LGPL which is compatible with the Apache License, but I'm not even sure that this is relevant. bq. bq. I thought we hashed out the testing issue before on the dev list - in short there is little coherent/useful that you could add to unit tests for the JCA as it's nearly all straight delegation to the JMS client. And including an appserver into our java tree just to do unit testing seems fantastic overhead. There appears to be little in between. The example code provides a reasonable smoke test (given that you've installed an app server) which I believe is as good as any unit tests would be. bq. bq. Weston Price wrote: bq. There is no real 'dependency' on JBoss, the sample configuration file is there to provide a convenient starting point for that particular application server but does necessitate it's use. The adapter has been tested in Weblogic as well as in Websphere. Since both these application servers do not require an XML configuration file, none has been provided. In sum the *-ds.xml file, is provided as a convenience, not a requirement. bq. bq. There is one specific JBoss annotation on QpidListener that is there simply to which RAR file is in use. This is a requirement of JBoss but can be removed in favor of an ejb-jar.xml file if you think this would be more acceptable. bq. bq. The adapter itself has no dependency on JBoss, it is a standard resource adapter that conforms to the 1.5 JCA specification and as such is application server agnostic. bq. OK, so my confusion over whether multiple application servers had been used in its development may have been linked to there being 3 README files included in the diff that outright note (or at least suggest) otherwise. LGPL 2.1 is a Category X Excluded licence according to the ASF legal pages (http://www.apache.org/legal/3party.html), i.e. it is not Apache Licence compatible, which is why the licencing is of interest particularly when there are imports present or features that only seem to be implemented for one product. The example at least would seem to fall into requiring consideration of the 'options for excluded works' sections as a result (http://www.apache.org/legal/3party.html#options), and for the adapter itself possibly the 'optional' XA features around transactions that appear to only have JBoss specific implementation. IANAL though, so it might be best if we cleared things with legal@. Regardless of any actual legal requirements though, whilst I think we all can guess why JBoss AS is of
[jira] [Commented] (QPID-3283) Make AuthenticationManager pluggable
[ https://issues.apache.org/jira/browse/QPID-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066873#comment-13066873 ] Keith Wall commented on QPID-3283: -- Add 0.13 specific config page to describe these changes: https://cwiki.apache.org/confluence/display/qpid/Configure+the+Broker+via+config.xml Make AuthenticationManager pluggable Key: QPID-3283 URL: https://issues.apache.org/jira/browse/QPID-3283 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Robbie Gemmell Fix For: 0.13 Attachments: 0001-QPID-3283-Make-Authentication-Manager-pluggable.patch This improvement forms part of the proposal I made to the Qpid Developer List on 2011-05-16 in the posting entitled Java Broker: Pluggable Authentication Managers. The existing AuthenticationManager and configuration classes will be refactored to allow a user to choose an implementation of AuthenticationManager through new elements in the config.xml. Existing use-cases (that is authentication against the etc/passwd file) will be maintained by plugging-in the PrincipalDatabaseAuthenticationManager implementation. Future implementations of AuthenticationManager could then allow authentication to be delegated to an external system such as an LDAP Directory. This change *will* alter the format of the config.xml file. Existing users of =0-12 will need to edit their config.xml when upgrading. Documentation will be updated to guide upgraders and helpful error messages will gently reject older configure files. See also: https://cwiki.apache.org/confluence/display/qpid/Java+Pluggable+Authentication+Managers -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
segfault in __cxa_finalize when unloading libqpidmessaging
Hi guys, I'm totally stumped with this one (and more than just a little out of my depth). I've been looking into a strange segfault that happens with the new swig-based PHP binding when the PHP command line interpreter loads and then unloads the cqpid_php module quickly. You can see more details in the last few comments at https://issues.apache.org/jira/browse/QPID-3027 But in short, when the cqpid.so library (the swig-based PHP binding) is unloaded by PHP, we get a segfault with backtrace like this: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0xb7980688 in __cxa_finalize () from /lib/i686/cmov/libc.so.6 #2 0xb7369df4 in __do_global_dtors_aux () from /lib/libqpidmessaging.so.2 #3 0xb73c1ba0 in _fini () from /lib/libqpidmessaging.so.2 #4 0xb7ff571e in ?? () from /lib/ld-linux.so.2 #5 0xb7ff6197 in ?? () from /lib/ld-linux.so.2 #6 0xb7ce0ca4 in ?? () from /lib/i686/cmov/libdl.so.2 #7 0xb7ff07f6 in ?? () from /lib/ld-linux.so.2 #8 0xb7ce109c in ?? () from /lib/i686/cmov/libdl.so.2 #9 0xb7ce0cda in dlclose () from /lib/i686/cmov/libdl.so.2 #10 0x083dcf54 in module_destructor (module=0x8913198) at /home/david/php5-5.3.3/Zend/zend_API.c:2120 This looks to me like it might be related to http://web.archiveorange.com/archive/v/7nip7tkWhQpEnlSqODIz ? But I'm not sure. I've tried a whole lot of little things, but nothing seems to make any difference. And since this __cxa_finalize function is something gcc generates internally, it's quite beyond my level of knowledge! As noted on the above QPID-3027 issue, this does not seem to be a problem is libqpidmessaging.so etc is built via cmake instead of gnu autotools, but that might just be a co-incidence. Also, internally PHP calls dlopen with the RTLD_LAZY flag... if I modify PHP to use RTLD_NOW instead, that seems to fix the problem, but that should not be necessary AFAIK (nor would it be practical). So, any hints / tips / suggestions on where to go, or what to try next? Is there someone here with really deep gcc / compiler knowledge that could help me look into this? or should I be heading to some gcc-specific discussion group somewhere else? Thanks! paul. http://colby.id.au
[jira] [Updated] (QPID-3361) Provides integration tests for the Ruby APIs
[ https://issues.apache.org/jira/browse/QPID-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-3361: --- Attachment: 0002-Created-an-integration-test-that-sends-multiple-mess.patch Provides integration tests for the Ruby APIs Key: QPID-3361 URL: https://issues.apache.org/jira/browse/QPID-3361 Project: Qpid Issue Type: Improvement Components: AMQP Compliance, Ruby Test Suite Reporter: Darryl L. Pierce Priority: Minor Attachments: 0001-Created-the-setup-module-for-the-integration-tests.patch, 0002-Created-an-integration-test-that-sends-multiple-mess.patch Provides integration tests to validate the codebase in Ruby. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3361) Provides integration tests for the Ruby APIs
[ https://issues.apache.org/jira/browse/QPID-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-3361: --- Attachment: 0001-Created-the-setup-module-for-the-integration-tests.patch Provides integration tests for the Ruby APIs Key: QPID-3361 URL: https://issues.apache.org/jira/browse/QPID-3361 Project: Qpid Issue Type: Improvement Components: AMQP Compliance, Ruby Test Suite Reporter: Darryl L. Pierce Priority: Minor Attachments: 0001-Created-the-setup-module-for-the-integration-tests.patch, 0002-Created-an-integration-test-that-sends-multiple-mess.patch Provides integration tests to validate the codebase in Ruby. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3362) Creates the Qpid gem file for distribution on RubyGems.org
Creates the Qpid gem file for distribution on RubyGems.org -- Key: QPID-3362 URL: https://issues.apache.org/jira/browse/QPID-3362 Project: Qpid Issue Type: New Feature Components: Ruby Client Reporter: Darryl L. Pierce Provides the Rakefile file for creating the gem, Cmake targets for both copying the Swig wrapper code and also creating the gem during the build process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3362) Creates the Qpid gem file for distribution on RubyGems.org
[ https://issues.apache.org/jira/browse/QPID-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-3362: --- Attachment: 0001-Ruby-specific-.gitignore-file.patch Creates the Qpid gem file for distribution on RubyGems.org -- Key: QPID-3362 URL: https://issues.apache.org/jira/browse/QPID-3362 Project: Qpid Issue Type: New Feature Components: Ruby Client Reporter: Darryl L. Pierce Attachments: 0001-Ruby-specific-.gitignore-file.patch, 0002-Added-a-new-target-to-copy-rubyRUBY_wrap.cxx-into-th.patch, 0003-Added-details-to-the-README.rdoc-file-for-using-the-.patch, 0004-Created-the-Qpid-gem-package.patch Provides the Rakefile file for creating the gem, Cmake targets for both copying the Swig wrapper code and also creating the gem during the build process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3362) Creates the Qpid gem file for distribution on RubyGems.org
[ https://issues.apache.org/jira/browse/QPID-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-3362: --- Attachment: 0003-Added-details-to-the-README.rdoc-file-for-using-the-.patch Creates the Qpid gem file for distribution on RubyGems.org -- Key: QPID-3362 URL: https://issues.apache.org/jira/browse/QPID-3362 Project: Qpid Issue Type: New Feature Components: Ruby Client Reporter: Darryl L. Pierce Attachments: 0001-Ruby-specific-.gitignore-file.patch, 0002-Added-a-new-target-to-copy-rubyRUBY_wrap.cxx-into-th.patch, 0003-Added-details-to-the-README.rdoc-file-for-using-the-.patch, 0004-Created-the-Qpid-gem-package.patch Provides the Rakefile file for creating the gem, Cmake targets for both copying the Swig wrapper code and also creating the gem during the build process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3362) Creates the Qpid gem file for distribution on RubyGems.org
[ https://issues.apache.org/jira/browse/QPID-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-3362: --- Attachment: 0002-Added-a-new-target-to-copy-rubyRUBY_wrap.cxx-into-th.patch Creates the Qpid gem file for distribution on RubyGems.org -- Key: QPID-3362 URL: https://issues.apache.org/jira/browse/QPID-3362 Project: Qpid Issue Type: New Feature Components: Ruby Client Reporter: Darryl L. Pierce Attachments: 0001-Ruby-specific-.gitignore-file.patch, 0002-Added-a-new-target-to-copy-rubyRUBY_wrap.cxx-into-th.patch, 0003-Added-details-to-the-README.rdoc-file-for-using-the-.patch, 0004-Created-the-Qpid-gem-package.patch Provides the Rakefile file for creating the gem, Cmake targets for both copying the Swig wrapper code and also creating the gem during the build process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3362) Creates the Qpid gem file for distribution on RubyGems.org
[ https://issues.apache.org/jira/browse/QPID-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-3362: --- Attachment: 0004-Created-the-Qpid-gem-package.patch Creates the Qpid gem file for distribution on RubyGems.org -- Key: QPID-3362 URL: https://issues.apache.org/jira/browse/QPID-3362 Project: Qpid Issue Type: New Feature Components: Ruby Client Reporter: Darryl L. Pierce Attachments: 0001-Ruby-specific-.gitignore-file.patch, 0002-Added-a-new-target-to-copy-rubyRUBY_wrap.cxx-into-th.patch, 0003-Added-details-to-the-README.rdoc-file-for-using-the-.patch, 0004-Created-the-Qpid-gem-package.patch Provides the Rakefile file for creating the gem, Cmake targets for both copying the Swig wrapper code and also creating the gem during the build process. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3363) broker allows unbind on default exchange
broker allows unbind on default exchange Key: QPID-3363 URL: https://issues.apache.org/jira/browse/QPID-3363 Project: Qpid Issue Type: Bug Affects Versions: 0.10, 0.12 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.13 Rule 'default-access' states The default exchange MUST NOT be accessible to the client except by specifying an empty exchange name in a content publish command (such as message.transfer). That is, the server must not let clients explicitly bind, unbind, delete, or make any other reference to this exchange. However qpid-config unbind my-queue my-queue will delete the binding preventing the queue from being directly accessed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Review Request: Recreation of JCA Resource Adapter review
On 2011-07-15 15:40:16, Robbie Gemmell wrote: The apparent JBoss 'dependency' for this seems less than ideal. I don't think we should/can accept something into the Qpid code base when it hasn't even been attempted to use it with a product that is actually Apache Licence compatible. I think this really needs to be able to work fully out the box with something like Geronimo, with additional rather than sole configuration supplied for JBoss AS. It probably gets round the letter of the licence, since although the example actually imports some JBoss annotations it probably gets away with it because it doesn't look to be built by default (correct?), whereas the adapter itself either has the bits turned off that are JBoss dependent and/or uses reflection to avoid the imports. That doesn't really seem to change the fact you don't appear to be able to use all of the 'optional' features without JBoss though, which is probably still in violation of the spirit of the licence. It still appears that there is absolutely zero test coverage for this? We keep talking about trying to improve our test situation as a project, but particularly in the Java tree, and additions like this are not helpful. The code continues to violate the field naming convention we use on the Java components ( https://cwiki.apache.org/qpid/java-coding-standards.html ), although in contrast to earlier versions this diff actually has a mixture of field naming conventions, making it inconsistent as well. Andrew Stitcher wrote: A quick answer to a couple of things - The adapter has actually been used with multiple application servers including JBoss and Websphere. Also I believe that the TCK testing actually uses Sun/Oracles reference app server (I didn't do the TCK testing myself). It's not at all clear to me why the licensing of the App server matters for this code as the resource adapter should work for all. So you're only talking about the default configuration, why shouldn't the default configuration be JBoss? Its license is LGPL which is compatible with the Apache License, but I'm not even sure that this is relevant. I thought we hashed out the testing issue before on the dev list - in short there is little coherent/useful that you could add to unit tests for the JCA as it's nearly all straight delegation to the JMS client. And including an appserver into our java tree just to do unit testing seems fantastic overhead. There appears to be little in between. The example code provides a reasonable smoke test (given that you've installed an app server) which I believe is as good as any unit tests would be. Weston Price wrote: There is no real 'dependency' on JBoss, the sample configuration file is there to provide a convenient starting point for that particular application server but does necessitate it's use. The adapter has been tested in Weblogic as well as in Websphere. Since both these application servers do not require an XML configuration file, none has been provided. In sum the *-ds.xml file, is provided as a convenience, not a requirement. There is one specific JBoss annotation on QpidListener that is there simply to which RAR file is in use. This is a requirement of JBoss but can be removed in favor of an ejb-jar.xml file if you think this would be more acceptable. The adapter itself has no dependency on JBoss, it is a standard resource adapter that conforms to the 1.5 JCA specification and as such is application server agnostic. Robbie Gemmell wrote: OK, so my confusion over whether multiple application servers had been used in its development may have been linked to there being 3 README files included in the diff that outright note (or at least suggest) otherwise. LGPL 2.1 is a Category X Excluded licence according to the ASF legal pages (http://www.apache.org/legal/3party.html), i.e. it is not Apache Licence compatible, which is why the licencing is of interest particularly when there are imports present or features that only seem to be implemented for one product. The example at least would seem to fall into requiring consideration of the 'options for excluded works' sections as a result (http://www.apache.org/legal/3party.html#options), and for the adapter itself possibly the 'optional' XA features around transactions that appear to only have JBoss specific implementation. IANAL though, so it might be best if we cleared things with legal@. Regardless of any actual legal requirements though, whilst I think we all can guess why JBoss AS is of interest here I still think that if the adapter is considered truly generic then it deserves some configuration/example and the ability to function fully with something something else, such as Geronimo (that obviously is Apache Licence compatible).
[jira] [Commented] (QPID-3044) Implement JCA Adapter for Java JMS client
[ https://issues.apache.org/jira/browse/QPID-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066991#comment-13066991 ] jirapos...@reviews.apache.org commented on QPID-3044: - bq. On 2011-07-15 15:40:16, Robbie Gemmell wrote: bq. The apparent JBoss 'dependency' for this seems less than ideal. I don't think we should/can accept something into the Qpid code base when it hasn't even been attempted to use it with a product that is actually Apache Licence compatible. I think this really needs to be able to work fully out the box with something like Geronimo, with additional rather than sole configuration supplied for JBoss AS. bq. bq. It probably gets round the letter of the licence, since although the example actually imports some JBoss annotations it probably gets away with it because it doesn't look to be built by default (correct?), whereas the adapter itself either has the bits turned off that are JBoss dependent and/or uses reflection to avoid the imports. That doesn't really seem to change the fact you don't appear to be able to use all of the 'optional' features without JBoss though, which is probably still in violation of the spirit of the licence. bq. bq. It still appears that there is absolutely zero test coverage for this? We keep talking about trying to improve our test situation as a project, but particularly in the Java tree, and additions like this are not helpful. bq. bq. The code continues to violate the field naming convention we use on the Java components ( https://cwiki.apache.org/qpid/java-coding-standards.html ), although in contrast to earlier versions this diff actually has a mixture of field naming conventions, making it inconsistent as well. bq. bq. Andrew Stitcher wrote: bq. A quick answer to a couple of things - bq. bq. The adapter has actually been used with multiple application servers including JBoss and Websphere. Also I believe that the TCK testing actually uses Sun/Oracles reference app server (I didn't do the TCK testing myself). bq. bq. It's not at all clear to me why the licensing of the App server matters for this code as the resource adapter should work for all. So you're only talking about the default configuration, why shouldn't the default configuration be JBoss? Its license is LGPL which is compatible with the Apache License, but I'm not even sure that this is relevant. bq. bq. I thought we hashed out the testing issue before on the dev list - in short there is little coherent/useful that you could add to unit tests for the JCA as it's nearly all straight delegation to the JMS client. And including an appserver into our java tree just to do unit testing seems fantastic overhead. There appears to be little in between. The example code provides a reasonable smoke test (given that you've installed an app server) which I believe is as good as any unit tests would be. bq. bq. Weston Price wrote: bq. There is no real 'dependency' on JBoss, the sample configuration file is there to provide a convenient starting point for that particular application server but does necessitate it's use. The adapter has been tested in Weblogic as well as in Websphere. Since both these application servers do not require an XML configuration file, none has been provided. In sum the *-ds.xml file, is provided as a convenience, not a requirement. bq. bq. There is one specific JBoss annotation on QpidListener that is there simply to which RAR file is in use. This is a requirement of JBoss but can be removed in favor of an ejb-jar.xml file if you think this would be more acceptable. bq. bq. The adapter itself has no dependency on JBoss, it is a standard resource adapter that conforms to the 1.5 JCA specification and as such is application server agnostic. bq. bq. bq. Robbie Gemmell wrote: bq. OK, so my confusion over whether multiple application servers had been used in its development may have been linked to there being 3 README files included in the diff that outright note (or at least suggest) otherwise. bq. bq. LGPL 2.1 is a Category X Excluded licence according to the ASF legal pages (http://www.apache.org/legal/3party.html), i.e. it is not Apache Licence compatible, which is why the licencing is of interest particularly when there are imports present or features that only seem to be implemented for one product. The example at least would seem to fall into requiring consideration of the 'options for excluded works' sections as a result (http://www.apache.org/legal/3party.html#options), and for the adapter itself possibly the 'optional' XA features around transactions that appear to only have JBoss specific implementation. IANAL though, so it might be best if we cleared things with legal@. bq. bq. Regardless of any actual
[jira] [Commented] (QPID-3286) cluster node went down
[ https://issues.apache.org/jira/browse/QPID-3286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067026#comment-13067026 ] Alan Conway commented on QPID-3286: --- 1. Is it possible to monitor the journal file size growth and flush the journal files before it reach certain limit, so that we can save the brocker going down. No. If the senders are consistently sending messages faster than the receivers are accepting them then you will inevitably hit the limit at some point. However as in my previous comment, you can avoid broker shutdown: a good solution is to set a queue limit policy on you're queues with a limit that is lower than the size of your store. Policy exceptions are synchronized across the broker so if you exceed the limit on a queue, the sender will receive an exception and the cluster will continue as normal. 2. Is there any limit on journal file size No. cluster node went down -- Key: QPID-3286 URL: https://issues.apache.org/jira/browse/QPID-3286 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.10 Environment: Two node persistent cluster using openais. Both nodes are CentOS 5.5. Reporter: sujith paily Assignee: Alan Conway Priority: Critical Labels: adminis, newbie Original Estimate: 24h Remaining Estimate: 24h I have configured qpid 0.10 c++ brocker as 2 node persistent cluster. I was worked without any issue for few hours or sometimes one or two day. But one node went down after some time with following error. --- 2011-05-30 12:55:28 warning Journal OPC_MESSAGE_QUEUE: Enqueue capacity threshold exceeded on queue OPC_MESSAGE_QUEUE. 2011-05-30 12:55:28 error Unexpected exception: Enqueue capacity threshold exceeded on queue OPC_MESSAGE_QUEUE. (JournalImpl.cpp:587) 2011-05-30 12:55:28 error Connection 192.168.1.138:5672-192.168.1.10:58839 closed by error: Enqueue capacity threshold exceeded on queue OPC_MESSAGE_QUEUE. (JournalImpl.cpp:587)(501) 2011-05-30 12:55:28 critical cluster(192.168.1.138:6321 READY/error) local error 11545 did not occur on member 192.168.1.139:25161: Enqueue capacity threshold exceeded on queue OPC_MESSAGE_QUEUE. (JournalImpl.cpp:587) 2011-05-30 12:55:28 critical Error delivering frames: local error did not occur on all cluster members : Enqueue capacity threshold exceeded on queue OPC_MESSAGE_QUEUE. (JournalImpl.cpp:587) (qpid/cluster/ErrorCheck.cpp:89) 2011-05-30 12:55:28 notice cluster(192.168.1.138:6321 LEFT/error) leaving cluster QCLUSTER 2011-05-30 12:55:28 notice Shut down -- But the remaining node is working without any issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
