[jira] Updated: (QPID-2476) Complete ACL implementation for 0-10 code path
[ https://issues.apache.org/jira/browse/QPID-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kennedy updated QPID-2476: - Attachment: acl.txt method-considered-harmful.txt method-redux.txt Wiki page text for ACL documentatiopn Complete ACL implementation for 0-10 code path -- Key: QPID-2476 URL: https://issues.apache.org/jira/browse/QPID-2476 Project: Qpid Issue Type: New Feature Components: Java Broker Affects Versions: 0.7 Reporter: Andrew Kennedy Fix For: 0.7 Attachments: acl.txt, method-considered-harmful.txt, method-redux.txt Original Estimate: 336h Remaining Estimate: 336h Complete ACL implementation for 0-10 code path, providing an ACLv2 implementation that covers the following features/requirements: - Best practice security design - Support for roles/groups - Appropriate for standard stores for authorisation credentials (e.g. LDAP, Kerberos) - Expressable as XML - Easy to store/backup/extract ACL config - Exception handling catching at point of ACL application and return to client via Connection ExceptionListener with correct error code, log failure in broker - No significant performance cost on publish, permissions to be cached - Security handled at correct level of abstraction internally - Interoperability with existing ACLv2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
On 19 May 2010 17:22, Carl Trieloff cctriel...@redhat.com wrote:
I've had a brief read, it seem seems the point I was trying to make has
been entirely miss-understood.
How about some IRC, or a call if you can do that and the reflect back to the
list.
Carl.
Hi.
I talked with carl, and I think we are basically on the same page,
apart from some minor confusion over naming and definitions which I
think I now understand better. Basically, the 'Conclusions' section of
the document I posted earlier describes the way ACLs on management
functions will work, however I have added a post-script with some more
detail, including an explanation of what exactly a 'mangement
function' is. Additionally, I have updated the original proposal to
reflect the changes to the object type and operation combinations. I
am in the process of getting the wiki pages updated, but in the
meantime I have attached three text files to QPID-2476 and the
post-script and part of the conclusion are reproduced below:
{noformat}
ACL ALLOW kitten EXECUTE METHOD component=log name=reload*
ACL ALLOW kitten UPDATE METHOD component=log
ACL ALLOW robot ACCESS METHOD component=log
ACL ALLOW robot EXECUTE METHOD component=acl name=reload*
ACL DENY robot EXECUTE METHOD component=config name=reload*
ACL ALLOW robot EXECUTE METHOD component=config
{noformat}
h2. Post Scriptum
The following points should clarify some of the proposed features,
however the syntax as described in the [#Conclusion] is intended to
represent the preferred usage.
In the C++ broker there exists a feature wherby plugins, uniquely
identified by a schema package and a class name, can have ACLs applied
to them. This will also become available in the Java broker, and would
be permissioned using the _OBJECT_ object type. This allows objects
that are external to the broker to be controlled. For the Java broker
it is intended that the main class for a plugin would check with the
security manager using the Java package and class names as properties,
as below.
{noformat}
ACL ALLOW kittens ACCESS OBJECT package=com.example.plugin class=Example
{noformat}
When management functions are being permissioned, a symbolic name for
a logical grouping of related methods, properties, attributes and
operations is used to identify what is being controlled. This is
identified using the _component_ property in the examples above. These
groupings will map onto JMX managed objects or MBeans, QMF management
schemas, or some other form of mangement object. It is intended that a
particular broker implementation handles these mappings internally and
ignores mappings that do not exist, such as logging management on the
C++ broker currently. It is also possible to offer finer grained
control by specifying the _name_ property for the ACL entry, thus
restricting the scope to a single method or property. It _may_ also be
possible to specify other properties that have meaning for a paricular
broker implementation, thus maintaining backward compatibility. The
list of possible property names should be fixed as part of the
definition of the ACL file format.
Cheers,
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2623) Implement 'JMSXDeliveryCount'
Implement 'JMSXDeliveryCount' - Key: QPID-2623 URL: https://issues.apache.org/jira/browse/QPID-2623 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Client Reporter: Martin Ritchie This optional JMS property is not currently supported in Qpid, From the JMS spec this an int sent by Provider on Receive and represents 'The number of message delivery attempts; the first is 1, the second 2,...' Whilst incrementing the delivery count for all messages as they enter the prefetch is a little annoying it does seem to be within the spirit of 'delivery attempt'. There is no suggestion that only messages that are actually given to the client application need to be incremented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2623) Implement 'JMSXDeliveryCount'
[ https://issues.apache.org/jira/browse/QPID-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869950#action_12869950 ] Martin Ritchie commented on QPID-2623: -- See ActiveMQ's discussion on this here : AMQ-1730 Implement 'JMSXDeliveryCount' - Key: QPID-2623 URL: https://issues.apache.org/jira/browse/QPID-2623 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Client Reporter: Martin Ritchie This optional JMS property is not currently supported in Qpid, From the JMS spec this an int sent by Provider on Receive and represents 'The number of message delivery attempts; the first is 1, the second 2,...' Whilst incrementing the delivery count for all messages as they enter the prefetch is a little annoying it does seem to be within the spirit of 'delivery attempt'. There is no suggestion that only messages that are actually given to the client application need to be incremented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Issue Comment Edited: (QPID-2623) Implement 'JMSXDeliveryCount'
[ https://issues.apache.org/jira/browse/QPID-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869950#action_12869950 ] Martin Ritchie edited comment on QPID-2623 at 5/21/10 7:37 AM: --- See ActiveMQ's discussion on this here : https://issues.apache.org/activemq/browse/AMQ-1730 was (Author: ritchiem): See ActiveMQ's discussion on this here : AMQ-1730 Implement 'JMSXDeliveryCount' - Key: QPID-2623 URL: https://issues.apache.org/jira/browse/QPID-2623 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Client Reporter: Martin Ritchie This optional JMS property is not currently supported in Qpid, From the JMS spec this an int sent by Provider on Receive and represents 'The number of message delivery attempts; the first is 1, the second 2,...' Whilst incrementing the delivery count for all messages as they enter the prefetch is a little annoying it does seem to be within the spirit of 'delivery attempt'. There is no suggestion that only messages that are actually given to the client application need to be incremented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Website prototype take2
On 05/20/2010 05:48 PM, Jonathan Robie wrote: Here's a slightly modified version of prototype 4, some of the changes are not visible, the main visible change is that the title and subtitle are larger than in Rajith and Robbie's designs: http://people.apache.org/~jonathan/website/ I'd consider this a minor modification of what we agreed on, and we can change it further if we need to. But is this a good design to start with? I think it looks great. One comment on the text Qpid implements the *latest* AMQP specification, this will be untrue for a time when AMQP 1.0 ships, and will be periodically untrue as revisions to the specification come out. Maybe drop the latest for the front page, we can provide a separate page that we keep up to date with details about the specifications we implement. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] transaction handling
On 1 April 2010 01:26, Aidan Skinner aidan.skin...@gmail.com wrote: I've recently been wrestling with transaction handling in the java broker in the context of 0-9-1 compliance. We're currently not strictly spec compliant with 0-9-1 as we will resend messages that have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter, and I've been trying to retain current behaviour for them. However, it's a) a massive PITA and b) probably Not What You Want. If you're rolling back a consume it's almost certainly because you can't cope with the message. If you think b) I'd like to float the idea of 0.8 being the we are breaking backwards compatibility release so we can fix the conf file, the command line etc. Thoughts? I don't read the spec in the same way. From the 0-9-1 Spec: 1.9.2.5. Method tx.rollback (ID 30) This method abandons all message publications and acknowledgments performed in the current transaction. A new transaction starts immediately after a rollback. Note that unacked messages will not be automatically redelivered by rollback; if that is required an explicit recover call should be issued. I read that as the unacked messages will not be automatically given back to the client. So we should put them back on the queue and let the client fight it out with other cilents to see who gets them. It is just a case that the client that does rollback will not be given a second opportunity to consume those messages. This is what we currently do in the Java broker. This differs from JMS Client Ack Recover which calls Basic.Recover which does resend all the unacked messages so the client is guarranteed to get the same messages as the first time through. So given a transacted client that consumes messages then rolls back are you suggesting that the spec says that the client should not be able to receive the messages that it had been given in the transaction it rolled back? Martin - Aidan -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Website prototype take2
It looks good - what are the plans for getting the content up live? -Steve -Original Message- From: Jonathan Robie [mailto:jonathan.ro...@redhat.com] Sent: Thursday, May 20, 2010 5:49 PM To: dev@qpid.apache.org Subject: Re: Website prototype take2 Here's a slightly modified version of prototype 4, some of the changes are not visible, the main visible change is that the title and subtitle are larger than in Rajith and Robbie's designs: http://people.apache.org/~jonathan/website/ I'd consider this a minor modification of what we agreed on, and we can change it further if we need to. But is this a good design to start with? I'd also like to have higher res versions of the logos on the upper left and right, and might want to fiddle with the size Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2555) Qpid Info OSGI plugin
[ https://issues.apache.org/jira/browse/QPID-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sorin Suciu updated QPID-2555: -- Attachment: qpid-2555.patch info.tgz Qpid Info OSGI plugin - Key: QPID-2555 URL: https://issues.apache.org/jira/browse/QPID-2555 Project: Qpid Issue Type: New Feature Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Priority: Minor Fix For: 0.7 Attachments: info.tgz, QPID-2555-Feedback.txt, qpid-2555.patch This OSGI plugin is implementing an info service that would post broker information to a central location. It will activate on broker start and will http post the following information: QPID_HOME (eg /home/sorin/qpid-broker) QPID_WORK (eg /home/sorin) hostname (eg sorins-pc) ip (eg 192.168.1.24) java.class.path ( java.class.version (eg java.vm.name (eg os.arch (eg amd64) os.name (eg Linux) os.version (eg 2.6.18-128.7.1.el5) port (eg [5672]) sun.arch.data.model (eg 64) time (eg 2010-04-27 14:37:59.894+0100) user.dir (eg /home/sorin) user.name (eg sorin) user.timezone (eg Europe/London) This info is useful for large qpid deployments for automated monitoring purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2555) Qpid Info OSGI plugin
[ https://issues.apache.org/jira/browse/QPID-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sorin Suciu updated QPID-2555: -- Attachment: (was: info.tgz) Qpid Info OSGI plugin - Key: QPID-2555 URL: https://issues.apache.org/jira/browse/QPID-2555 Project: Qpid Issue Type: New Feature Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Priority: Minor Fix For: 0.7 Attachments: info.tgz, QPID-2555-Feedback.txt, qpid-2555.patch This OSGI plugin is implementing an info service that would post broker information to a central location. It will activate on broker start and will http post the following information: QPID_HOME (eg /home/sorin/qpid-broker) QPID_WORK (eg /home/sorin) hostname (eg sorins-pc) ip (eg 192.168.1.24) java.class.path ( java.class.version (eg java.vm.name (eg os.arch (eg amd64) os.name (eg Linux) os.version (eg 2.6.18-128.7.1.el5) port (eg [5672]) sun.arch.data.model (eg 64) time (eg 2010-04-27 14:37:59.894+0100) user.dir (eg /home/sorin) user.name (eg sorin) user.timezone (eg Europe/London) This info is useful for large qpid deployments for automated monitoring purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-2555) Qpid Info OSGI plugin
[ https://issues.apache.org/jira/browse/QPID-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sorin Suciu updated QPID-2555: -- Attachment: (was: qpid-2555.patch) Qpid Info OSGI plugin - Key: QPID-2555 URL: https://issues.apache.org/jira/browse/QPID-2555 Project: Qpid Issue Type: New Feature Components: Java Broker Affects Versions: 0.7 Reporter: Sorin Suciu Priority: Minor Fix For: 0.7 Attachments: info.tgz, QPID-2555-Feedback.txt, qpid-2555.patch This OSGI plugin is implementing an info service that would post broker information to a central location. It will activate on broker start and will http post the following information: QPID_HOME (eg /home/sorin/qpid-broker) QPID_WORK (eg /home/sorin) hostname (eg sorins-pc) ip (eg 192.168.1.24) java.class.path ( java.class.version (eg java.vm.name (eg os.arch (eg amd64) os.name (eg Linux) os.version (eg 2.6.18-128.7.1.el5) port (eg [5672]) sun.arch.data.model (eg 64) time (eg 2010-04-27 14:37:59.894+0100) user.dir (eg /home/sorin) user.name (eg sorin) user.timezone (eg Europe/London) This info is useful for large qpid deployments for automated monitoring purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] transaction handling
On 05/21/2010 02:43 PM, Martin Ritchie wrote: On 1 April 2010 01:26, Aidan Skinneraidan.skin...@gmail.com wrote: I've recently been wrestling with transaction handling in the java broker in the context of 0-9-1 compliance. We're currently not strictly spec compliant with 0-9-1 as we will resend messages that have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter, and I've been trying to retain current behaviour for them. However, it's a) a massive PITA and b) probably Not What You Want. If you're rolling back a consume it's almost certainly because you can't cope with the message. If you think b) I'd like to float the idea of 0.8 being the we are breaking backwards compatibility release so we can fix the conf file, the command line etc. Thoughts? I don't read the spec in the same way. From the 0-9-1 Spec: 1.9.2.5. Method tx.rollback (ID 30) This method abandons all message publications and acknowledgments performed in the current transaction. A new transaction starts immediately after a rollback. Note that unacked messages will not be automatically redelivered by rollback; if that is required an explicit recover call should be issued. I read that as the unacked messages will not be automatically given back to the client. So we should put them back on the queue and let the client fight it out with other cilents to see who gets them. My understanding is that they would remain in the 'acquired' state, not acked but not requeued. The client could then decide to call recover explicitly to either requeue them or have them redelivered (or it could simply replay them itself if held locally). In 0-8/0-9 it was not explicitly stated that there should be a recover(requeue=false) implied by rollback but we assumed this as the spec did prohibit an explicit recover call for transactional sessions. 0-9-1 explicitly stated that the recover was not implied, but allowed the recover to be called on a transactional session if desired. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2624) NPE thrown when virtualhost.xml file cannot be loaded
NPE thrown when virtualhost.xml file cannot be loaded - Key: QPID-2624 URL: https://issues.apache.org/jira/browse/QPID-2624 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6 Reporter: Martin Ritchie If the specfied virtualhost.xml file does not exist when the broker is started up a NullPointerException: at org.apache.qpid.server.configuration.ServerConfiguration.parseConfig(ServerConfiguration.java:217) at org.apache.qpid.server.configuration.ServerConfiguration.setupVirtualHosts(ServerConfiguration.java:180) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [java] transaction handling
On 21 May 2010 17:57, Gordon Sim g...@redhat.com wrote: On 05/21/2010 02:43 PM, Martin Ritchie wrote: On 1 April 2010 01:26, Aidan Skinneraidan.skin...@gmail.com wrote: I've recently been wrestling with transaction handling in the java broker in the context of 0-9-1 compliance. We're currently not strictly spec compliant with 0-9-1 as we will resend messages that have been rolled back. 0-9 and 0-8 are... ambiguous... on this matter, and I've been trying to retain current behaviour for them. However, it's a) a massive PITA and b) probably Not What You Want. If you're rolling back a consume it's almost certainly because you can't cope with the message. If you think b) I'd like to float the idea of 0.8 being the we are breaking backwards compatibility release so we can fix the conf file, the command line etc. Thoughts? I don't read the spec in the same way. From the 0-9-1 Spec: 1.9.2.5. Method tx.rollback (ID 30) This method abandons all message publications and acknowledgments performed in the current transaction. A new transaction starts immediately after a rollback. Note that unacked messages will not be automatically redelivered by rollback; if that is required an explicit recover call should be issued. I read that as the unacked messages will not be automatically given back to the client. So we should put them back on the queue and let the client fight it out with other cilents to see who gets them. My understanding is that they would remain in the 'acquired' state, not acked but not requeued. The client could then decide to call recover explicitly to either requeue them or have them redelivered (or it could simply replay them itself if held locally). In 0-8/0-9 it was not explicitly stated that there should be a recover(requeue=false) implied by rollback but we assumed this as the spec did prohibit an explicit recover call for transactional sessions. 0-9-1 explicitly stated that the recover was not implied, but allowed the recover to be called on a transactional session if desired. Thanks for the clarification.. Sounds like we should be calling a recover on the 0-9-1 session then, and stop the Java broker 'auto-recovering' as it is just now. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Website prototype take2
On 05/21/2010 12:46 PM, Jonathan Robie wrote: I am setting up a system to generate pages using this template, using HTML fragments that represent the main text for a given page. I think that's important to make sure that that the pages are consistent. Basically, you'll stick the HTML content for a given page, wrapped in a div/ element, in a separate file, and there will be simple way to expand it into a full-fledged page that uses this template. I expect to have that today. I've checked these tools into trunk/qpid/doc/website now. Look at README.txt in the main directory to see how to write pages, look at the source in website/content for examples. After that - we have to convert static pages for the site, and link to Wiki pages for content not yet converted or not yet available. Who can help with that? I've created some content and built some pages to verify the Python script that creates pages in the template format and put them here for your viewing pleasure: http://people.apache.org/~jonathan/qpid-site/ The following pages have been done in that prototype: index.html acknowledgements.html amqp.html compatibility.html download.html getting_started.html mailing_lists.html people.html qpid_integrated_with.html source_repository.html Anyone want to help by creating new content and placing it in website/content? I'll be back on Wednesday. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2625) Allow Broker Plugins to leaverage the Logging Framework
Allow Broker Plugins to leaverage the Logging Framework --- Key: QPID-2625 URL: https://issues.apache.org/jira/browse/QPID-2625 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Martin Ritchie Assignee: Martin Ritchie Expose the generated logging framework to allow plugins to define their own logging. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
