Exclusive broker access
Hi, Is there a way to enforce a per account exclusive access to the broker? For example if a user has an opened connection to the broker, when he opens another connection the first one is automatically closed. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: Exclusive broker access
We are sorry we have to inform you that this functionality is not yet implemented, but is planned for the Q1 release in 2019. ;-)) sorry, couldn't resist ... I guess, you wouldn't want your mail sent to commons-dev, no? Ciao, Mario -Ursprüngliche Nachricht- Von: Emmanuel Bourg [mailto:ebo...@apache.org] Gesendet: Freitag, 09. Juli 2010 10:44 An: Commons Developers List Betreff: Exclusive broker access Hi, Is there a way to enforce a per account exclusive access to the broker? For example if a user has an opened connection to the broker, when he opens another connection the first one is automatically closed. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Exclusive broker access
Le 09/07/2010 10:50, Mario Ivankovits (Apache) a écrit : We are sorry we have to inform you that this functionality is not yet implemented, but is planned for the Q1 release in 2019. ;-)) sorry, couldn't resist ... I guess, you wouldn't want your mail sent to commons-dev, no? Ciao, Mario Oops wrong list ;) That was for the Qpid folks. Excellent project if you haven't tried it already. http://qpid.apache.org Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r962515 - in /commons/proper/math/trunk/src/main: java/org/apache/commons/math/analysis/polynomials/ java/org/apache/commons/math/exception/ java/org/apache/commons/math/random/ java
On 9 July 2010 14:15, er...@apache.org wrote:
Author: erans
Date: Fri Jul 9 13:15:28 2010
New Revision: 962515
URL: http://svn.apache.org/viewvc?rev=962515view=rev
Log:
MATH-361
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/polynomials/PolynomialFunction.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/NotPositiveException.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/NotStrictlyPositiveException.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/NumberIsTooLargeException.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/random/AbstractRandomGenerator.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/random/BitsStreamGenerator.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/random/RandomDataImpl.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/random/UncorrelatedRandomVectorGenerator.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/LocalizedFormats.java
commons/proper/math/trunk/src/main/resources/META-INF/localization/LocalizedFormats_fr.properties
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/polynomials/PolynomialFunction.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/polynomials/PolynomialFunction.java?rev=962515r1=962514r2=962515view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/polynomials/PolynomialFunction.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/polynomials/PolynomialFunction.java
Fri Jul 9 13:15:28 2010
@@ -19,7 +19,7 @@ package org.apache.commons.math.analysis
import java.io.Serializable;
import java.util.Arrays;
-import org.apache.commons.math.MathRuntimeException;
+import org.apache.commons.math.exception.NotStrictlyPositiveException;
import org.apache.commons.math.analysis.DifferentiableUnivariateRealFunction;
import org.apache.commons.math.analysis.UnivariateRealFunction;
import org.apache.commons.math.util.LocalizedFormats;
@@ -58,12 +58,13 @@ public class PolynomialFunction implemen
*
* @param c polynomial coefficients
* @throws NullPointerException if c is null
- * @throws IllegalArgumentException if c is empty
+ * @throws NotStrictlyPositiveException if c is empty
*/
public PolynomialFunction(double c[]) {
super();
if (c.length 1) {
- throw
MathRuntimeException.createIllegalArgumentException(LocalizedFormats.EMPTY_POLYNOMIALS_COEFFICIENTS_ARRAY);
+ throw new
NotStrictlyPositiveException(LocalizedFormats.EMPTY_POLYNOMIALS_COEFFICIENTS_ARRAY,
+ c.length);
}
Seems very odd to me to reject an empty array parameter with
NotStrictlyPositiveException.
I would expect that to be reserved for numeric data passed as a
parameter or as an array entry.
IllegalArgument seems much clearer to me; alternatively one could
perhaps create an EmptyArrayNotAllowedException, if this is a common
requirement.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r962306 - in /commons/proper/math/trunk/src/main: java/org/apache/commons/math/analysis/interpolation/ java/org/apache/commons/math/exception/ java/org/apache/commons/math/util/ resour
Le 09/07/2010 01:45, er...@apache.org a écrit :
Author: erans
/** {...@inheritdoc} */
@Override
public String getMessage() {
-return MessageFactory.buildMessage(Locale.US, pattern, arguments);
+final StringBuilder sb = new StringBuilder();
+
+if (specific != null) {
+sb.append(MessageFactory.buildMessage(Locale.US, specific,
arguments));
+sb.append(: );
+}
+sb.append(MessageFactory.buildMessage(Locale.US, general,
arguments));
+
+return sb.toString();
}
/** {...@inheritdoc} */
@Override
public String getLocalizedMessage() {
-return MessageFactory.buildMessage(Locale.getDefault(), pattern,
arguments);
+final StringBuilder sb = new StringBuilder();
+
+if (specific != null) {
+sb.append(MessageFactory.buildMessage(Locale.getDefault(),
specific, arguments));
+sb.append(: );
+}
+sb.append(MessageFactory.buildMessage(Locale.getDefault(), general,
arguments));
+
+return sb.toString();
I don't how we can use the same arguments in both the general and
specific messages and later combine them together. How is this different
from a more complete message ?
Luc
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r962306 - in /commons/proper/math/trunk/src/main: java/org/apache/commons/math/analysis/interpolation/ java/org/apache/commons/math/exception/ java/org/apache/commons/math/util/ resour
I don't how we can use the same arguments in both the general and
specific messages and later combine them together.
The place holders {0}, {1}, ... will be replaced by the corresponding
argument in both the specific and the general patterns.
How is this different
from a more complete message ?
It is not different, for your use-case (i.e. the detailed message will contain
the same information as before).
The general pattern describes the problem (what precondition was violated)
and is tied to the exception, so the developer does not have to copy/paste,
time and again, the pattern.
The specific pattern is optional but can be used to discriminate between
different contexts, if so desired (or required, should I say). Some
examples:
---Ex 1---
if (mean = 0) {
throw new NotStrictlyPositiveException(LocalizedFormats.MEAN, mean);
}
--
---Ex 2---
if (len = 0) {
throw new NotStrictlyPositiveException(LocalizedFormats.LENGTH,
len);
}
---Ex 3---
if (k = 0) {
throw new
NotStrictlyPositiveException(LocalizedFormats.NUMBER_OF_SAMPLES, k);
}
--
In all cases, the general problem is the same, but the specific context
will make the detailed message well... more specific.
Then the same existing (in LocalizedFormats) specific concept might be
involved
in another general problem (also existing), in which case we won't have to add
any new complete pattern: the new message will be created for the combination
of the existing patterns.
Of course, since you ask, I don't particularly like to see these
LocalizedFormats everywhere in the CM code; I hoped that they would be
encapsulated inside the exception classes. This is indeed no improvement
over the previous state of affairs (it's not worse anyways), but at least
now we have stateful exceptions that by themselves are potentially more
useful than a plain IllegalArgumentException.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r962515 - in /commons/proper/math/trunk/src/main: java/org/apache/commons/math/analysis/polynomials/ java/org/apache/commons/math/exception/ java/org/apache/commons/math/random/ java/o
public PolynomialFunction(double c[]) {
super();
if (c.length 1) {
- throw
MathRuntimeException.createIllegalArgumentException(LocalizedFormats.EMPTY_POLYNOMIALS_COEFFICIENTS_ARRAY);
+ throw new
NotStrictlyPositiveException(LocalizedFormats.EMPTY_POLYNOMIALS_COEFFICIENTS_ARRAY,
+ c.length);
}
Seems very odd to me to reject an empty array parameter with
NotStrictlyPositiveException.
It just means that a 0 length is not allowed.
I would expect that to be reserved for numeric data passed as a
parameter or as an array entry.
IllegalArgument seems much clearer to me;
NotStrictlyPositiveException is a subclass of IllegalArgumentException.
alternatively one could
perhaps create an EmptyArrayNotAllowedException, if this is a common
requirement.
Could be too.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r962515 - in /commons/proper/math/trunk/src/main: java/org/apache/commons/math/analysis/polynomials/ java/org/apache/commons/math/exception/ java/org/apache/commons/math/random/ java
On 9 July 2010 18:35, Gilles Sadowski gil...@harfang.homelinux.org wrote:
public PolynomialFunction(double c[]) {
super();
if (c.length 1) {
- throw
MathRuntimeException.createIllegalArgumentException(LocalizedFormats.EMPTY_POLYNOMIALS_COEFFICIENTS_ARRAY);
+ throw new
NotStrictlyPositiveException(LocalizedFormats.EMPTY_POLYNOMIALS_COEFFICIENTS_ARRAY,
+ c.length);
}
Seems very odd to me to reject an empty array parameter with
NotStrictlyPositiveException.
It just means that a 0 length is not allowed.
Or it could potentially mean that one of the array entries was 0.
The point is that the cause of the problem is not at all obvious from
the exception class name.
IMO it's less helpful than IAE.
I would expect that to be reserved for numeric data passed as a
parameter or as an array entry.
IllegalArgument seems much clearer to me;
NotStrictlyPositiveException is a subclass of IllegalArgumentException.
Irrelevant, since what is confusing here is the classname of the exception.
alternatively one could
perhaps create an EmptyArrayNotAllowedException, if this is a common
requirement.
Could be too.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
