[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866422#action_12866422 ] Rajith Attapattu commented on QPID-2589: I noticed that the binding lives inside the cpp dir. I would assume this is temporary and that it will eventually be moved out to a suitable location? > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- 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] Created: (QPID-2600) ACL policy doesn't permit certain characters in usernames added to groups
ACL policy doesn't permit certain characters in usernames added to groups - Key: QPID-2600 URL: https://issues.apache.org/jira/browse/QPID-2600 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.6 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Priority: Minor Fix For: 0.7 Description of problem: Unable to add a host principle to a group, the acl policy file fails to load and prevents qpidd from running. I guess this is partly due to us not figuring out what is exactly allowed for group and usernames. How reproducible: Fails every time. Steps to Reproduce: 1. Add a host or service principle to a group in the acl file. Something like this will suffice: group somegroup host/somemachine.example@example.com Actual results: Failure to start. Error message is: Daemon startup failed: Could not read ACL file ACL format error: /etc/qpid/policy.acl:25: Name "host/somemachine.example@example.com" contains illegal characters. Expected results: Should load and parse the group cleanly. -- 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: info.tgz Attached a new version incorporating Martin suggestions. What is not ready yet (and I would suggest leaving it for the next commit): - QPID_WORK still taken from environment and not from ApplicationRegistry. as getConfiguration seems not to be static. - Activator testing could be improved by testing with a mock BundleContext. > 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, 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] Created: (QPID-2599) Allow Qpid users to configure the Java client logging using an sl4j binding of their choice, instead of Qpid shipping a defualt binding.
Allow Qpid users to configure the Java client logging using an sl4j binding of their choice, instead of Qpid shipping a defualt binding. Key: QPID-2599 URL: https://issues.apache.org/jira/browse/QPID-2599 Project: Qpid Issue Type: Improvement Components: Java Client Affects Versions: 0.6, 0.5 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: 0.7 All though we have a logging facade (slf4j) in the java client, we complicate the situation by shipping slf4j-log4j binding along with our release artifacts. If not configured properly log4j will default to using DEBUG which degrades the performance. The situation complicated as we have a whole bunch of log4j.xmls and property files lying all over the place. We have discussed and arrived at some consensus on the following thread. http://apache-qpid-developers.2158895.n2.nabble.com/Java-Client-Logging-yet-again-td4696020.html#a4696020 The action plan for solving this includes. 1. Remove all log4j.xml and log4j.properties files from the code based (except for the ones in broker/etc ) 2. Remove slf4j-log4j.jar from our release artefacts. The reason this is present in the java/lib folder is due to our test framework relying on log4j for capturing client logs for debug. 3. Document clearly the logging mechanism in the "Programming-In-Apache-Qpid' guide." This should include how one could change to a different slf4j binding 4. Upstream packages could use a binding of their choice. -- 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] Created: (QPID-2598) C++ clients hang at program end since April 16, 2010
C++ clients hang at program end since April 16, 2010 Key: QPID-2598 URL: https://issues.apache.org/jira/browse/QPID-2598 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.7 Environment: Windows Reporter: Steve Huston Priority: Critical C++ client code on Windows hangs at program shutdown. It appears that this started with svn r934503 (related to QPID-2511). Symptom is that at program end, the IOThread is hung waiting for there to be 0 connections but that never happens. The sockets are open. All the python-based tests are ok, but the C++ ones hang. -- 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: [.net]: some debate please
Hi Carl, > -Original Message- > From: Carl Trieloff [mailto:cctriel...@redhat.com] > > On 05/11/2010 04:28 PM, Steve Huston wrote: > >> -Original Message- > >> From: Gordon Sim [mailto:g...@redhat.com] > >> > >> On 05/10/2010 09:33 PM, tr...@apache.org wrote: > >> > >>> Author: tross > >>> Date: Mon May 10 20:33:19 2010 > >>> New Revision: 942892 > >>> > >>> URL: http://svn.apache.org/viewvc?rev=942892&view=rev > >>> Log: > >>> QPID-2589 - Applied patch from Chuck Rolke. > >>> > >> This commit adds a new component and yet another approach > for .net, > >> specifically a .net wrapper around the c++ messaging API. > >> > >> We also have a wcf client (this also uses some c++ code, > but uses the > >> 0-10 specific API plus some direct use of the internals of the > >> client), and two different pure c# clients for 0-8 and 0-10 > >> respectively. > >> > >> Four different options each with its own codebase isn't > sensible. We > >> can't maintain them all and it is confusing for users. > >> > > Right. This is nuts. > > > > > >> While aspects of this latest approach certainly appeal to me > >> personally (the messaging API is better for a number of > reasons than > >> the older API > >> and wrapping that also keeps the clients more aligned > >> conceptually), I > >> think it deserves a bit more debate. Specifically we have to > >> explicitly > >> decide as a community whether this new approach is a path we should > >> pursue. I'm keen to hear the thoughts of Cliff, Aidan and > other .net > >> aficionados. > >> > > I'm certainly not up to Cliff's level w/ .NET but I agree > with Gordon > > - this new approach is more elegant and probably more maintainable. > > However, nobody has discussed: > > > > - What about the older .NET component(s)? > > > > Deprecate them I agree with this. > > - How might this affect WCF? > > > > The current WCF uses the 0-10 API, I would suggest moving the > WCF client to the updated C++ API. I believe this has been > agreed to be done at some point before on the list which > would then be consistent with this work Ok, as long as somebody is committed to follow through with it - the existing WCF was a sizeable effort. > > - Has anyone thought of how to package this? > > > > I would package in the same way we package QMF binding to C++ Ok... Again, someone needs to follow through with this. I don't have funding at this point to extend the installer for 0.8. > > - Does it have any documentation or tests? > > > > no idea.. Code without tests is a bad idea. I'd also say that new client/user code must have documentation too. -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [.net]: some debate please
> -Original Message- > From: Rajith Attapattu [mailto:rajit...@gmail.com] > > While I will leave it to the experts to comment about the > current approach, may I suggest that we make a prominent > notice in our download page that we have deprecated the 0-8 > and 0-10 .NET clients. Good idea... A nice explanation that the .NET 0-8 and 0-10 clients will not be maintained and will not be in the Qpid 0.8 or future releases, along with a short explanation why and mention that 0.6 also includes WCF/.NET which will be included in future versions. > I know that several individuals have > put in some very good effort in the thankless task of > propping up these two code bases. But we have to be > pragmatic, and understand that we do not have the resources > to manage all these code bases. Right, and a plea for improvements/fixes got a little attention months ago and has since gone dead again, AFAIK. > I would actually go one step ahead and delete the 0-8 and > 0-10 client artefacts from our download page to prevent > people from using them any further. We should also probably > move those code bases out of the main tree into a "boneyard" dir. They could always be resurrected from svn if needed - I don't see a need for a "boneyard" area. -Steve > On Tue, May 11, 2010 at 3:36 PM, Gordon Sim wrote: > > On 05/10/2010 09:33 PM, tr...@apache.org wrote: > >> > >> Author: tross > >> Date: Mon May 10 20:33:19 2010 > >> New Revision: 942892 > >> > >> URL: http://svn.apache.org/viewvc?rev=942892&view=rev > >> Log: > >> QPID-2589 - Applied patch from Chuck Rolke. > > > > This commit adds a new component and yet another approach for .net, > > specifically a .net wrapper around the c++ messaging API. > > > > We also have a wcf client (this also uses some c++ code, > but uses the > > 0-10 specific API plus some direct use of the internals of the > > client), and two different pure c# clients for 0-8 and 0-10 > > respectively. > > > > Four different options each with its own codebase isn't > sensible. We > > can't maintain them all and it is confusing for users. > > > > While aspects of this latest approach certainly appeal to me > > personally (the messaging API is better for a number of > reasons than > > the older API and wrapping that also keeps the clients more aligned > > conceptually), I think it deserves a bit more debate. > Specifically we > > have to explicitly decide as a community whether this new > approach is > > a path we should pursue. I'm keen to hear the thoughts of > Cliff, Aidan > > and other .net aficionados. > > > > --Gordon > > > > > - > > Apache Qpid - AMQP Messaging Implementation > > Project: http://qpid.apache.org > > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > > > > > > > -- > Regards, > > Rajith Attapattu > Red Hat > http://rajith.2rlabs.com/ > > - > 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
Re: [.net]: some debate please
On 05/11/2010 05:22 PM, Martin Ritchie wrote: -- Martin Sent from my iPhone On 11 May 2010, at 21:36, Rajith Attapattu wrote: While I will leave it to the experts to comment about the current approach, may I suggest that we make a prominent notice in our download page that we have deprecated the 0-8 and 0-10 .NET clients. I know that several individuals have put in some very good effort in the thankless task of propping up these two code bases. But we have to be pragmatic, and understand that we do not have the resources to manage all these code bases. I would actually go one step ahead and delete the 0-8 and 0-10 client artefacts from our download page to prevent people from using them any further. I'd leave the artefacts up for the previosly releases we just should ship them again as that implies that have been maintained. I've said this before but I think our approach to always releasing every component at once is wrong. If no work has been done to maintain or test components then they shouldn't get a new release. +1 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
-- Martin Sent from my iPhone On 11 May 2010, at 21:36, Rajith Attapattu wrote: While I will leave it to the experts to comment about the current approach, may I suggest that we make a prominent notice in our download page that we have deprecated the 0-8 and 0-10 .NET clients. I know that several individuals have put in some very good effort in the thankless task of propping up these two code bases. But we have to be pragmatic, and understand that we do not have the resources to manage all these code bases. I would actually go one step ahead and delete the 0-8 and 0-10 client artefacts from our download page to prevent people from using them any further. I'd leave the artefacts up for the previosly releases we just should ship them again as that implies that have been maintained. I've said this before but I think our approach to always releasing every component at once is wrong. If no work has been done to maintain or test components then they shouldn't get a new release. We should also probably move those code bases out of the main tree into a "boneyard" dir. This seem like a good idea we have discussed this notion before. We also talked about an experimental directory for incomming work, such as this new client, so we can evaluate and see there is some level of commitment to maintain it. To that end I've added an experimental dir to the java broker-plugins, but more on that when I have a full keyboard. Regards, Rajith On Tue, May 11, 2010 at 3:36 PM, Gordon Sim wrote: On 05/10/2010 09:33 PM, tr...@apache.org wrote: Author: tross Date: Mon May 10 20:33:19 2010 New Revision: 942892 URL: http://svn.apache.org/viewvc?rev=942892&view=rev Log: QPID-2589 - Applied patch from Chuck Rolke. This commit adds a new component and yet another approach for .net, specifically a .net wrapper around the c++ messaging API. We also have a wcf client (this also uses some c++ code, but uses the 0-10 specific API plus some direct use of the internals of the client), and two different pure c# clients for 0-8 and 0-10 respectively. Four different options each with its own codebase isn't sensible. We can't maintain them all and it is confusing for users. While aspects of this latest approach certainly appeal to me personally (the messaging API is better for a number of reasons than the older API and wrapping that also keeps the clients more aligned conceptually), I think it deserves a bit more debate. Specifically we have to explicitly decide as a community whether this new approach is a path we should pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net aficionados. --Gordon - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - 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] Resolved: (QPID-2594) Exception chaining for JMSExceptions
[ https://issues.apache.org/jira/browse/QPID-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved QPID-2594. -- Resolution: Fixed Patch applied by Rajith > Exception chaining for JMSExceptions > > > Key: QPID-2594 > URL: https://issues.apache.org/jira/browse/QPID-2594 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Affects Versions: 0.6 >Reporter: Emmanuel Bourg >Priority: Minor > Fix For: 0.7 > > Attachments: initcause.patch > > > JMSException has an archaic mechanism to chain the root cause by calling the > setLinkedException() method. It predates the introduction of the > Throwable.initCause() method in Java 1.4 which standardized the exception > chaining. > Currently when Qpid creates a JMSException the initCause() method isn't > always called. This results in difficult to interpret stacktraces which are > missing the root cause. > The right behavior would be to call both methods, setLinkedException and > initCause, to maintain the backward compatibility with code looking at the > linked exception and to display the full exception chain when the exception > is printed. -- 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: [.net]: some debate please
While I will leave it to the experts to comment about the current approach, may I suggest that we make a prominent notice in our download page that we have deprecated the 0-8 and 0-10 .NET clients. I know that several individuals have put in some very good effort in the thankless task of propping up these two code bases. But we have to be pragmatic, and understand that we do not have the resources to manage all these code bases. I would actually go one step ahead and delete the 0-8 and 0-10 client artefacts from our download page to prevent people from using them any further. We should also probably move those code bases out of the main tree into a "boneyard" dir. Regards, Rajith On Tue, May 11, 2010 at 3:36 PM, Gordon Sim wrote: > On 05/10/2010 09:33 PM, tr...@apache.org wrote: >> >> Author: tross >> Date: Mon May 10 20:33:19 2010 >> New Revision: 942892 >> >> URL: http://svn.apache.org/viewvc?rev=942892&view=rev >> Log: >> QPID-2589 - Applied patch from Chuck Rolke. > > This commit adds a new component and yet another approach for .net, > specifically a .net wrapper around the c++ messaging API. > > We also have a wcf client (this also uses some c++ code, but uses the 0-10 > specific API plus some direct use of the internals of the client), and two > different pure c# clients for 0-8 and 0-10 respectively. > > Four different options each with its own codebase isn't sensible. We can't > maintain them all and it is confusing for users. > > While aspects of this latest approach certainly appeal to me personally (the > messaging API is better for a number of reasons than the older API and > wrapping that also keeps the clients more aligned conceptually), I think it > deserves a bit more debate. Specifically we have to explicitly decide as a > community whether this new approach is a path we should pursue. I'm keen to > hear the thoughts of Cliff, Aidan and other .net aficionados. > > --Gordon > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [.net]: some debate please
On 05/11/2010 04:28 PM, Steve Huston wrote: -Original Message- From: Gordon Sim [mailto:g...@redhat.com] On 05/10/2010 09:33 PM, tr...@apache.org wrote: Author: tross Date: Mon May 10 20:33:19 2010 New Revision: 942892 URL: http://svn.apache.org/viewvc?rev=942892&view=rev Log: QPID-2589 - Applied patch from Chuck Rolke. This commit adds a new component and yet another approach for .net, specifically a .net wrapper around the c++ messaging API. We also have a wcf client (this also uses some c++ code, but uses the 0-10 specific API plus some direct use of the internals of the client), and two different pure c# clients for 0-8 and 0-10 respectively. Four different options each with its own codebase isn't sensible. We can't maintain them all and it is confusing for users. Right. This is nuts. While aspects of this latest approach certainly appeal to me personally (the messaging API is better for a number of reasons than the older API and wrapping that also keeps the clients more aligned conceptually), I think it deserves a bit more debate. Specifically we have to explicitly decide as a community whether this new approach is a path we should pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net aficionados. I'm certainly not up to Cliff's level w/ .NET but I agree with Gordon - this new approach is more elegant and probably more maintainable. However, nobody has discussed: - What about the older .NET component(s)? Deprecate them - How might this affect WCF? The current WCF uses the 0-10 API, I would suggest moving the WCF client to the updated C++ API. I believe this has been agreed to be done at some point before on the list which would then be consistent with this work - Has anyone thought of how to package this? I would package in the same way we package QMF binding to C++ - Does it have any documentation or tests? no idea.. my 2 cents. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [.net]: some debate please
> -Original Message- > From: Gordon Sim [mailto:g...@redhat.com] > > On 05/10/2010 09:33 PM, tr...@apache.org wrote: > > Author: tross > > Date: Mon May 10 20:33:19 2010 > > New Revision: 942892 > > > > URL: http://svn.apache.org/viewvc?rev=942892&view=rev > > Log: > > QPID-2589 - Applied patch from Chuck Rolke. > > This commit adds a new component and yet another approach for .net, > specifically a .net wrapper around the c++ messaging API. > > We also have a wcf client (this also uses some c++ code, but uses the > 0-10 specific API plus some direct use of the internals of > the client), > and two different pure c# clients for 0-8 and 0-10 respectively. > > Four different options each with its own codebase isn't sensible. We > can't maintain them all and it is confusing for users. Right. This is nuts. > While aspects of this latest approach certainly appeal to me > personally > (the messaging API is better for a number of reasons than the > older API > and wrapping that also keeps the clients more aligned > conceptually), I > think it deserves a bit more debate. Specifically we have to > explicitly > decide as a community whether this new approach is a path we should > pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net > aficionados. I'm certainly not up to Cliff's level w/ .NET but I agree with Gordon - this new approach is more elegant and probably more maintainable. However, nobody has discussed: - What about the older .NET component(s)? - How might this affect WCF? - Has anyone thought of how to package this? - Does it have any documentation or tests? -Steve - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2589) Add a .NET binding to QPID Messaging API
[ https://issues.apache.org/jira/browse/QPID-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866303#action_12866303 ] Gordon Sim commented on QPID-2589: -- Would it be possible to build the WCF (channel and service interfaces) on top of this API? > Add a .NET binding to QPID Messaging API > > > Key: QPID-2589 > URL: https://issues.apache.org/jira/browse/QPID-2589 > Project: Qpid > Issue Type: New Feature > Components: C++ Client >Affects Versions: 0.7 > Environment: Windows >Reporter: Chuck Rolke >Assignee: Ted Ross > Fix For: 0.7 > > Attachments: qpid_bindings.diff > > > This binding package is a .NET Interop wrapper around the Qpid Messaging > interface. It exposes the Messaging interface through a series of managed > code classes that may be used by any .NET language. -- 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-2596) Transaction Rollback does not restore consumer credit
[ https://issues.apache.org/jira/browse/QPID-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2596: - Status: Ready To Review (was: In Progress) > Transaction Rollback does not restore consumer credit > - > > Key: QPID-2596 > URL: https://issues.apache.org/jira/browse/QPID-2596 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.6 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > > When a transaction rollback occurs on the 0-8/0-9/0-91 code path the messages > are put back on to the queue but the subscriber is not credited for them. > This can be seen with a small prefetch. The credit is lost and the client > starves. > Adding a restoreCredit call in the message release will address this issue. -- 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-2597) Provide scavenge() for SimpleQueueEntryList
[ https://issues.apache.org/jira/browse/QPID-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-2597: - Status: Ready To Review (was: In Progress) > Provide scavenge() for SimpleQueueEntryList > --- > > Key: QPID-2597 > URL: https://issues.apache.org/jira/browse/QPID-2597 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.6 >Reporter: Martin Ritchie >Assignee: Martin Ritchie > Fix For: 0.7 > > > Currently selectors, multiple consumers and message expiry can cause messages > to be deleted mid queue. These are left as deleted entries in the list and > will not be GC'd as they are part of the list structure. > This scavenge method will walk the list and remove them. -- 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
[.net]: some debate please
On 05/10/2010 09:33 PM, tr...@apache.org wrote: Author: tross Date: Mon May 10 20:33:19 2010 New Revision: 942892 URL: http://svn.apache.org/viewvc?rev=942892&view=rev Log: QPID-2589 - Applied patch from Chuck Rolke. This commit adds a new component and yet another approach for .net, specifically a .net wrapper around the c++ messaging API. We also have a wcf client (this also uses some c++ code, but uses the 0-10 specific API plus some direct use of the internals of the client), and two different pure c# clients for 0-8 and 0-10 respectively. Four different options each with its own codebase isn't sensible. We can't maintain them all and it is confusing for users. While aspects of this latest approach certainly appeal to me personally (the messaging API is better for a number of reasons than the older API and wrapping that also keeps the clients more aligned conceptually), I think it deserves a bit more debate. Specifically we have to explicitly decide as a community whether this new approach is a path we should pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net aficionados. --Gordon - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2597) Provide scavenge() for SimpleQueueEntryList
Provide scavenge() for SimpleQueueEntryList --- Key: QPID-2597 URL: https://issues.apache.org/jira/browse/QPID-2597 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6 Reporter: Martin Ritchie Assignee: Martin Ritchie Fix For: 0.7 Currently selectors, multiple consumers and message expiry can cause messages to be deleted mid queue. These are left as deleted entries in the list and will not be GC'd as they are part of the list structure. This scavenge method will walk the list and remove them. -- 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-2541) Separate Group an ACL configuration and make group sources pluggable
[ https://issues.apache.org/jira/browse/QPID-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866252#action_12866252 ] Rajith Attapattu commented on QPID-2541: Continuing the discussion from QPID-2539, I think there absolutely no value in a group mechanism that is not tied to authentication. Infact I think it's a security loophole that can be exploited. Also we need to be careful when adding features. Unless there is a demonstrable need for such changes we shouldn't be just adding features for the sake of it. This is not say that we shouldn't allow a pluggable group mechanism, but to stress the point that it's not useful if it's not tied to the authentication mechanism. > Separate Group an ACL configuration and make group sources pluggable > > > Key: QPID-2541 > URL: https://issues.apache.org/jira/browse/QPID-2541 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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] Created: (QPID-2596) Transaction Rollback does not restore consumer credit
Transaction Rollback does not restore consumer credit - Key: QPID-2596 URL: https://issues.apache.org/jira/browse/QPID-2596 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6 Reporter: Martin Ritchie Assignee: Martin Ritchie When a transaction rollback occurs on the 0-8/0-9/0-91 code path the messages are put back on to the queue but the subscriber is not credited for them. This can be seen with a small prefetch. The credit is lost and the client starves. Adding a restoreCredit call in the message release will address this issue. -- 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 Client Logging (yet again !)
On Tue, May 11, 2010 at 1:50 PM, Martin Ritchie wrote: > Sorry for late response I seem to be unable to access gmail at work just > now. > > -- > Martin > > Sent from my iPhone > > On 11 May 2010, at 17:59, Rajith Attapattu wrote: > >> Since, there doesn't seem to be any objections, I will proceed with my >> plan in the evening. >> >> Rajith >> >> On Mon, May 10, 2010 at 2:12 PM, Rajith Attapattu >> wrote: >>> >>> On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu >>> wrote: Sorry for allowing this thread to rot a bit. Based on all the comments we had so far, let me try to summarize on what we have seemed to reach some consensus. 1. We agreed that all though not shipping a slf4j binding is a plausible option, it does pose some challengers w.r.t running examples out of the box. 2. Most people disagreed about shipping our own plugging. 3. Shipping the slf4j-jdk1.4 a.k.a Java Logging binding was brought up as a possible solution. Based on the above, may I suggest the following. 1. Remove all log4j.xml and log4j.properties files from the code based (except for the ones in broker/etc ) > > Sounds good > 2. Remove the slf4j-log4j binding from java/lib 3. Put sl4j-log4j binding in the test-profiles/test-resources as our test output is configured using log4j and set the path in ant test. 4. Put sl4j-jdk1.4 binding in client/example/lib folder > > I don't see why you want to move the jar from our lib dir. Curretly java/lib > is where all our 3rd party jars live. I think it would be beat to keep them > all on the same place. Ok fair enough, however then we need to make sure, we do not copy that into our distributions. Our distributions should just include the slf4j-api, which will (from 1.6.0 onwards) print a message and discard any subsequent logging if no binding is detected. 5. Document clearly the logging mechanism in the "Programming-In-Apache-Qpid' guide. This should include how one could change to a different slf4j binding 6. Upstream packages could use a binding of their choice. 7. Eventually when when we ship bundles in Qpid that works out-of-box we could use the sl4j-jdk1.4 to ensure the logging works. > > We can ship bundles now, we just nee to choose to. I'll make some builds up > tonight so we can talk about concrete artifacts. > > >>> Ceki Gülcü has kindly brought to my attention, that from SLF4J version >>> 1.6.0, if no binding is found, it will print the following message and >>> continue to discard the rest. >>> (Earlier it threw and exception). >>> >>> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". >>> SLF4J: Defaulting to no-operation (NOP) logger implementation >>> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for >>> further details. >>> >>> So we could probably ship our bundle (item 7) without any binding. >>> If the end user needs to do any sort of further debugging, then they >>> could download a binding of their choice and configure it the way they >>> like. >>> In our documentation we should provide information on how our logger >>> objects are configured, so they would know what to enable etc.. >>> >>> Rajith >>> Does this sound like a plan? If you see anything wrong or disagree, please shout. Regards, Rajith. On Wed, Mar 24, 2010 at 6:47 PM, Robbie Gemmell wrote: > >> -Original Message- >> From: Gordon Sim [mailto:g...@redhat.com] >> Sent: 24 March 2010 18:59 >> To: dev@qpid.apache.org >> Subject: Re: Java Client Logging (yet again !) >> >> On 03/23/2010 09:20 PM, Robbie Gemmell wrote: >>> >>> Alternatively, shipping the JDK bindings by default could be a viable >>> option, working out the box but requiring that users actually >>> configure java.util.logging to required behaviour. >> >> I like this approach. >> >> It doesn't have to be in the same location as the core jars if that is >> felt to cause confusion. Perhaps e.g. bundled with examples or >> similar[1]. >> >>> I would think that anyone who doesn't care enough to configure the >>> logging at all might reasonably expect not to be too surprised to >>> find there are none, if they ever even looked at the logs. >> >> I think it can be frustrating for people trying to get familiar with >> the >> project to debug simple problems with packaged examples or tools if >> there is no logging available. >> >> Not everyone who ends up trying to get something working with the JMS >> client has experience with sl4j. Having to dig around on information >> on >> what to download, where to install it and then what format of file >> needs >> to be created is significantly harder than e.g. the python or c++ >> clients. Making that easier is in my view quite reasonable. Having
Re: Java Client Logging (yet again !)
Sorry for late response I seem to be unable to access gmail at work just now. -- Martin Sent from my iPhone On 11 May 2010, at 17:59, Rajith Attapattu wrote: Since, there doesn't seem to be any objections, I will proceed with my plan in the evening. Rajith On Mon, May 10, 2010 at 2:12 PM, Rajith Attapattu wrote: On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu wrote: Sorry for allowing this thread to rot a bit. Based on all the comments we had so far, let me try to summarize on what we have seemed to reach some consensus. 1. We agreed that all though not shipping a slf4j binding is a plausible option, it does pose some challengers w.r.t running examples out of the box. 2. Most people disagreed about shipping our own plugging. 3. Shipping the slf4j-jdk1.4 a.k.a Java Logging binding was brought up as a possible solution. Based on the above, may I suggest the following. 1. Remove all log4j.xml and log4j.properties files from the code based (except for the ones in broker/etc ) Sounds good 2. Remove the slf4j-log4j binding from java/lib 3. Put sl4j-log4j binding in the test-profiles/test-resources as our test output is configured using log4j and set the path in ant test. 4. Put sl4j-jdk1.4 binding in client/example/lib folder I don't see why you want to move the jar from our lib dir. Curretly java/lib is where all our 3rd party jars live. I think it would be beat to keep them all on the same place. 5. Document clearly the logging mechanism in the "Programming-In-Apache-Qpid' guide. This should include how one could change to a different slf4j binding 6. Upstream packages could use a binding of their choice. 7. Eventually when when we ship bundles in Qpid that works out-of- box we could use the sl4j-jdk1.4 to ensure the logging works. We can ship bundles now, we just nee to choose to. I'll make some builds up tonight so we can talk about concrete artifacts. Ceki Gülcü has kindly brought to my attention, that from SLF4J ver sion 1.6.0, if no binding is found, it will print the following message and continue to discard the rest. (Earlier it threw and exception). SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. So we could probably ship our bundle (item 7) without any binding. If the end user needs to do any sort of further debugging, then they could download a binding of their choice and configure it the way they like. In our documentation we should provide information on how our logger objects are configured, so they would know what to enable etc.. Rajith Does this sound like a plan? If you see anything wrong or disagree, please shout. Regards, Rajith. On Wed, Mar 24, 2010 at 6:47 PM, Robbie Gemmell wrote: -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: 24 March 2010 18:59 To: dev@qpid.apache.org Subject: Re: Java Client Logging (yet again !) On 03/23/2010 09:20 PM, Robbie Gemmell wrote: Alternatively, shipping the JDK bindings by default could be a viable option, working out the box but requiring that users actually configure java.util.logging to required behaviour. I like this approach. It doesn't have to be in the same location as the core jars if that is felt to cause confusion. Perhaps e.g. bundled with examples or similar[1]. I would think that anyone who doesn't care enough to configure the logging at all might reasonably expect not to be too surprised to find there are none, if they ever even looked at the logs. I think it can be frustrating for people trying to get familiar with the project to debug simple problems with packaged examples or tools if there is no logging available. Not everyone who ends up trying to get something working with the JMS client has experience with sl4j. Having to dig around on information on what to download, where to install it and then what format of file needs to be created is significantly harder than e.g. the python or c++ clients. Making that easier is in my view quite reasonable. Having at least warning level messages be visible is also a help. --Gordon [1] I always feel like there something missing on the java side when testing releases - no test app or examples to run. We do actually have examples, but we don't currently ship them in the standalone client bundle and they just get lost in the noise of the full bundle, since the lib dir has such a vast number and mix of jars and it also isn't that clear how to run/use them. I like Martin's suggestion for shipping them as a side dir in the client bundle, and from there we could make it clear how to leverage one or two of them as a specific test or first time user example. I agree that having logging available easily is a good thing and is obviously very useful for new people to the project to debug t
Re: [Java] The use of setLinkedException in JMSException is not a good idea
Thx, I really appreciate it. I have committed the patch. Rajith On Tue, May 11, 2010 at 11:29 AM, Emmanuel Bourg wrote: > Le 11/05/2010 15:44, Rajith Attapattu a écrit : > >> I am slammed atm, so a patch would be very much appreciated ! > > Here it is: > > https://issues.apache.org/jira/browse/QPID-2594 > > https://issues.apache.org/jira/secure/attachment/12444205/initcause.patch > > Emmanuel Bourg > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866217#action_12866217 ] Carl Trieloff commented on QPID-2539: - I miss-typed the one example, method is an object. I really don't get why you keep putting in 'manage' -- what does that mean - access, update, delete ? or all of them? Carl. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2595) WCF programming guide documentation
[ https://issues.apache.org/jira/browse/QPID-2595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated QPID-2595: --- Attachment: QPID-2595.patch A chapter on using the WCF channel with code examples > WCF programming guide documentation > --- > > Key: QPID-2595 > URL: https://issues.apache.org/jira/browse/QPID-2595 > Project: Qpid > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.7 >Reporter: Cliff Jansen > Fix For: 0.7 > > Attachments: QPID-2595.patch > > > WCF/C++ client programming documentation -- 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 Client Logging (yet again !)
Since, there doesn't seem to be any objections, I will proceed with my plan in the evening. Rajith On Mon, May 10, 2010 at 2:12 PM, Rajith Attapattu wrote: > On Mon, May 10, 2010 at 1:00 PM, Rajith Attapattu wrote: >> Sorry for allowing this thread to rot a bit. >> Based on all the comments we had so far, let me try to summarize on >> what we have seemed to reach some consensus. >> >> 1. We agreed that all though not shipping a slf4j binding is a >> plausible option, it does pose some challengers w.r.t running >> examples out of the box. >> 2. Most people disagreed about shipping our own plugging. >> 3. Shipping the slf4j-jdk1.4 a.k.a Java Logging binding was brought up >> as a possible solution. >> >> Based on the above, may I suggest the following. >> >> 1. Remove all log4j.xml and log4j.properties files from the code based >> (except for the ones in broker/etc ) >> >> 2. Remove the slf4j-log4j binding from java/lib >> >> 3. Put sl4j-log4j binding in the test-profiles/test-resources as our >> test output is configured using log4j and set the path in ant test. >> >> 4. Put sl4j-jdk1.4 binding in client/example/lib folder >> >> 5. Document clearly the logging mechanism in the >> "Programming-In-Apache-Qpid' guide. >> This should include how one could change to a different slf4j binding >> >> 6. Upstream packages could use a binding of their choice. >> >> 7. Eventually when when we ship bundles in Qpid that works out-of-box >> we could use the sl4j-jdk1.4 to ensure the logging works. > > Ceki Gülcü has kindly brought to my attention, that from SLF4J version > 1.6.0, if no binding is found, it will print the following message and > continue to discard the rest. > (Earlier it threw and exception). > > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". > SLF4J: Defaulting to no-operation (NOP) logger implementation > SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for > further details. > > So we could probably ship our bundle (item 7) without any binding. > If the end user needs to do any sort of further debugging, then they > could download a binding of their choice and configure it the way they > like. > In our documentation we should provide information on how our logger > objects are configured, so they would know what to enable etc.. > > Rajith > >> Does this sound like a plan? If you see anything wrong or disagree, >> please shout. >> >> Regards, >> >> Rajith. >> >> On Wed, Mar 24, 2010 at 6:47 PM, Robbie Gemmell >> wrote: >>> -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: 24 March 2010 18:59 To: dev@qpid.apache.org Subject: Re: Java Client Logging (yet again !) On 03/23/2010 09:20 PM, Robbie Gemmell wrote: > Alternatively, shipping the JDK bindings by default could be a viable > option, working out the box but requiring that users actually > configure java.util.logging to required behaviour. I like this approach. It doesn't have to be in the same location as the core jars if that is felt to cause confusion. Perhaps e.g. bundled with examples or similar[1]. > I would think that anyone who doesn't care enough to configure the > logging at all might reasonably expect not to be too surprised to > find there are none, if they ever even looked at the logs. I think it can be frustrating for people trying to get familiar with the project to debug simple problems with packaged examples or tools if there is no logging available. Not everyone who ends up trying to get something working with the JMS client has experience with sl4j. Having to dig around on information on what to download, where to install it and then what format of file needs to be created is significantly harder than e.g. the python or c++ clients. Making that easier is in my view quite reasonable. Having at least warning level messages be visible is also a help. --Gordon [1] I always feel like there something missing on the java side when testing releases - no test app or examples to run. >>> >>> >>> We do actually have examples, but we don't currently ship them in the >>> standalone client bundle and they just get lost in the noise of the full >>> bundle, since the lib dir has such a vast number and mix of jars and it also >>> isn't that clear how to run/use them. I like Martin's suggestion for >>> shipping them as a side dir in the client bundle, and from there we could >>> make it clear how to leverage one or two of them as a specific test or first >>> time user example. >>> >>> I agree that having logging available easily is a good thing and is >>> obviously very useful for new people to the project to debug things. I just >>> don't think we should provide something that self configures the logging by >>> default, and don't think it is unreasonable to expect a user who wants >>> loggin
[jira] Created: (QPID-2595) WCF programming guide documentation
WCF programming guide documentation --- Key: QPID-2595 URL: https://issues.apache.org/jira/browse/QPID-2595 Project: Qpid Issue Type: Improvement Components: Documentation Affects Versions: 0.7 Reporter: Cliff Jansen Fix For: 0.7 WCF/C++ client programming documentation -- 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: Want to Help - qpid newbie
I was looking at the ACL/SeLinux integration tasks, could someone suggest if this would be an ideal starting task. I will be able to spend sometime preferably on weekends. Any directions on where to start or documentation would really be helpful. Hello Subramanian, I started down the SELinux road last year and uploaded a preliminary plan on JIRA - see https://issues.apache.org/jira/browse/QPID-1838 . How much do you know about implementing user object managers in SELinux? Cheers, -Josh -- - http://www.globalherald.net/jb01 GlobalHerald.NET, the Smarter Social Network! (tm) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866188#action_12866188 ] Carl Trieloff commented on QPID-2539: - I think the thread can be summed as follows: - The acl v2 mechinism can most likely handle all if not all the cases, (maybe a few minor things are missing). - From the Java side, they have a few defined (groups/roles) with specific predefined permissions. I think the debate will come down to -- should we include a set of 'qpid-defined' named roles with permissions set. The approach on the C++ side has been to allow the user to create what he needs. But having a few predefined groups (even if just shipped in the default acl file) that may be meaningful. Carl. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866184#action_12866184 ] Andrew Kennedy commented on QPID-2539: -- acl allow admin admin log # allow JMX/QMF log level administration This means that the log4j logger's level is able to be changed from, e.g. INFO to DEBUG, or a new logging configuration file can be loaded, I don't believe it is equivalent to: acl allow admin access all Also, you use METHOD as both an object and an operation - it isn't clear what the difference between, say, access method and update method would be? acl allow admin method all # should there be an update or an access before the method? acl allow admin update method reloadACLFile Would these not be clearer as: acl allow admin access method name=* # access to all methods acl allow admin access method name=reloadACLFile # access to a single method or even: acl allow admin manage broker method=* acl allow admin manage broker method=reloadACLFile I will update the document I'm writing with the results of this discussion and post a link. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866182#action_12866182 ] Rajith Attapattu commented on QPID-2539: I see that Carl had already put up an example. Andrew could you also put up a wiki page with your proposals and use examples. You could then post the link in the description section. That will help a lot to avoid going back and forth to clarify certain points. Also it will help folks who will join the discussion mid way through. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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
Want to Help - qpid newbie
All, Iam a qpid newbie and Iam hoping to contribute to the development on the C++/Java side mostly on Linux. I was looking at the ACL/SeLinux integration tasks, could someone suggest if this would be an ideal starting task. I will be able to spend sometime preferably on weekends. Any directions on where to start or documentation would really be helpful. I have experience in contributing to projects in sourceforge. Thanks. Kanthi. _ Win $10,000 from Hotmail! Enter Here. http://go.microsoft.com/?linkid=9729708
Re: [Java] The use of setLinkedException in JMSException is not a good idea
Le 11/05/2010 15:44, Rajith Attapattu a écrit : I am slammed atm, so a patch would be very much appreciated ! Here it is: https://issues.apache.org/jira/browse/QPID-2594 https://issues.apache.org/jira/secure/attachment/12444205/initcause.patch Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (QPID-2594) Exception chaining for JMSExceptions
[ https://issues.apache.org/jira/browse/QPID-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg updated QPID-2594: - Attachment: initcause.patch > Exception chaining for JMSExceptions > > > Key: QPID-2594 > URL: https://issues.apache.org/jira/browse/QPID-2594 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Affects Versions: 0.6 >Reporter: Emmanuel Bourg >Priority: Minor > Fix For: 0.7 > > Attachments: initcause.patch > > > JMSException has an archaic mechanism to chain the root cause by calling the > setLinkedException() method. It predates the introduction of the > Throwable.initCause() method in Java 1.4 which standardized the exception > chaining. > Currently when Qpid creates a JMSException the initCause() method isn't > always called. This results in difficult to interpret stacktraces which are > missing the root cause. > The right behavior would be to call both methods, setLinkedException and > initCause, to maintain the backward compatibility with code looking at the > linked exception and to display the full exception chain when the exception > is printed. -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866177#action_12866177 ] Carl Trieloff commented on QPID-2539: - RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc.. However I am wondering how much of config is going to overlap with QMF. On C++ side is is done like this: Then the normal ACL action perissions are applied to the method, allowing you to set permissions of who may reload the ACL's. Reason it is 'METHOD' is that it ACL's applied to QMF methods --> I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this: ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration <-- For example group admin (..) acl allow admin method all # allow admin group access to all QMF / JMX methods. acl allow admin access all # equivalent of your LOG level statement. acl allow admin update method reloadACLFile # allow admin group to update acl file. I believe they are all covered already. Carl. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866171#action_12866171 ] Andrew Kennedy commented on QPID-2539: -- I couldn't find any documentation of the METHOD object, and it is not listed on the ACL web page. Could someone list the way this is currently used, and give some example ACL lines to illustrate? Cheers, Andrew. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866170#action_12866170 ] Andrew Kennedy commented on QPID-2539: -- RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc.. However I am wondering how much of config is going to overlap with QMF. For example the C++ broker is using QMF to reload the ACL file. So reloading of the ACL file is actually protected under the "METHOD" object. As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name :) Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ? LOG allows changing the log4j levels and USER grants the ability to add/delete users. RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc.. But I am also not really opposed to having a top level LOG object either. I'd be interested to hear opinions from a wider audience as well. ADK: FYI, there is no ACL object, that may have been a typo. I don't have any preference between ADMIN or MANGE, but I prefer both of those to METHOD. Also, to me this is an operation and the object types I suggested would then allow ACL lines like this: ACL ALLOW admin ADMIN BROKER # allow JMX/QMF access to read-only management attributes on the broker ACL ALLOW admin ADMIN CONFIG # allow JMX/QMF administration of configuration file reloading ACL ALLOW admin ADMIN LOG # allow JMX/QMF log level administration ACL ALLOW admin ADMIN USER # allow JMX/QMF user administration > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866166#action_12866166 ] Carl Trieloff edited comment on QPID-2539 at 5/11/10 10:49 AM: --- Is ADMIN not just a group of users with a specifc set of permissions assigned? Is CONNECT not just allow access virtualhost ? I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call. " LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not a broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff. Then all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions. Carl. was (Author: cctrieloff): Is ADMIN not just a group of users with a specifc set of permissions assigned? Is CONNECT not just allow access virtualhost ? I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call. " LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not an broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff. The all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions. Carl. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866166#action_12866166 ] Carl Trieloff commented on QPID-2539: - Is ADMIN not just a group of users with a specifc set of permissions assigned? Is CONNECT not just allow access virtualhost ? I think LOG is already covered with METHOD, maybe we should walk through an example for JMX admin and QMF Admin and see if it covers all the cases that are being thought about. If not we should add those to the METHOD call. " LOG allows changing the log4j levels and USER grants the ability to add/delete users. " Is use not an broker tangental concept. I know Java broker supports a user create call. In my view with QMF, this should be modeled with a QMF user schema and then if that object is supplied by the broker or something external it makes no diff. The all the permissions can be applied to all the methods on that schema using the METHOD object. This would keep things 100% consistent. i.e. controlling setting log level, adding users etc all sound like METHOD permissions. Carl. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866165#action_12866165 ] Andrew Kennedy commented on QPID-2539: -- 1. What is the purpose of CONNECT ? ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation. RA: In that case why not use "ACCESS" which is already there ? ADK: I just checked, and it turns out I am using ACCESS, exactly as you say. I have removed CONNECT now. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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] Created: (QPID-2594) Exception chaining for JMSExceptions
Exception chaining for JMSExceptions Key: QPID-2594 URL: https://issues.apache.org/jira/browse/QPID-2594 Project: Qpid Issue Type: Improvement Components: Java Broker, Java Client, Java Common Affects Versions: 0.6 Reporter: Emmanuel Bourg Priority: Minor Fix For: 0.7 JMSException has an archaic mechanism to chain the root cause by calling the setLinkedException() method. It predates the introduction of the Throwable.initCause() method in Java 1.4 which standardized the exception chaining. Currently when Qpid creates a JMSException the initCause() method isn't always called. This results in difficult to interpret stacktraces which are missing the root cause. The right behavior would be to call both methods, setLinkedException and initCause, to maintain the backward compatibility with code looking at the linked exception and to display the full exception chain when the exception is printed. -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866162#action_12866162 ] Rajith Attapattu commented on QPID-2539: 1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game? I am not opposed to having a virtual host object in the ACL file as the Java broker is using that. The c++ broker can easily ignore it. My question was more about whether it's really worth spending effort on something that we know want be there for long. If you have customer requests for protecting virtual hosts with ACL then it is fine (All though I think this is redundant as the objects within a virtual host is covered anyways). But if there is no interest from the users, then I'd say don't bother. ADK: This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely. RA: Good question, Aidan and I had discussed on the qpid dev list about using ACL to validate the IP addresses instead of maintaining a separate firewall plugin. The C++ broker does have an outstanding JIRA for something similar to the firewall plugin which we hope to implement using ACL. We were planning to have that as an optional feature to ensure backwards compatibility. So if you want ACL to restrict IP address you need to explicitly enable it in the ACL module. The config option (Not the CONFIG object) you talked about is going to be handy here. I am bit swamped these days, hopefully when I get some free time, I will try to put my thoughts into a wiki page to capture the requirements and share some ideas with you. Perhaps then we can open some more concrete JIRA's to focus on those individual areas. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866158#action_12866158 ] Rajith Attapattu commented on QPID-2539: 1. What is the purpose of CONNECT ? ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation. RA: In that case why not use "ACCESS" which is already there ? 2. What is the purpose of ADMIN ? 2. What is the purpose of LOG, CONFIG and ACL ? I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind. 3. Also how is LOG different from "allow-log" and "deny-log" in the current format ? ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created. RA: We already have a BROKER object. And we already have "METHOD" for QMF, which I think nicely covers JMX as well. If you need to query a queue name, then that is protected by the QUEUE object. In ACL, each object defines it's own access control list. So I didn't really understand the role of the "ACL" object. in the context you described. Besides ACL module does not add/modify users. That is the responsibility of the authentication mechanism defined using SASL. So not sure what the "USER" object is supposed to do. CONFIG grants permission to reload the security config, or edit ACL lines, RA: We need to have a mechanism to allow reloading of config files. This may include the ACL file, security config, log config etc.. However I am wondering how much of config is going to overlap with QMF. For example the C++ broker is using QMF to reload the ACL file. So reloading of the ACL file is actually protected under the "METHOD" object. As I mentioned before, METHOD can cover both QMF and JMX. However I really dislike the name :) Perhaps we can have a meaningful name here. Maybe ADMIN (or MGT) instead of METHOD ? LOG allows changing the log4j levels and USER grants the ability to add/delete users. RA: Instead of using a separate top level object can we not have this under the purview of the MGT or ADMIN (previously METHOD) object and the properties to define the file name, log level etc.. But I am also not really opposed to having a top level LOG object either. I'd be interested to hear opinions from a wider audience as well. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866149#action_12866149 ] Rajith Attapattu commented on QPID-2539: RA: Is this to improve readability? I am not sure what exactly the benefit here? ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention. RA: I am totally fine with the whitespace, my comment was more about continuations. Sorry for not making that clear. Could you perhaps provide an example of what is allowed and not allowed with the proposed changes for continuations ? > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866147#action_12866147 ] Rajith Attapattu commented on QPID-2539: ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired ;) and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas. RA: I think we should really stop thinking in terms of a java format or c++ format. We need to focus on agreeing on a common format. Once we decide and agree on a format both brokers **should** be able to parse the file format. However each broker could ignore items that it doesn't support. Also when we document, we need to ensure that we position this as the "Qpid ACL format". Then we can go onto mention the exceptions where each broker may ignore certain entries. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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] The use of setLinkedException in JMSException is not a good idea
Emmanuel, I am slammed atm, so a patch would be very much appreciated ! Rajith On Mon, May 10, 2010 at 4:33 PM, Emmanuel Bourg wrote: > Le 23/03/2010 13:57, Rajith Attapattu a écrit : >> >> Thanks for the input. >> I will create a JIRA and take care of this. > > This change would be much welcome. I didn't find the JIRA report, if you > want I can provide a patch addressing this issue. > > Emmanuel Bourg > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-2593) Broker shutdown process does not wait for Connection Closure
Broker shutdown process does not wait for Connection Closure Key: QPID-2593 URL: https://issues.apache.org/jira/browse/QPID-2593 Project: Qpid Issue Type: Bug Affects Versions: 0.6 Reporter: Martin Ritchie Currently during broker shutdown the virtualhost closes all registered connections. However, it doesn't sensibly wait for these connections to have been closed. A) It keeps sending a close frame until it is removed from the _registry. (It should only send it once) B) When the connection is closing it immediately removes its connection from the _registry before it has finished its processing. So two things to fix. 1) Vhost close should send 1 close frame per connection and then wait for them to close 2) The connection should not be removed from the _registry until it is no longer active. -- 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] The use of setLinkedException in JMSException is not a good idea
Le 11/05/2010 12:48, Andrew Kennedy a écrit : Don't we need to use setLinkedException, since it's the JMS specification required mechanism. If you wanted to add an initCause, that would be in addition to this, since some JMS clients would expect the setLinkedException to be set? Yes, that's what Aidan and Robert proposed. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: [Java] The use of setLinkedException in JMSException is not a good idea
On 10 May 2010 21:33, Emmanuel Bourg wrote: > Le 23/03/2010 13:57, Rajith Attapattu a écrit : >> >> Thanks for the input. >> I will create a JIRA and take care of this. > > This change would be much welcome. I didn't find the JIRA report, if you > want I can provide a patch addressing this issue. > > Emmanuel Bourg Don't we need to use setLinkedException, since it's the JMS specification required mechanism. If you wanted to add an initCause, that would be in addition to this, since some JMS clients would expect the setLinkedException to be set? 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] Commented: (QPID-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866127#action_12866127 ] Andrew Kennedy commented on QPID-2539: -- 1. I can see the value of virtual host for the current setup, but going forward do we have virtual hosts in AMQP 1.0 ? So it worth it doing so late in the game? This is required for the Firewall plugin. Whether the Firewall plugin is required is another question entirely. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866126#action_12866126 ] Andrew Kennedy commented on QPID-2539: -- 1. What is the purpose of CONNECT ? ADK: An ACL that allows access to a virtual host, but no more. Only CONNECT VIRTUALHOST makes sense for this operation. 2. What is the purpose of ADMIN ? 2. What is the purpose of LOG, CONFIG and ACL ? I think CONFIG is probably a good addition, but I'd like to understand what exactly you had in mind. 3. Also how is LOG different from "allow-log" and "deny-log" in the current format ? ADK: An ACL that allows JMX (or QMF) administration to take place, where the object being administered is either the BROKER (i.e. to retrieve queue names, statistics, read-only attributes and so on) or CONFIG, LOG or USER. These three are only modifiable using the admin interface, wheras the other ACL entries apply (like CREATE QUEUE) no matter how the queue is created. CONFIG grants permission to reload the security config, or edit ACL lines, LOG allows changing the log4j levels and USER grants the ability to add/delete users. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866125#action_12866125 ] Andrew Kennedy commented on QPID-2539: -- RA: 1. I don't think we should deprecate the "group" declarations. I think it's a very convenient feature and is currently used by several customers that in production. 2. I am not opposed to having a pluggable external mechanism for configuring groups. However I am still not clear as to how these groups are tied to the authentication system. Bear in mind that the users in ACL are authenticated via our authentication mechanism. So any external mechanism used for the groups needs to be used in authentication as well. Could you pls clarify this point? ADK: This is to allow other mechanisms, primarily directory services but also stand-alone group files, such as the unix /etc/group file. I have no problem keepin the ability to include groups in the ACL file, I would just like to have the ability to override this facility and use an external, pluggable mechanism. In many cases this will be separate from the authentication mechanism by their very nature - unix passwd and group is an obvious example, as is .htaccess and tomcat groups. We should continue discussion at QPID-2541 though. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866124#action_12866124 ] Andrew Kennedy commented on QPID-2539: -- RA: Is this to improve readability? I am not sure what exactly the benefit here? ADK: The whitespace and continuation definitions are to both improve readability and to make parsing simpler. I could easily restict whitespace back to the old set, but see no problem with extending it as longas it is well defined. As for continuation lines, if they are supported in one place, why not just support them everywhere, rather than the confusing (perhaps) rules about where exactly they can be placed. Every language that allows continuation characters for line breaking simply allows them anywhere and joins the two lines, ignoring the continuation character, I just wanted to follow the existing convention. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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-2539) Update ACL file syntax to be clearer and add extra operations
[ https://issues.apache.org/jira/browse/QPID-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866122#action_12866122 ] Andrew Kennedy commented on QPID-2539: -- 1. I'd like to emphasize again that there should not be a separate c++ and java ACL file formats. We should have one and only one ACL file format for Qpid brokers. If we agree to make changes, then both brokers would need to support it. There are users who are already trying to use both C++ and Java brokers (using federation) in production. Having a single file format makes life very easy here. 2. Qpid as project is aiming to provide a consistent experience across all brokers and clients. This is a vision and a goal of this project. Individual features should be developed with this in mind. 3. IMO having a strict format is better, as it is simple and less ambiguous, resulting in far less errors. Also rigid format is better for a security related to system to prevent people from exploiting the lenient nature of the format to exploit any gaps. ADK: I agree. The 'less strict' phrasing was not the best choice of words. The file format I'm proposing still has no ambiguity, and can be defined with a strict EBNF grammar (if so desired ;) and is simply an extension of the C++ format, i.e. any valid C++ broker ACL file is also a valid Java broker ACL file. The opposite is not true, since at the moment there are features (virtualhosts) that are not available in the C++ broker. Actually, this can be dealt with the same way the java broker deals with currently un-implemented features (routes, links) by ignoring those ACL stanzas. > Update ACL file syntax to be clearer and add extra operations > - > > Key: QPID-2539 > URL: https://issues.apache.org/jira/browse/QPID-2539 > Project: Qpid > Issue Type: Sub-task > Components: Java Broker >Reporter: Andrew Kennedy > Fix For: 0.7 > > -- 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
