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.
