[jira] [Commented] (QPID-4001) Add a java version of the Qpid API
[ https://issues.apache.org/jira/browse/QPID-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277561#comment-13277561 ] jirapos...@reviews.apache.org commented on QPID-4001: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5151/ --- (Updated 2012-05-17 04:34:35.003307) Review request for qpid, Robbie Gemmell, Weston Price, Rafael Schloming, and Rob Godfrey. Summary (updated) --- As mentioned in the JIRA (and based on offline discussions I had with some folks) it would be good if we can settle down on a set of interfaces for the java version of the Qpid API. The JMS layer could then be built on top of this, without having to wait until the api implementation is complete. Implementation possibilities include, 1. A java implementation of this API 2. This acting as a wrapper for the python (via jython) or c++ client I wonder if we could do something more clever with the Message interface using generics to denote the type of content. I certainly appreciate feedback and comments :) TODO Exception heirachy. This addresses bug QPID-4001. https://issues.apache.org/jira/browse/QPID-4001 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.deps 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.xml 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/build.xml PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Connection.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Message.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Receiver.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Sender.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Session.java PRE-CREATION Diff: https://reviews.apache.org/r/5151/diff Testing --- Thanks, rajith > Add a java version of the Qpid API > -- > > Key: QPID-4001 > URL: https://issues.apache.org/jira/browse/QPID-4001 > Project: Qpid > Issue Type: New Feature > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.17 > > > Both C++ and Python have a common API that is commonly referred to as the > "Qpid API". There have been numerous requests to add one for Java. > The consensus we have so far for the upcomming new client is to have the > following layering where the Qpid API is a major component. > proton-j --> Qpid API --> JMS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request: QPID-4001 Interfaces for QPID API
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5151/ --- (Updated 2012-05-17 04:34:35.003307) Review request for qpid, Robbie Gemmell, Weston Price, Rafael Schloming, and Rob Godfrey. Summary (updated) --- As mentioned in the JIRA (and based on offline discussions I had with some folks) it would be good if we can settle down on a set of interfaces for the java version of the Qpid API. The JMS layer could then be built on top of this, without having to wait until the api implementation is complete. Implementation possibilities include, 1. A java implementation of this API 2. This acting as a wrapper for the python (via jython) or c++ client I wonder if we could do something more clever with the Message interface using generics to denote the type of content. I certainly appreciate feedback and comments :) TODO Exception heirachy. This addresses bug QPID-4001. https://issues.apache.org/jira/browse/QPID-4001 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.deps 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.xml 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/build.xml PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Connection.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Message.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Receiver.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Sender.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Session.java PRE-CREATION Diff: https://reviews.apache.org/r/5151/diff Testing --- Thanks, rajith
[jira] [Commented] (QPID-4005) Eliminate "using" especially "using namespace" from header file
[
https://issues.apache.org/jira/browse/QPID-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277207#comment-13277207
]
Andrew Stitcher commented on QPID-4005:
---
There is really a hierarchy of badness here:
Worst:
"using namespace" In the global scope of a header file - This pollutes the
namespace of any using source file.
"using " In the global scope of a header file - This may cause
some unexpected symbol resolution which will be affected by which header files
are included - tricky to diagnose if it happens.
These previous are especially bad if they are in exported headers because they
affect programs which merely use a qpid library.
Bad:
"
namespace qpid { ... using ...;
"
This can still cause the above problems and confusions to qpid developers but
at least have little to no chance of confusing library users.
Probably not actually harmful:
Using "using ... " inside a block scope generated by a macro in a header file.
Questionable from a taste point of view, but can't pollute anyone elses
namespace.
> Eliminate "using" especially "using namespace" from header file
> ---
>
> Key: QPID-4005
> URL: https://issues.apache.org/jira/browse/QPID-4005
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Broker, C++ Client
>Reporter: Andrew Stitcher
>Priority: Minor
>
> The using declaration is generally unsuitable for use in header files as it
> affects the namespace of any file including that header file.
> This can make the C++ build unstable under code maintenance.
> We should remove using and using namespace from header files and replace it
> where necessary in the C++ source files that previously relied on the
> declaration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Re: JBoss 5.1 to 6.1 Migration Problem...
For clarification, I should not have said EAP, that should simply read JBoss 5
and JBoss 6 where appropriate.
Regards,
Weston
On May 16, 2012, at 4:47 PM, Weston M. Price wrote:
> Hi Dan,
> It looks like your trying to mix JMS providers. The stacktrace is
> telling you that you are attempting to use the HornetQ activation spec for
> your MDB. HornetQ is the default JMS provider for EAP and as such, if you
> don't tell EAP you want to use another messaging provider then it assumes the
> default. I assume you are trying to use Qpid. So, you have two choices to
> define the ResourceAdapter you need to use. You can either use the EAP
> specific annotation
>
> org.jboss.ejb3.annotation.ResourceAdapter
>
> This annotation can usually be found in the jboss-ejb3-ext-api-impl.jar which
> is generally in the JBOSS_HOME/client directory. This is class level
> annotation, so simply put this at the top of your MDB as such:
>
> @ResourceAdapter("qpid-ra-.rar")
>
> where corresponds to your version of the Qpid JCA rar file you are
> using.
>
>
> If you don't want to use the annotation, you can use the jboss.xml deployment
> descriptor mechanism. In your ejb-jar/META-INF directory, if you don't
> already have one, create the jboss.xml file. it should look something like:
>
> xmlns="http://www.jboss.com/xml/ns/javaee";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee
>http://www.jboss.org/j2ee/schema/jboss_5_0.xsd";
>version="3.0">
>
>
>
> ResourceConfigListenerMDB
> qpid-ra-.rar
>
>
>
>
> There were very few infrastructure changes between EAP 5 and EAP 6 so looking
> at your problem, one of three things may have happened:
>
> 1) The annotation mentioned above may have been removed
> 2) The descriptor mentioned above may have been removed
> 3) The original EAP 5.x environment replaced HornetQ with Qpid as the default
> JMS provider. If this is the case, then you will have to migrate this
> configuration over the EAP 6. This may have already been done for you before,
> so you will have to find out if this is indeed the case, and just replace
> HornetQ with Qpid on the new instance.
>
>
> Note, if it is actually #3, I highly recommend using approach #1 or #2.
> Either way will avoid a lot of work on your part and is much easier to
> migrate if you have to do this again.
>
> Regards,
>
> Weston
>
> On May 16, 2012, at 4:30 PM, Dan Carda wrote:
>
>>
>> Hi there!
>> I'm currently in the middle of a JBoss 5.1 to 6.1 migration and it's not
>> going well. I know the problem was caused by ME, but I'm hopeful someone
>> will go, "oh yeah, you need to do ".
>>
>> Currently, I'm using the 0.10 version. This version worked fine under JBoss
>> 5.1. So well in fact this location standardized on it.
>>
>> The message I'm getting from JBoss is:
>>
>> 14:21:40,977 INFO [org.jboss.ejb3.EJBContainer] STARTED EJB:
>> com.twtelecom.esbc.sip.mdb3.qpid.resourceconfig.ResourceConfigListenerMDB
>> ejbName: ResourceConfigListenerMDB
>> 14:21:41,005 ERROR
>> [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
>> installing to Start:
>> name=jboss.j2ee:ear=sip_application-ear-1.0-SNAPSHOT.ear,jar=sip_application-ejb-1.0-SNAPSHOT.jar,name=ResourceConfigListenerMDB,service=EJB3
>> state=Create: org.jboss.deployers.spi.DeploymentException: Error for
>> ActivationSpec class org.hornetq.ra.inflow.HornetQActivationSpec as JavaBean
>> Caused by: java.beans.IntrospectionException: No property found for:
>> connectionURL on JavaBean:
>> org.hornetq.ra.inflow.HornetQActivationSpec(ra=null
>> destination=jms/QpidNowTopic destinationType=javax.jms.Topic
>> selector=SipMessageType = 'ResourceConfigMsg' ack=Auto-acknowledge
>> durable=false clientID=null user=null maxSession=1)
>>
>> In my EJB, this I define this:
>>
>> @MessageDriven ( activationConfig = { @ActivationConfigProperty (
>> propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge" ) ,
>> @ActivationConfigProperty ( propertyName = "connectionURL", propertyValue =
>> "amqp://guest:guest@clientid/test?brokerlist='tcp://mrgdalprdn4:5672'" ) ,
>> @ActivationConfigProperty ( propertyName = "destination", propertyValue =
>> "jms/QpidNowTopic" ) , @ActivationConfigProperty ( propertyName =
>> "destinationType", propertyValue = "javax.jms.Topic" ) ,
>> @ActivationConfigProperty ( propertyName = "maxSession", propertyValue = "1"
>> ) , @ActivationConfigProperty ( propertyName = "messageSelector",
>> propertyValue = "SipMessageType = 'ResourceConfigMsg'" ) ,
>> @ActivationConfigProperty ( propertyName = "useLocalTx", propertyValue =
>> "false" ) } ) @TransactionAttribute( TransactionAttributeType.NOT_SUPPORTED
>> ) public class SystemConfigListenerMDB extends ResourceConfigLogic
>> implements MessageListener{
>>
>> Any idea what I'm doing wrong???
>>
>> Tha
[jira] [Created] (QPID-4005) Eliminate "using" especially "using namespace" from header file
Andrew Stitcher created QPID-4005: - Summary: Eliminate "using" especially "using namespace" from header file Key: QPID-4005 URL: https://issues.apache.org/jira/browse/QPID-4005 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Reporter: Andrew Stitcher Priority: Minor The using declaration is generally unsuitable for use in header files as it affects the namespace of any file including that header file. This can make the C++ build unstable under code maintenance. We should remove using and using namespace from header files and replace it where necessary in the C++ source files that previously relied on the declaration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4004) Cruft in qpid::framing::Buffer class should be removed
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved QPID-4004. --- Resolution: Fixed Fix Version/s: 0.17 > Cruft in qpid::framing::Buffer class should be removed > -- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > Fix For: 0.17 > > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: JBoss 5.1 to 6.1 Migration Problem...
Hi Dan,
It looks like your trying to mix JMS providers. The stacktrace is
telling you that you are attempting to use the HornetQ activation spec for your
MDB. HornetQ is the default JMS provider for EAP and as such, if you don't tell
EAP you want to use another messaging provider then it assumes the default. I
assume you are trying to use Qpid. So, you have two choices to define the
ResourceAdapter you need to use. You can either use the EAP specific annotation
org.jboss.ejb3.annotation.ResourceAdapter
This annotation can usually be found in the jboss-ejb3-ext-api-impl.jar which
is generally in the JBOSS_HOME/client directory. This is class level
annotation, so simply put this at the top of your MDB as such:
@ResourceAdapter("qpid-ra-.rar")
where corresponds to your version of the Qpid JCA rar file you are
using.
If you don't want to use the annotation, you can use the jboss.xml deployment
descriptor mechanism. In your ejb-jar/META-INF directory, if you don't already
have one, create the jboss.xml file. it should look something like:
http://www.jboss.com/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee
http://www.jboss.org/j2ee/schema/jboss_5_0.xsd";
version="3.0">
ResourceConfigListenerMDB
qpid-ra-.rar
There were very few infrastructure changes between EAP 5 and EAP 6 so looking
at your problem, one of three things may have happened:
1) The annotation mentioned above may have been removed
2) The descriptor mentioned above may have been removed
3) The original EAP 5.x environment replaced HornetQ with Qpid as the default
JMS provider. If this is the case, then you will have to migrate this
configuration over the EAP 6. This may have already been done for you before,
so you will have to find out if this is indeed the case, and just replace
HornetQ with Qpid on the new instance.
Note, if it is actually #3, I highly recommend using approach #1 or #2. Either
way will avoid a lot of work on your part and is much easier to migrate if you
have to do this again.
Regards,
Weston
On May 16, 2012, at 4:30 PM, Dan Carda wrote:
>
> Hi there!
> I'm currently in the middle of a JBoss 5.1 to 6.1 migration and it's not
> going well. I know the problem was caused by ME, but I'm hopeful someone
> will go, "oh yeah, you need to do ".
>
> Currently, I'm using the 0.10 version. This version worked fine under JBoss
> 5.1. So well in fact this location standardized on it.
>
> The message I'm getting from JBoss is:
>
> 14:21:40,977 INFO [org.jboss.ejb3.EJBContainer] STARTED EJB:
> com.twtelecom.esbc.sip.mdb3.qpid.resourceconfig.ResourceConfigListenerMDB
> ejbName: ResourceConfigListenerMDB
> 14:21:41,005 ERROR
> [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
> installing to Start:
> name=jboss.j2ee:ear=sip_application-ear-1.0-SNAPSHOT.ear,jar=sip_application-ejb-1.0-SNAPSHOT.jar,name=ResourceConfigListenerMDB,service=EJB3
> state=Create: org.jboss.deployers.spi.DeploymentException: Error for
> ActivationSpec class org.hornetq.ra.inflow.HornetQActivationSpec as JavaBean
> Caused by: java.beans.IntrospectionException: No property found for:
> connectionURL on JavaBean:
> org.hornetq.ra.inflow.HornetQActivationSpec(ra=null
> destination=jms/QpidNowTopic destinationType=javax.jms.Topic
> selector=SipMessageType = 'ResourceConfigMsg' ack=Auto-acknowledge
> durable=false clientID=null user=null maxSession=1)
>
> In my EJB, this I define this:
>
> @MessageDriven ( activationConfig = { @ActivationConfigProperty (
> propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge" ) ,
> @ActivationConfigProperty ( propertyName = "connectionURL", propertyValue =
> "amqp://guest:guest@clientid/test?brokerlist='tcp://mrgdalprdn4:5672'" ) ,
> @ActivationConfigProperty ( propertyName = "destination", propertyValue =
> "jms/QpidNowTopic" ) , @ActivationConfigProperty ( propertyName =
> "destinationType", propertyValue = "javax.jms.Topic" ) ,
> @ActivationConfigProperty ( propertyName = "maxSession", propertyValue = "1"
> ) , @ActivationConfigProperty ( propertyName = "messageSelector",
> propertyValue = "SipMessageType = 'ResourceConfigMsg'" ) ,
> @ActivationConfigProperty ( propertyName = "useLocalTx", propertyValue =
> "false" ) } ) @TransactionAttribute( TransactionAttributeType.NOT_SUPPORTED
> ) public class SystemConfigListenerMDB extends ResourceConfigLogic
> implements MessageListener{
>
> Any idea what I'm doing wrong???
>
> Thanks!
> Daniel Carda
> Time Warner Telecom
>
>
>
>
> --
> View this message in context:
> http://old.nabble.com/JBoss-5.1-to-6.1-Migration-Problem...-tp33860736p33860736.html
> Sent from the Qpid Developers mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: dev
[jira] [Updated] (QPID-4004) Cruft in qpid::framing::Buffer class should be removed
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-4004: -- Summary: Cruft in qpid::framing::Buffer class should be removed (was: qpid::framing::Buffer::Iterator not very useful) > Cruft in qpid::framing::Buffer class should be removed > -- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
JBoss 5.1 to 6.1 Migration Problem...
Hi there!
I'm currently in the middle of a JBoss 5.1 to 6.1 migration and it's not
going well. I know the problem was caused by ME, but I'm hopeful someone
will go, "oh yeah, you need to do ".
Currently, I'm using the 0.10 version. This version worked fine under JBoss
5.1. So well in fact this location standardized on it.
The message I'm getting from JBoss is:
14:21:40,977 INFO [org.jboss.ejb3.EJBContainer] STARTED EJB:
com.twtelecom.esbc.sip.mdb3.qpid.resourceconfig.ResourceConfigListenerMDB
ejbName: ResourceConfigListenerMDB
14:21:41,005 ERROR
[org.jboss.kernel.plugins.dependency.AbstractKernelController] Error
installing to Start:
name=jboss.j2ee:ear=sip_application-ear-1.0-SNAPSHOT.ear,jar=sip_application-ejb-1.0-SNAPSHOT.jar,name=ResourceConfigListenerMDB,service=EJB3
state=Create: org.jboss.deployers.spi.DeploymentException: Error for
ActivationSpec class org.hornetq.ra.inflow.HornetQActivationSpec as JavaBean
Caused by: java.beans.IntrospectionException: No property found for:
connectionURL on JavaBean:
org.hornetq.ra.inflow.HornetQActivationSpec(ra=null
destination=jms/QpidNowTopic destinationType=javax.jms.Topic
selector=SipMessageType = 'ResourceConfigMsg' ack=Auto-acknowledge
durable=false clientID=null user=null maxSession=1)
In my EJB, this I define this:
@MessageDriven ( activationConfig = { @ActivationConfigProperty (
propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge" ) ,
@ActivationConfigProperty ( propertyName = "connectionURL", propertyValue =
"amqp://guest:guest@clientid/test?brokerlist='tcp://mrgdalprdn4:5672'" ) ,
@ActivationConfigProperty ( propertyName = "destination", propertyValue =
"jms/QpidNowTopic" ) , @ActivationConfigProperty ( propertyName =
"destinationType", propertyValue = "javax.jms.Topic" ) ,
@ActivationConfigProperty ( propertyName = "maxSession", propertyValue = "1"
) , @ActivationConfigProperty ( propertyName = "messageSelector",
propertyValue = "SipMessageType = 'ResourceConfigMsg'" ) ,
@ActivationConfigProperty ( propertyName = "useLocalTx", propertyValue =
"false" ) } ) @TransactionAttribute( TransactionAttributeType.NOT_SUPPORTED
) public class SystemConfigListenerMDB extends ResourceConfigLogic
implements MessageListener{
Any idea what I'm doing wrong???
Thanks!
Daniel Carda
Time Warner Telecom
--
View this message in context:
http://old.nabble.com/JBoss-5.1-to-6.1-Migration-Problem...-tp33860736p33860736.html
Sent from the Qpid Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4004) qpid::framing::Buffer::Iterator not very useful
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277073#comment-13277073 ] Andrew Stitcher commented on QPID-4004: --- There are a few bits of cruft in the Buffer class and interface: * This iterator which actually isn't used by any current code * record() and restore() member functions which are aren't really safe to use. [The Buffer class doesn't keep a stack of recorded locations, so you can't perform any function calls that might themselves do record()/restore()] This makes it hard to reason about locally, and hard to ensure globally. > qpid::framing::Buffer::Iterator not very useful > --- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3401) Refactor address resolution code
[ https://issues.apache.org/jira/browse/QPID-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277049#comment-13277049 ] jirapos...@reviews.apache.org commented on QPID-3401: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4658/#review7940 --- Just an update on the status. I have already made the changes suggested here. In addition I have also made further changes based on more comments received by Rob Godfrey. The only missing piece (a critical one at that) is the testing. I'm planning to add the unit tests soon. - rajith On 2012-04-05 15:03:30, rajith attapattu wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/4658/ bq. --- bq. bq. (Updated 2012-04-05 15:03:30) bq. bq. bq. Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, Rafael Schloming, and Rob Godfrey. bq. bq. bq. Summary bq. --- bq. bq. The following patch is based on the various discussions we've had on the dev list about restructing our destination implementation. bq. As the first phase this patch only includes the new class heirachy. For the second phase we will tackle the integration into the code base. bq. bq. A summary of the desgin is as follows, bq. bq. 1. Once initialized with the destination string, the destination objects are immutable. bq. 2. There are 2 concrete implementations in the form of QpidTopic and QpidQueue. bq. 3. Destinations will be desginated as "Queues" and "Topics" by the users in the jndi file. This prevents us from having to automagically decide the type. bq. 4. Both BURL and Address strings are parsed and adapted into a common data structure. Internally the code will work with this data structure. bq. 5. The Destination impl does not depend on any other classes, thus allowing it be used with the current code or the new client. bq. bq. (There are 2 oe 3 white space errors that I can't seem to get rid of. It seems they are comming from the diff process). bq. bq. bq. This addresses bug QPID-3401. bq. https://issues.apache.org/jira/browse/QPID-3401 bq. bq. bq. Diffs bq. - bq. bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/DestinationStringParser.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidQueue.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryQueue.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTopic.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/TemporaryDestinationProvider.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/Address.java 1309769 bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/AddressException.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Link.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Node.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/util/AddressHelper.java PRE-CREATION bq. bq. Diff: https://reviews.apache.org/r/4658/diff bq. bq. bq. Testing bq. --- bq. bq. bq. Thanks, bq. bq. rajith bq. bq. > Refactor address resolution code > > > Key: QPID-3401 > URL: https://issues.apache.org/jira/browse/QPID-3401 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Labels: addressing > Fix For: Future > > Attachments: QPID-3401-systests.patch, QPID-3401.patch, > class_diagram.png, model2.gif > > > After some thought it seems that the following JIRA's would benefit from some
Re: Review Request: Destination refactoring
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4658/#review7940 --- Just an update on the status. I have already made the changes suggested here. In addition I have also made further changes based on more comments received by Rob Godfrey. The only missing piece (a critical one at that) is the testing. I'm planning to add the unit tests soon. - rajith On 2012-04-05 15:03:30, rajith attapattu wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/4658/ > --- > > (Updated 2012-04-05 15:03:30) > > > Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, Rafael > Schloming, and Rob Godfrey. > > > Summary > --- > > The following patch is based on the various discussions we've had on the dev > list about restructing our destination implementation. > As the first phase this patch only includes the new class heirachy. For the > second phase we will tackle the integration into the code base. > > A summary of the desgin is as follows, > > 1. Once initialized with the destination string, the destination objects are > immutable. > 2. There are 2 concrete implementations in the form of QpidTopic and > QpidQueue. > 3. Destinations will be desginated as "Queues" and "Topics" by the users in > the jndi file. This prevents us from having to automagically decide the type. > 4. Both BURL and Address strings are parsed and adapted into a common data > structure. Internally the code will work with this data structure. > 5. The Destination impl does not depend on any other classes, thus allowing > it be used with the current code or the new client. > > (There are 2 oe 3 white space errors that I can't seem to get rid of. It > seems they are comming from the diff process). > > > This addresses bug QPID-3401. > https://issues.apache.org/jira/browse/QPID-3401 > > > Diffs > - > > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/DestinationStringParser.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidQueue.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryQueue.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTopic.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/TemporaryDestinationProvider.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/Address.java > 1309769 > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/AddressException.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Link.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/address/Node.java > PRE-CREATION > > http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/messaging/util/AddressHelper.java > PRE-CREATION > > Diff: https://reviews.apache.org/r/4658/diff > > > Testing > --- > > > Thanks, > > rajith > >
[jira] [Commented] (QPID-4001) Add a java version of the Qpid API
[ https://issues.apache.org/jira/browse/QPID-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276898#comment-13276898 ] jirapos...@reviews.apache.org commented on QPID-4001: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5151/ --- Review request for qpid, Robbie Gemmell, Weston Price, Rafael Schloming, and Rob Godfrey. Summary --- As mentioned in the JIRA (and based on offline discussions I had with some folks) it would be good if we can settle down on a set of interfaces for the java version of the Qpid API. The JMS layer could then be built on top of this, without having to wait until the api implementation is complete. Implementation possibilities include, 1. A java implementation of this API 2. This acting as a wrapper for the python (via jython) or c++ client I wonder if we could do something more clever with the Message interface using generics to denote the type of content. I certainly appreciate feedback and comments :) This addresses bug QPID-4001. https://issues.apache.org/jira/browse/QPID-4001 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.deps 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.xml 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/build.xml PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Connection.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Message.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Receiver.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Sender.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Session.java PRE-CREATION Diff: https://reviews.apache.org/r/5151/diff Testing --- Thanks, rajith > Add a java version of the Qpid API > -- > > Key: QPID-4001 > URL: https://issues.apache.org/jira/browse/QPID-4001 > Project: Qpid > Issue Type: New Feature > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu > Fix For: 0.17 > > > Both C++ and Python have a common API that is commonly referred to as the > "Qpid API". There have been numerous requests to add one for Java. > The consensus we have so far for the upcomming new client is to have the > following layering where the Qpid API is a major component. > proton-j --> Qpid API --> JMS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: QPID-4001 Interfaces for QPID API
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5151/ --- Review request for qpid, Robbie Gemmell, Weston Price, Rafael Schloming, and Rob Godfrey. Summary --- As mentioned in the JIRA (and based on offline discussions I had with some folks) it would be good if we can settle down on a set of interfaces for the java version of the Qpid API. The JMS layer could then be built on top of this, without having to wait until the api implementation is complete. Implementation possibilities include, 1. A java implementation of this API 2. This acting as a wrapper for the python (via jython) or c++ client I wonder if we could do something more clever with the Message interface using generics to denote the type of content. I certainly appreciate feedback and comments :) This addresses bug QPID-4001. https://issues.apache.org/jira/browse/QPID-4001 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.deps 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/build.xml 1339266 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/build.xml PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Connection.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Message.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Receiver.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Sender.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client-api/src/main/java/org/apache/qpid/messaging/Session.java PRE-CREATION Diff: https://reviews.apache.org/r/5151/diff Testing --- Thanks, rajith
[jira] [Assigned] (QPID-4004) qpid::framing::Buffer::Iterator not very useful
[ https://issues.apache.org/jira/browse/QPID-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned QPID-4004: - Assignee: Andrew Stitcher > qpid::framing::Buffer::Iterator not very useful > --- > > Key: QPID-4004 > URL: https://issues.apache.org/jira/browse/QPID-4004 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Reporter: Florian Weimer >Assignee: Andrew Stitcher >Priority: Minor > > The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is > not a bidirectional iterator. It's not even a forward iterator because the > iterator state is kept in the referenced buffer object. It is not possible > to use a pair of such iterators to form a range, so not many algorithms can > be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4004) qpid::framing::Buffer::Iterator not very useful
Florian Weimer created QPID-4004: Summary: qpid::framing::Buffer::Iterator not very useful Key: QPID-4004 URL: https://issues.apache.org/jira/browse/QPID-4004 Project: Qpid Issue Type: Improvement Components: C++ Broker Reporter: Florian Weimer Priority: Minor The definition of qpid::framing::Buffer::Iterator seems buggy to me. This is not a bidirectional iterator. It's not even a forward iterator because the iterator state is kept in the referenced buffer object. It is not possible to use a pair of such iterators to form a range, so not many algorithms can be used on them (at least not in a safe manner). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Concerns about qpid::framing::Buffer::Iterator
On Wed, 2012-05-16 at 15:09 +0200, Florian Weimer wrote: > Hi, > > the definition of qpid::framing::Buffer::Iterator seems buggy to me. > This is not a bidirectional iterator. It's not even a forward iterator > because the iterator state is kept in the referenced buffer object. It > is not possible to use a pair of such iterators to form a range, so not > many algorithms can be used on them (at least not in a safe manner). > > Consequently, I don't think this class is very useful. Perhaps it can > be removed together with the Buffer::getIterator() method? I agree with this - >From a quick git grep of the source code the Iterator is only used in cpp/src/qpid/framing/AMQCommandControlBody.h. And it seems that AMQCommandControlBody.h is not used anywhere in the source! (Again according to git grep) So it seems that we could just remove this code entirely. On a side note - We do seem to have a certain amount of dead code hanging around ripe for deletion. Perhaps open a Jira so that we can track this issue? Assign it to me if you like. Thanks for looking at this. Andrew - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3175) SSL support in Python client libraries
[
https://issues.apache.org/jira/browse/QPID-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276773#comment-13276773
]
Michal Zerola commented on QPID-3175:
-
Hi,
we are encountering problems when using the ssl transport layer in Python
clients. When the client is sending messages in burst to the broker in
asynchronous manner (sync=False in Sender.send) the exception is occasionally
thrown with the following output:
[Errno 1] _ssl.c:1217: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write
retry
It seems, like the client's socket gets full, so the next underlying
SSLSocket.write() throws the SSLError (with SSL_ERROR_WANT_WRITE as a code) but
this situation is not handled properly. One can see, that in
qpid/messaging/transports.py in the constructor of the SSL transport the socket
is set to NON BLOCKING. Such a non blocking socket then behaves that write()
doesn't wait till there is enough space on the socket and may throw the above
exception. The question is therefore:
* Why is SSLSocket set to NON BLOCKING state in contrast to the non SSL
transport?
* Is handling of the above SSL_ERROR_WANT_{WRITE,READ} errors implemented
properly in the Python's API?
Thanks for answers. Best,
Michal
> SSL support in Python client libraries
> --
>
> Key: QPID-3175
> URL: https://issues.apache.org/jira/browse/QPID-3175
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Affects Versions: 0.8
> Environment: Windows XP, Python 2.7.1, (broker Red Hat MRG 1.3 on
> RHEL 5.5)
>Reporter: JAkub Scholz
>Assignee: Rafael H. Schloming
> Labels: possibly_complete
> Fix For: 0.15
>
> Attachments: QPID-3175.patch, QPID-3175a.patch, sasl_external.patch
>
>
> I was trying to connect to my broker with SSL encrypted connection (both
> PLAIN and EXTERNAL authentication methods). However, it seems to be not
> working. I get following error messages:
> Traceback (most recent call last):
> File "ssl-external.py", line 20, in
> connection.open()
> File "", line 6, in open
> File
> "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py",
> line 244, in open
> self.attach()
> File "", line 6, in attach
> File
> "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py",
> line 262, in attach
> self._ewait(lambda: self._transport_connected and not self._unlinked())
> File
> "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py",
> line 197, in _ewait
> self.check_error()
> File
> "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py",
> line 190, in check_error
> raise self.error
> qpid.messaging.exceptions.ConnectError: [Errno 1] _ssl.c:499:
> error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
> In the source codes (messaging/transports.py), the SSL seems to be supported
> and implemented, but it is not working. I didn't found any possibilities how
> to pass the certificates to the SSL libraries and the wrap_socket call in
> transports.py is calling the wrap_socket without any additional attributes
> except the original socket.
> I didn't had the chance to test other platforms or Python versions, except
> Python 2.4.3 on RHEL 5.5, where the SSL is not supported at all (the SSL
> support in Python changed significantly with 2.6)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Binding URL Options
Guys, thx for the explanation. I will have a look at the code to see how best to carry this option in the address structure. It appears that this can be put under x-subscriber map. When I post the code in this area, I will make sure to ping you both to ensure I got it right. Thanks again Rajith On Wed, May 16, 2012 at 4:25 AM, Oleksandr Rudyy wrote: > Hi Rajith, > > I am sorry for a delayed reply. > Option "reject_behaviour" is a client setting only and it is not > passed into queue declare arguments. With reject_behaviour=server the > 0-9-x client sends BasicReject commands for unacknowledged messages on > recover to reject these messages either for the entire connection > globally or only for the queues with this behaviour. With > reject_behaviour=normal 0-9-x client sends BasicRecoverSyncOk command > only on session recover. > > Kind Regards, > Alex > > On 15 May 2012 14:24, Rajith Attapattu wrote: > > Alex, > > > > Thanks for the explanation. > > I assume this is passed as a queue-declare argument ? > > > > Regards, > > > > Rajith > > > > > > On Tue, May 15, 2012 at 4:30 AM, Oleksandr Rudyy > wrote: > > > >> Hi Rajith, > >> > >> Option reject_behaviour was introduced as part of work on implementing > >> DLQ functionality in java broker. This is only 0-9-1 client setting > >> and it is not needed for 0-10 client. > >> By default, redelivered messages are not moved into DLQ after > >> exceeding Maximum redelivery attempts (for backward compatibility). In > >> order to have redelivered messages to be moved into DLQ after reaching > >> Maximum redelivery number the client should set > >> reject_behaviour=server either as a connection option or a queue > >> Binding URL option. > >> > >> Kind Regards, > >> Alex > >> > >> > >> > >> On 14 May 2012 22:36, Rajith Attapattu wrote: > >> > Hi All, > >> > > >> > I'm trying to compile an exhaustive list of all the valid options for > >> > binding URL. > >> > Some of the options make sense while others a lot is left to be > desired. > >> > I'd really appreciate some help in agreeing to a proper list and also > >> > updating the wiki for accuracy. > >> > > >> > The wiki page here > >> > https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the > >> > following options. > >> > > >> > exclusive boolean Is this an exclusive connection > >> > autodelete boolean Should this queue be deleted on client > >> > disconnection > >> > durable boolean Create a durable queue > >> > clientid string Use the following client id > >> > subscription boolean Create a subscription to this destination > >> > routingkey string Use this value as the routing key > >> > > >> > While the code has the following options, > >> > > >> > public static final String OPTION_EXCLUSIVE = "exclusive"; > >> > public static final String OPTION_AUTODELETE = "autodelete"; > >> > public static final String OPTION_DURABLE = "durable"; > >> > public static final String OPTION_BROWSE = "browse"; > >> > public static final String OPTION_CLIENTID = "clientid"; > >> > public static final String OPTION_SUBSCRIPTION = "subscription"; > >> > public static final String OPTION_ROUTING_KEY = "routingkey"; > >> > public static final String OPTION_BINDING_KEY = "bindingkey"; > >> > public static final String OPTION_REJECT_BEHAVIOUR = > "rejectbehaviour"; > >> > > >> > (*) Multiple Binding keys can be specified. > >> > > >> > While most of the options are quite straight forward I'm trying to > figure > >> > out the intended behaviour for a few. > >> > > >> > 1. Subscription > >> > What's the intended usage for "subscription" ? > >> > All though the wiki lists it as a boolean it has been used in a > >> rather > >> > bizarre way in the BindingURLParser.java > >> > (All though I was the author of BindingURLParser I simply used the > >> > same that was there in the old code). > >> > > >> >Could we remove this option? > >> > > >> > 2. Client ID > >> > We don't use the queue-name worked out here in anyway when we > create > >> > the durable subscription name. > >> > Could we remove this option ? > >> > > >> > 3. OPTION_REJECT_BEHAVIOUR > >> > Could somebody please explain the intended behaviour for this > option > >> > so I could correctly pass it when creating the address structure out > of a > >> > BURL. > >> > > >> > Regards, > >> > > >> > Rajith > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > >> For additional commands, e-mail: dev-h...@qpid.apache.org > >> > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
Concerns about qpid::framing::Buffer::Iterator
Hi, the definition of qpid::framing::Buffer::Iterator seems buggy to me. This is not a bidirectional iterator. It's not even a forward iterator because the iterator state is kept in the referenced buffer object. It is not possible to use a pair of such iterators to form a range, so not many algorithms can be used on them (at least not in a safe manner). Consequently, I don't think this class is very useful. Perhaps it can be removed together with the Buffer::getIterator() method? Florian -- Florian Weimer / Red Hat Product Security Team - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4003) qpid-cluster to allow --sasl-mechanism option
[ https://issues.apache.org/jira/browse/QPID-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Moravec updated QPID-4003: Attachment: qpid-cluster-mechList.patch patch implementing --sasl-mechanism option. Simple copy&paste code from qpid-stat, I verified it works properly. > qpid-cluster to allow --sasl-mechanism option > - > > Key: QPID-4003 > URL: https://issues.apache.org/jira/browse/QPID-4003 > Project: Qpid > Issue Type: Improvement > Components: Python Tools >Affects Versions: 0.14 >Reporter: Pavel Moravec >Priority: Minor > Labels: patch > Attachments: qpid-cluster-mechList.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Description of problem: > qpid-cluster shall have option --sasl-mechanism to select which SASL > authentication mechanism it wishes to use. Other qpid tools have it. > That makes sense e.g. when more mechanisms are allowed and one wishes to > authenticate qpid-cluster via Kerberos. Currently qpid-cluster picks up the > most secure method (DIGEST-MD5) that can't be changed. > Trivial patch is already proposed. > Version-Release number of selected component (if applicable): > qpid 0.14 > How reproducible: > 100% > Steps to Reproduce: > 1. don't limit auth.mechanisms in /etc/sasl2/qpidd.conf (comment out > mech_list there, if present) > 2. have auth=yes in a clustered broker > 3. Setup Kerberos credentials. > 4. Try to run qpid-cluster authenticating via Kerberos. > > Actual results: > There is no option to pick up a mechanism (in our case, GSSAPI). > Expected results: > Have --sasl-mechanism option available. > Additional info: > Easy patch proposed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4003) qpid-cluster to allow --sasl-mechanism option
Pavel Moravec created QPID-4003: --- Summary: qpid-cluster to allow --sasl-mechanism option Key: QPID-4003 URL: https://issues.apache.org/jira/browse/QPID-4003 Project: Qpid Issue Type: Improvement Components: Python Tools Affects Versions: 0.14 Reporter: Pavel Moravec Priority: Minor Description of problem: qpid-cluster shall have option --sasl-mechanism to select which SASL authentication mechanism it wishes to use. Other qpid tools have it. That makes sense e.g. when more mechanisms are allowed and one wishes to authenticate qpid-cluster via Kerberos. Currently qpid-cluster picks up the most secure method (DIGEST-MD5) that can't be changed. Trivial patch is already proposed. Version-Release number of selected component (if applicable): qpid 0.14 How reproducible: 100% Steps to Reproduce: 1. don't limit auth.mechanisms in /etc/sasl2/qpidd.conf (comment out mech_list there, if present) 2. have auth=yes in a clustered broker 3. Setup Kerberos credentials. 4. Try to run qpid-cluster authenticating via Kerberos. Actual results: There is no option to pick up a mechanism (in our case, GSSAPI). Expected results: Have --sasl-mechanism option available. Additional info: Easy patch proposed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Binding URL Options
Hi Rajith, I am sorry for a delayed reply. Option "reject_behaviour" is a client setting only and it is not passed into queue declare arguments. With reject_behaviour=server the 0-9-x client sends BasicReject commands for unacknowledged messages on recover to reject these messages either for the entire connection globally or only for the queues with this behaviour. With reject_behaviour=normal 0-9-x client sends BasicRecoverSyncOk command only on session recover. Kind Regards, Alex On 15 May 2012 14:24, Rajith Attapattu wrote: > Alex, > > Thanks for the explanation. > I assume this is passed as a queue-declare argument ? > > Regards, > > Rajith > > > On Tue, May 15, 2012 at 4:30 AM, Oleksandr Rudyy wrote: > >> Hi Rajith, >> >> Option reject_behaviour was introduced as part of work on implementing >> DLQ functionality in java broker. This is only 0-9-1 client setting >> and it is not needed for 0-10 client. >> By default, redelivered messages are not moved into DLQ after >> exceeding Maximum redelivery attempts (for backward compatibility). In >> order to have redelivered messages to be moved into DLQ after reaching >> Maximum redelivery number the client should set >> reject_behaviour=server either as a connection option or a queue >> Binding URL option. >> >> Kind Regards, >> Alex >> >> >> >> On 14 May 2012 22:36, Rajith Attapattu wrote: >> > Hi All, >> > >> > I'm trying to compile an exhaustive list of all the valid options for >> > binding URL. >> > Some of the options make sense while others a lot is left to be desired. >> > I'd really appreciate some help in agreeing to a proper list and also >> > updating the wiki for accuracy. >> > >> > The wiki page here >> > https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the >> > following options. >> > >> > exclusive boolean Is this an exclusive connection >> > autodelete boolean Should this queue be deleted on client >> > disconnection >> > durable boolean Create a durable queue >> > clientid string Use the following client id >> > subscription boolean Create a subscription to this destination >> > routingkey string Use this value as the routing key >> > >> > While the code has the following options, >> > >> > public static final String OPTION_EXCLUSIVE = "exclusive"; >> > public static final String OPTION_AUTODELETE = "autodelete"; >> > public static final String OPTION_DURABLE = "durable"; >> > public static final String OPTION_BROWSE = "browse"; >> > public static final String OPTION_CLIENTID = "clientid"; >> > public static final String OPTION_SUBSCRIPTION = "subscription"; >> > public static final String OPTION_ROUTING_KEY = "routingkey"; >> > public static final String OPTION_BINDING_KEY = "bindingkey"; >> > public static final String OPTION_REJECT_BEHAVIOUR = "rejectbehaviour"; >> > >> > (*) Multiple Binding keys can be specified. >> > >> > While most of the options are quite straight forward I'm trying to figure >> > out the intended behaviour for a few. >> > >> > 1. Subscription >> > What's the intended usage for "subscription" ? >> > All though the wiki lists it as a boolean it has been used in a >> rather >> > bizarre way in the BindingURLParser.java >> > (All though I was the author of BindingURLParser I simply used the >> > same that was there in the old code). >> > >> > Could we remove this option? >> > >> > 2. Client ID >> > We don't use the queue-name worked out here in anyway when we create >> > the durable subscription name. >> > Could we remove this option ? >> > >> > 3. OPTION_REJECT_BEHAVIOUR >> > Could somebody please explain the intended behaviour for this option >> > so I could correctly pass it when creating the address structure out of a >> > BURL. >> > >> > Regards, >> > >> > Rajith >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org >> For additional commands, e-mail: dev-h...@qpid.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
