David,
You'll need to set the keystore and truststore system properties in your
client application. This obviates the need to put credentials in the URL.
Other than that, you should be able to use your Synapse-configured client
as-is.
To get a quick idea how to do this, take a look at our
Hi!
In our company we're using Apache QPID in some of our company-internal
web-applications (ASP.NET, C#).
One of them has the job to manage the QPID-Broker running on one of our
internal servers.
This is a quite old application and my job is to get it working for the newest
QPID-Version
Hi David,
Just to add to add to Phils email..
The javax.net.ssl properties will only influence the SSL behaviour of the
JMX interface, and not the messaging ports. For the latter you have to
specify them in the file one way or another.
The 'VM Summary' tab in JConsole has displayed the values
Hi David,
I beleive what Phil and Rajith were commenting on was the use of the SSL
certificates as opposed to the password in the connection URL, that is to
use Client Certificate Authentication such that the broker only allows the
connection if it trusts the clients certificate. This could be
Hi,
In the source tree there is a picture of how the .NET binding fits into the
native C++ messaging world:
qpid/cpp/doc/dev-readme/QPID-Component-README.pdf
The .NET Binding gives you access to the messaging library but no direct access
to the client library. Going forward the messaging
We do this using QMF calls... they achieve the same effect as old C++
client libraries
On Tue, Dec 11, 2012 at 1:40 PM, Chuck Rolke cro...@redhat.com wrote:
Hi,
In the source tree there is a picture of how the .NET binding fits into
the native C++ messaging world:
Hi, Phil,
With another of the response, you seem have recommended two approaches
on doing this -
1. use system variable
(1) use java option -D to pass the value in
(2) export variable to pass in the value
2. Pass the keystore and password via connection URL (like your test
case).
Hi, Robbie,
JMX is not our concern yet. I will keep this on file for reference in
the future.
About javax.net.ssl properties will only influence the SSL behaviour of
the JMX interface, so the messaging port, we should use configuration
in connection URL or in config.xml section connection.ssl,
Hi, Robbie,
Thanks for the info.
About authenticator, I have noticed that there are the following
configurations in our qpid config.xml.
security
principal-databases
principal-database
namecarbon-user-store/name
Hi,
I have a situation where I reuse the same destination queue for multiple
producers. What I am finding is that if I do this, the second instance
message is stuck and is not available for the MessageConsumer. Assume that
there is a connection that is started. I would have expected both test1()
Hi David,
There seems to be a bit of confusion here.
The brokers SSL configuration in relation to the messaging ports can only
be controlled using the connectorssl elements in config.xml. Phil was
suggesting that you could use system properties (which will be resolved at
broker startup) in the
Hi, Robbie,
Make sense.
The ssl keystore/truststore/passwords in connection url is for client
side only.
But for broker, the configuration should go in config.xml where the
variable can be used as per Phil and the value of the variables can be
passed in using -D or via environment variable.
The javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword properties
will influence the JMX port if SSL is enabled in the management element,
but so will the configuration in the management section.
The connection.ssl is indeed how to configure the messaging port, and
as explained in other
The variable value can be passed in using -D system properties, but not as
an environment variable (Phils example set the -D system property
configuration by supplying it to the startup script via an environment
variable the startup script uses to enable such configuration).
Robbie
On 11
Ok, Robbie,
Got it. Back to encrypt keystore password in connectionssl section
in config.xml, I guess it is not supported?
David
-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
Sent: Tuesday, December 11, 2012 4:59 PM
To: users@qpid.apache.org
Subject: Re:
Hi David,
The authentication system is pluggable (in the below case, using the class
element to specify a specific PrincipalDatabase implementation) and I
recall a discussion on here with someone from WSO2 a couple of years ago
about integrating with their existing authentication pieces, so this
Correct.
On 11 December 2012 22:02, david...@ubs.com wrote:
Ok, Robbie,
Got it. Back to encrypt keystore password in connectionssl section
in config.xml, I guess it is not supported?
David
-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
Sent: Tuesday,
Ok, Robbie.
-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
Sent: Tuesday, December 11, 2012 5:18 PM
To: users@qpid.apache.org
Subject: Re: How to encrypt user password in connection url
Hi David,
The authentication system is pluggable (in the below case,
Thank you, Robbie.
-Original Message-
From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com]
Sent: Tuesday, December 11, 2012 5:21 PM
To: users@qpid.apache.org
Subject: Re: How to encrypt ssl keystore password in config.xml
Correct.
On 11 December 2012 22:02, david...@ubs.com wrote:
Hi Venkat,
It appears that you are not closing your consumers, so I would guess what
you are seeing is the result of message prefetch.
The consumer has a prefetch buffer for messages (defaults to 500 but is
configurable, see
http://qpid.apache.org/books/0.18/Programming-In-Apache-Qpid/html/ for
Robbie,
Thanks for your prompt response. Closing the consumer did indeed fix the
second client consumer. Thanks again...
venkat
On Tue, Dec 11, 2012 at 3:11 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote:
Hi Venkat,
It appears that you are not closing your consumers, so I would guess what
21 matches
Mail list logo
