Adam Heath wrote:
Adrian Crum wrote:
Adam Heath wrote:
Adrian Crum wrote:
David,
Thank you for the detailed description of the problem - that made it
much easier to track down.
Yes it is UEL related, and also related to weak Java code in
mini-language.
The mini-lang code causing the exception is:
<field-to-list field-name="orderItemShipGrpInvResAndItemLocation"
list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
The ${orderItemShipGrpInvResAndItemLocation.productId} expression is
evaluated and returns a String - "GZ-2644". The String is appended to
orderItemShipGrpInvResAndItemLocation and the result is
"orderItemShipGrpInvResAndItemLocation.GZ-2644"
That String is handed off to the JUEL library for evaluation. I haven't
looked into the JUEL code to be sure, but I can assume JUEL thinks that
expression means "Take the orderItemShipGrpInvResAndItemLocation.GZ
variable and subtract 2644 from it." So, JUEL returns -2644.
The exception is thrown in FieldToList.java:
List<Object> toList = listAcsr.get(methodContext);
if (toList == null) {
if (Debug.verboseOn()) Debug.logVerbose("List not found with name "
+ listAcsr + ", creating new list", module);
toList = FastList.newInstance();
listAcsr.put(methodContext, toList);
}
Changing that to:
List<Object> toList = null;
try {
toList = listAcsr.get(methodContext);
} catch (Exception e) {}
if (toList == null) {
if (Debug.verboseOn()) Debug.logVerbose("List not found with name "
+ listAcsr + ", creating new list", module);
toList = FastList.newInstance();
listAcsr.put(methodContext, toList);
}
fixes the problem. It also makes more sense - because you can't assume
the object returned will always be a List (even without UEL).
Looking through the mini-language Java code, I see that assumption is
made a lot. I'm not sure where to go from here. Surrounding all of the
type casts with try-catch blocks would be a worthwhile endeavor, but it
is also a lot of work.
Anyways, I've made the change to most of the classes and can commit
them, but there are chances this exception might pop up elsewhere.
What do you think?
No, not correct.
If you have to change all the methods, then you are fixing the wrong
problem. The generics keep this problem from occuring. The problem
lies elsewhere, where-ever the listAcsr stuff is instantiated.
That uses the UtilGenerics.cast() method - because the Map of context
variables doesn't contain a single Object type - they could be anything.
It's called listAcsr, because the users of it require a list to be in
the map. If someone doesn't put a list into the map, then it's that
someone else that is the problem. Fix the correct problem, whatever put
the wrong type of object into the map.
That would require re-writing most of mini-language.
-Adrian
