[JBoss JIRA] Created: (EJBTHREE-1647) @Resource injection of primitive types from JNDI
by Dennis Reed (JIRA)
@Resource injection of primitive types from JNDI
------------------------------------------------
Key: EJBTHREE-1647
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1647
Project: EJB 3.0
Issue Type: Bug
Components: injection
Affects Versions: AS 4.2.1.GA
Reporter: Dennis Reed
The following does not work to inject an arbitrary JNDI entry for primitive/primitive wrapper/String fields:
@Resource( mappedName = "java:/blah/blah" )
String myVar;
In older versions, a "NYI" exception was thrown (then changed to a different exception before getting to the user).
In newer versions, the literal value in mappedName is injected.
For all other types, the JNDI entry injection works. For example, the following does inject that same String from JNDI:
@Resource( mappedName = "java:/blah/blah" )
Object myVar;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBRULES-1769) Improvements to pluggable operator framework
by Edson Tirelli (JIRA)
Improvements to pluggable operator framework
--------------------------------------------
Key: JBRULES-1769
URL: https://jira.jboss.org/jira/browse/JBRULES-1769
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Edson Tirelli
Assignee: Edson Tirelli
e-mail from Michel Zimmermann:
-----------
Hi Edson,
I think I got it working :-)
Edson Tirelli wrote:
> For an example, look at the file SetEvaluatorsDefinition and look at
> the BaseMemberOf inner class. So, all the logic is in there, but we
> still used subclasses just to set the constructor attributes and
> override the toString() method, but you could still implement
> everything in a single class I guess.
Yes, this approach makes sense as long as you don't need to use the
different VariableContextEntry subclasses for handling double, char etc.
Yet, this can be handled, too.
toString():
You can avoid subclassing from your BaseMyEvaluatorClass to override
toString() by using a string method like:
public String toString() {
return getValueType().getName() + " " +
getOperator().getOperatorString();
}
Regarding the evaluator API:
If you only need one evaluator class (subclassed from BaseEvaluator),
personally I don't like the > 10 static calls to
addEvaluator(type, operator, myEvaluatorInstance)
in the EvaluatorDefinition class.
So, how about adding the method addDefaultEvaluator(operator,
evaluatorClass) to EvaluatorCache, see attachment?
This would allow you to register a evaluator as default and only overide
the special cases...
PS: If you are interested I will write some small tutorial about custom
evaluators / operators in drools trunk. This might take a week or two,
though. Any preferences regarding the format?
Thanks for the help....
cu, Michael
@SuppressWarnings("unchecked")
public void addDefaultEvaluator(final Operator operator, Class evaluatorClass) {
// define the constructor
Class[] evaluatorParameters = new Class[2];
evaluatorParameters[0] = ValueType.class;
evaluatorParameters[1] = Operator.class;
// get the constructor
try {
Constructor<BaseEvaluator> constructor;
constructor = evaluatorClass.getConstructor( evaluatorParameters );
// add feault operators
addEvaluator(ValueType.ARRAY_TYPE, operator, constructor.newInstance(ValueType.ARRAY_TYPE, operator));
addEvaluator(ValueType.BIG_DECIMAL_TYPE, operator, constructor.newInstance(ValueType.BIG_DECIMAL_TYPE, operator));
addEvaluator(ValueType.BIG_INTEGER_TYPE, operator, constructor.newInstance(ValueType.BIG_INTEGER_TYPE, operator));
addEvaluator(ValueType.BOOLEAN_TYPE, operator, constructor.newInstance(ValueType.BOOLEAN_TYPE, operator));
addEvaluator(ValueType.PBOOLEAN_TYPE, operator, constructor.newInstance(ValueType.PBOOLEAN_TYPE, operator));
addEvaluator(ValueType.BYTE_TYPE, operator, constructor.newInstance(ValueType.BYTE_TYPE, operator));
addEvaluator(ValueType.PBYTE_TYPE, operator, constructor.newInstance(ValueType.PBYTE_TYPE, operator));
addEvaluator(ValueType.CHAR_TYPE, operator, constructor.newInstance(ValueType.CHAR_TYPE, operator));
addEvaluator(ValueType.PCHAR_TYPE, operator, constructor.newInstance(ValueType.PCHAR_TYPE, operator));
addEvaluator(ValueType.DATE_TYPE, operator, constructor.newInstance(ValueType.DATE_TYPE, operator));
addEvaluator(ValueType.DOUBLE_TYPE, operator, constructor.newInstance(ValueType.DOUBLE_TYPE, operator));
addEvaluator(ValueType.PDOUBLE_TYPE, operator, constructor.newInstance(ValueType.PDOUBLE_TYPE, operator));
addEvaluator(ValueType.FLOAT_TYPE, operator, constructor.newInstance(ValueType.FLOAT_TYPE , operator));
addEvaluator(ValueType.PFLOAT_TYPE, operator, constructor.newInstance(ValueType.PFLOAT_TYPE, operator));
addEvaluator(ValueType.INTEGER_TYPE, operator, constructor.newInstance(ValueType.INTEGER_TYPE, operator));
addEvaluator(ValueType.PINTEGER_TYPE, operator, constructor.newInstance(ValueType.PINTEGER_TYPE, operator));
addEvaluator(ValueType.LONG_TYPE, operator, constructor.newInstance(ValueType.LONG_TYPE, operator));
addEvaluator(ValueType.PLONG_TYPE, operator, constructor.newInstance(ValueType.PLONG_TYPE, operator));
addEvaluator(ValueType.OBJECT_TYPE, operator, constructor.newInstance(ValueType.OBJECT_TYPE, operator));
addEvaluator(ValueType.SHORT_TYPE, operator, constructor.newInstance(ValueType.SHORT_TYPE, operator));
addEvaluator(ValueType.PSHORT_TYPE, operator, constructor.newInstance(ValueType.PSHORT_TYPE, operator));
addEvaluator(ValueType.STRING_TYPE, operator, constructor.newInstance(ValueType.STRING_TYPE, operator));
} catch (SecurityException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (NoSuchMethodException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IllegalArgumentException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (InstantiationException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IllegalAccessException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (InvocationTargetException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBRULES-1322) Accumulate functions are highly unreliable for long's and BigDecimals
by Geoffrey De Smet (JIRA)
Accumulate functions are highly unreliable for long's and BigDecimals
---------------------------------------------------------------------
Key: JBRULES-1322
URL: http://jira.jboss.com/jira/browse/JBRULES-1322
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.3
Reporter: Geoffrey De Smet
Assigned To: Edson Tirelli
Priority: Critical
Fix For: 4.1.0
When dealing with financial data, one should never ever use double's. Instead BigDecimal should be used.
Not because BigDecimal is bigger (that's rarely a problem) but because it doesn't do any decimal to binary transformation.
For example, it's impossible for a double to correctly represent "0.2", aka 1/5.
Summing many doubles (or even a few differing in scale), can easily give wrong results (and for financial data this tends to be important).
Using doubles to sum longs have the exact same problem.
Attached is a testcase patch which proves this by checking if (MAX_LONG - 4L) and 3L sum up to be (MAX_LONG - 1L).
Currently they don't.
One possible way to solve this is to fix JBRULES-1075,
which just happens to give drools-solver 3% more performance ;) what a coincidence ^^
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months