Issue with expression evaluation (possibly UEL related?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with expression evaluation (possibly UEL related?)

David E Jones-3

To reproduce, from latest OFBiz revision and fresh database with it:

1. in ecommerce (or Order Manager) place a sales order for 10  
(anything more than 5) of product "GZ-2644"; this will cause an  
inventory reservation against a bulk facility location, therefore  
needing a stock move before picking the order
2. place another order for "GZ-2644" so that there are at least 2  
reservations against the bulk location
3. go to the Facility -> Stock Moves tab for the facility  
WebStoreWarehouse (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse 
)

When the page renders you'll get an error, the main exception is (just  
first couple of lines):

2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1)  
[       SimpleMethod.java:926:ERROR]
---- runtime exception report  
--------------------------------------------------
Error in simple-method operation [<field-to-list list-
name="oiirailByProdMap.$
{orderItemShipGrpInvResAndItemLocation.productId}" field-
name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:  
java.lang.ClassCastException: java.lang.Long
Exception: java.lang.ClassCastException
Message: java.lang.Long
---- stack trace  
---------------------------------------------------------------
java.lang.ClassCastException: java.lang.Long
org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)

This is happening in the StockMoveServices.xml file on line 65.

Somehow the expression "${oiirailByProdMap.$
{orderItemShipGrpInvResAndItemLocation.productId}" is evaluation to  
"-2,644" as evidenced by adding this log statement just before line  
the line 65 mentioned above:

<log level="info"  
message="orderItemShipGrpInvResAndItemLocation.productId=$
{orderItemShipGrpInvResAndItemLocation.productId}  oiirailByProdMap  
value=${oiirailByProdMap.$
{orderItemShipGrpInvResAndItemLocation.productId}"/>

The log shows:

2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1)  
[                Log.java:110:INFO ]  
[StockMoveServices.xml#findStockMovesNeeded]  
orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
oiirailByProdMap value=
2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1)  
[                Log.java:110:INFO ]  
[StockMoveServices.xml#findStockMovesNeeded]  
orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
oiirailByProdMap value=-2,644

In other words, on the second line you can see where the expression  
that should return a List object instead returns a Long object with  
the value of "-2,644" which appears to be the productId GZ-2644 parsed  
as an integer...

Any ideas as to how this might be happening? I suspect it is an issue  
with the UEL stuff Adrian recently added, since this was working just  
a few days ago.

I'm guessing this is happening in other places too...

-David


Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum-2
David,

Thank you for reporting this. I will look into it.

-Adrian


--- On Mon, 12/15/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Issue with expression evaluation (possibly UEL related?)
> To: [hidden email]
> Date: Monday, December 15, 2008, 1:24 AM
> To reproduce, from latest OFBiz revision and fresh database
> with it:
>
> 1. in ecommerce (or Order Manager) place a sales order for
> 10 (anything more than 5) of product "GZ-2644";
> this will cause an inventory reservation against a bulk
> facility location, therefore needing a stock move before
> picking the order
> 2. place another order for "GZ-2644" so that
> there are at least 2 reservations against the bulk location
> 3. go to the Facility -> Stock Moves tab for the
> facility WebStoreWarehouse
> (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse)
>
> When the page renders you'll get an error, the main
> exception is (just first couple of lines):
>
> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1) [      
> SimpleMethod.java:926:ERROR]
> ---- runtime exception report
> --------------------------------------------------
> Error in simple-method operation [<field-to-list
> list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
> field-name="orderItemShipGrpInvResAndItemLocation"
> map-name=""/>]: java.lang.ClassCastException:
> java.lang.Long
> Exception: java.lang.ClassCastException
> Message: java.lang.Long
> ---- stack trace
> ---------------------------------------------------------------
> java.lang.ClassCastException: java.lang.Long
> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>
> This is happening in the StockMoveServices.xml file on line
> 65.
>
> Somehow the expression
> "${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
> is evaluation to "-2,644" as evidenced by adding
> this log statement just before line the line 65 mentioned
> above:
>
> <log level="info"
> message="orderItemShipGrpInvResAndItemLocation.productId=${orderItemShipGrpInvResAndItemLocation.productId}
>  oiirailByProdMap
> value=${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
>
> The log shows:
>
> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1) [            
>    Log.java:110:INFO ]
> [StockMoveServices.xml#findStockMovesNeeded]
> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644
> oiirailByProdMap value=
> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1) [            
>    Log.java:110:INFO ]
> [StockMoveServices.xml#findStockMovesNeeded]
> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644
> oiirailByProdMap value=-2,644
>
> In other words, on the second line you can see where the
> expression that should return a List object instead returns
> a Long object with the value of "-2,644" which
> appears to be the productId GZ-2644 parsed as an integer...
>
> Any ideas as to how this might be happening? I suspect it
> is an issue with the UEL stuff Adrian recently added, since
> this was working just a few days ago.
>
> I'm guessing this is happening in other places too...
>
> -David


     
Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
In reply to this post by David E Jones-3
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?

-Adrian

David E Jones wrote:

>
> To reproduce, from latest OFBiz revision and fresh database with it:
>
> 1. in ecommerce (or Order Manager) place a sales order for 10 (anything
> more than 5) of product "GZ-2644"; this will cause an inventory
> reservation against a bulk facility location, therefore needing a stock
> move before picking the order
> 2. place another order for "GZ-2644" so that there are at least 2
> reservations against the bulk location
> 3. go to the Facility -> Stock Moves tab for the facility
> WebStoreWarehouse
> (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse)
>
>
> When the page renders you'll get an error, the main exception is (just
> first couple of lines):
>
> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1) [      
> SimpleMethod.java:926:ERROR]
> ---- runtime exception report
> --------------------------------------------------
> Error in simple-method operation [<field-to-list
> list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
> field-name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:
> java.lang.ClassCastException: java.lang.Long
> Exception: java.lang.ClassCastException
> Message: java.lang.Long
> ---- stack trace
> ---------------------------------------------------------------
> java.lang.ClassCastException: java.lang.Long
> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>
> This is happening in the StockMoveServices.xml file on line 65.
>
> Somehow the expression
> "${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
> is evaluation to "-2,644" as evidenced by adding this log statement just
> before line the line 65 mentioned above:
>
> <log level="info"
> message="orderItemShipGrpInvResAndItemLocation.productId=${orderItemShipGrpInvResAndItemLocation.productId}  
> oiirailByProdMap
> value=${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
>
>
> The log shows:
>
> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1) [                
> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
> oiirailByProdMap value=
> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1) [                
> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
> oiirailByProdMap value=-2,644
>
> In other words, on the second line you can see where the expression that
> should return a List object instead returns a Long object with the value
> of "-2,644" which appears to be the productId GZ-2644 parsed as an
> integer...
>
> Any ideas as to how this might be happening? I suspect it is an issue
> with the UEL stuff Adrian recently added, since this was working just a
> few days ago.
>
> I'm guessing this is happening in other places too...
>
> -David
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adam Heath-2
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.


Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
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.

-Adrian

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

David E Jones-3
In reply to this post by Adrian Crum

How exactly would that fix the problem? Wouldn't it just make the code  
fail, but fail with less noise... and possibly fail without any notice  
at all, leading to incorrect results that the system treats as correct.

In this case, we need the "GZ-2644" interpreted as a map key rather  
than as a minus operator in the middle of an expression... and unless  
there's something amazing going on here that I'm totally missing  
(which I acknowledge is possible), I don't think ignoring the type  
cast exception would help...

-David

On Dec 15, 2008, at 1:10 PM, 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?
>
> -Adrian
>
> David E Jones wrote:
>> To reproduce, from latest OFBiz revision and fresh database with it:
>> 1. in ecommerce (or Order Manager) place a sales order for 10  
>> (anything more than 5) of product "GZ-2644"; this will cause an  
>> inventory reservation against a bulk facility location, therefore  
>> needing a stock move before picking the order
>> 2. place another order for "GZ-2644" so that there are at least 2  
>> reservations against the bulk location
>> 3. go to the Facility -> Stock Moves tab for the facility  
>> WebStoreWarehouse (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse 
>> ) When the page renders you'll get an error, the main exception is  
>> (just first couple of lines):
>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1)  
>> [       SimpleMethod.java:926:ERROR]
>> ---- runtime exception report  
>> --------------------------------------------------
>> Error in simple-method operation [<field-to-list list-
>> name="oiirailByProdMap.$
>> {orderItemShipGrpInvResAndItemLocation.productId}" field-
>> name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:  
>> java.lang.ClassCastException: java.lang.Long
>> Exception: java.lang.ClassCastException
>> Message: java.lang.Long
>> ---- stack trace  
>> ---------------------------------------------------------------
>> java.lang.ClassCastException: java.lang.Long
>> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:
>> 79)
>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>> This is happening in the StockMoveServices.xml file on line 65.
>> Somehow the expression "${oiirailByProdMap.$
>> {orderItemShipGrpInvResAndItemLocation.productId}" is evaluation to  
>> "-2,644" as evidenced by adding this log statement just before line  
>> the line 65 mentioned above:
>> <log level="info"  
>> message="orderItemShipGrpInvResAndItemLocation.productId=$
>> {orderItemShipGrpInvResAndItemLocation.productId}  oiirailByProdMap  
>> value=${oiirailByProdMap.$
>> {orderItemShipGrpInvResAndItemLocation.productId}"/> The log shows:
>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1)  
>> [                Log.java:110:INFO ]  
>> [StockMoveServices.xml#findStockMovesNeeded]  
>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>> oiirailByProdMap value=
>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1)  
>> [                Log.java:110:INFO ]  
>> [StockMoveServices.xml#findStockMovesNeeded]  
>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>> oiirailByProdMap value=-2,644
>> In other words, on the second line you can see where the expression  
>> that should return a List object instead returns a Long object with  
>> the value of "-2,644" which appears to be the productId GZ-2644  
>> parsed as an integer...
>> Any ideas as to how this might be happening? I suspect it is an  
>> issue with the UEL stuff Adrian recently added, since this was  
>> working just a few days ago.
>> I'm guessing this is happening in other places too...
>> -David

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
The code already expects the possibility that the object doesn't exist
and creates a new one if it's missing. The try-catch block just treats
an invalid object type as a missing object and then everything runs the
same as always.

-Adrian

David E Jones wrote:

>
> How exactly would that fix the problem? Wouldn't it just make the code
> fail, but fail with less noise... and possibly fail without any notice
> at all, leading to incorrect results that the system treats as correct.
>
> In this case, we need the "GZ-2644" interpreted as a map key rather than
> as a minus operator in the middle of an expression... and unless there's
> something amazing going on here that I'm totally missing (which I
> acknowledge is possible), I don't think ignoring the type cast exception
> would help...
>
> -David
>
> On Dec 15, 2008, at 1:10 PM, 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?
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> To reproduce, from latest OFBiz revision and fresh database with it:
>>> 1. in ecommerce (or Order Manager) place a sales order for 10
>>> (anything more than 5) of product "GZ-2644"; this will cause an
>>> inventory reservation against a bulk facility location, therefore
>>> needing a stock move before picking the order
>>> 2. place another order for "GZ-2644" so that there are at least 2
>>> reservations against the bulk location
>>> 3. go to the Facility -> Stock Moves tab for the facility
>>> WebStoreWarehouse
>>> (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse)
>>> When the page renders you'll get an error, the main exception is
>>> (just first couple of lines):
>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1) [      
>>> SimpleMethod.java:926:ERROR]
>>> ---- runtime exception report
>>> --------------------------------------------------
>>> Error in simple-method operation [<field-to-list
>>> list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>> field-name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:
>>> java.lang.ClassCastException: java.lang.Long
>>> Exception: java.lang.ClassCastException
>>> Message: java.lang.Long
>>> ---- stack trace
>>> ---------------------------------------------------------------
>>> java.lang.ClassCastException: java.lang.Long
>>> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>> This is happening in the StockMoveServices.xml file on line 65.
>>> Somehow the expression
>>> "${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>> is evaluation to "-2,644" as evidenced by adding this log statement
>>> just before line the line 65 mentioned above:
>>> <log level="info"
>>> message="orderItemShipGrpInvResAndItemLocation.productId=${orderItemShipGrpInvResAndItemLocation.productId}  
>>> oiirailByProdMap
>>> value=${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
>>> The log shows:
>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1) [                
>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>> oiirailByProdMap value=
>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1) [                
>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>> oiirailByProdMap value=-2,644
>>> In other words, on the second line you can see where the expression
>>> that should return a List object instead returns a Long object with
>>> the value of "-2,644" which appears to be the productId GZ-2644
>>> parsed as an integer...
>>> Any ideas as to how this might be happening? I suspect it is an issue
>>> with the UEL stuff Adrian recently added, since this was working just
>>> a few days ago.
>>> I'm guessing this is happening in other places too...
>>> -David
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

David E Jones-3

But in this case it's not missing... there is actually a Map member  
(that is a List object) with the key "GZ-2644" and the simple-method  
code is try to access it, so we can't just treat it as missing when it  
comes back as the wrong type...

In this case, and in many cases where the FlexibleStringExpander and  
FlexibleMapAccessor are used we are just trying to get the name of a  
"variable" (a Map member really), and we really don't need (or want...  
I don't think...) arithmetic operations. Is there any way to turn  
those off?

-David


On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:

> The code already expects the possibility that the object doesn't  
> exist and creates a new one if it's missing. The try-catch block  
> just treats an invalid object type as a missing object and then  
> everything runs the same as always.
>
> -Adrian
>
> David E Jones wrote:
>> How exactly would that fix the problem? Wouldn't it just make the  
>> code fail, but fail with less noise... and possibly fail without  
>> any notice at all, leading to incorrect results that the system  
>> treats as correct.
>> In this case, we need the "GZ-2644" interpreted as a map key rather  
>> than as a minus operator in the middle of an expression... and  
>> unless there's something amazing going on here that I'm totally  
>> missing (which I acknowledge is possible), I don't think ignoring  
>> the type cast exception would help...
>> -David
>> On Dec 15, 2008, at 1:10 PM, 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?
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> To reproduce, from latest OFBiz revision and fresh database with  
>>>> it:
>>>> 1. in ecommerce (or Order Manager) place a sales order for 10  
>>>> (anything more than 5) of product "GZ-2644"; this will cause an  
>>>> inventory reservation against a bulk facility location, therefore  
>>>> needing a stock move before picking the order
>>>> 2. place another order for "GZ-2644" so that there are at least 2  
>>>> reservations against the bulk location
>>>> 3. go to the Facility -> Stock Moves tab for the facility  
>>>> WebStoreWarehouse (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse 
>>>> ) When the page renders you'll get an error, the main exception  
>>>> is (just first couple of lines):
>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1)  
>>>> [       SimpleMethod.java:926:ERROR]
>>>> ---- runtime exception report  
>>>> --------------------------------------------------
>>>> Error in simple-method operation [<field-to-list list-
>>>> name="oiirailByProdMap.$
>>>> {orderItemShipGrpInvResAndItemLocation.productId}" field-
>>>> name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:  
>>>> java.lang.ClassCastException: java.lang.Long
>>>> Exception: java.lang.ClassCastException
>>>> Message: java.lang.Long
>>>> ---- stack trace  
>>>> ---------------------------------------------------------------
>>>> java.lang.ClassCastException: java.lang.Long
>>>> org
>>>> .ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>> Somehow the expression "${oiirailByProdMap.$
>>>> {orderItemShipGrpInvResAndItemLocation.productId}" is evaluation  
>>>> to "-2,644" as evidenced by adding this log statement just before  
>>>> line the line 65 mentioned above:
>>>> <log level="info"  
>>>> message="orderItemShipGrpInvResAndItemLocation.productId=$
>>>> {orderItemShipGrpInvResAndItemLocation.productId}  
>>>> oiirailByProdMap value=${oiirailByProdMap.$
>>>> {orderItemShipGrpInvResAndItemLocation.productId}"/> The log shows:
>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1)  
>>>> [                Log.java:110:INFO ]  
>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>> oiirailByProdMap value=
>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1)  
>>>> [                Log.java:110:INFO ]  
>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>> oiirailByProdMap value=-2,644
>>>> In other words, on the second line you can see where the  
>>>> expression that should return a List object instead returns a  
>>>> Long object with the value of "-2,644" which appears to be the  
>>>> productId GZ-2644 parsed as an integer...
>>>> Any ideas as to how this might be happening? I suspect it is an  
>>>> issue with the UEL stuff Adrian recently added, since this was  
>>>> working just a few days ago.
>>>> I'm guessing this is happening in other places too...
>>>> -David

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adam Heath-2
In reply to this post by Adrian Crum
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.
Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

David E Jones-3
In reply to this post by David E Jones-3

Also, is there any way to have UEL complain more? In this case what  
does it do when it sees the reference to  
"orderItemShipGrpInvResAndItemLocation.GZ"? Does it create a List  
object and add it to the Map, or seeing it is part of an arithmetic  
expression does it create it as some sort of numeric object? In the  
old stuff it would know from context what type of object to create,  
and if that is still around and it knows it should be a List then with  
trying to do an arithmetic operation on a list it would be nice if it  
complained.

Is there any place where errors or warnings are being suppressed  
instead of being thrown as exceptions... or at least logged?

-David


On Dec 15, 2008, at 2:14 PM, David E Jones wrote:

>
> But in this case it's not missing... there is actually a Map member  
> (that is a List object) with the key "GZ-2644" and the simple-method  
> code is try to access it, so we can't just treat it as missing when  
> it comes back as the wrong type...
>
> In this case, and in many cases where the FlexibleStringExpander and  
> FlexibleMapAccessor are used we are just trying to get the name of a  
> "variable" (a Map member really), and we really don't need (or  
> want... I don't think...) arithmetic operations. Is there any way to  
> turn those off?
>
> -David
>
>
> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>
>> The code already expects the possibility that the object doesn't  
>> exist and creates a new one if it's missing. The try-catch block  
>> just treats an invalid object type as a missing object and then  
>> everything runs the same as always.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> How exactly would that fix the problem? Wouldn't it just make the  
>>> code fail, but fail with less noise... and possibly fail without  
>>> any notice at all, leading to incorrect results that the system  
>>> treats as correct.
>>> In this case, we need the "GZ-2644" interpreted as a map key  
>>> rather than as a minus operator in the middle of an expression...  
>>> and unless there's something amazing going on here that I'm  
>>> totally missing (which I acknowledge is possible), I don't think  
>>> ignoring the type cast exception would help...
>>> -David
>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> To reproduce, from latest OFBiz revision and fresh database with  
>>>>> it:
>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10  
>>>>> (anything more than 5) of product "GZ-2644"; this will cause an  
>>>>> inventory reservation against a bulk facility location,  
>>>>> therefore needing a stock move before picking the order
>>>>> 2. place another order for "GZ-2644" so that there are at least  
>>>>> 2 reservations against the bulk location
>>>>> 3. go to the Facility -> Stock Moves tab for the facility  
>>>>> WebStoreWarehouse (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse 
>>>>> ) When the page renders you'll get an error, the main exception  
>>>>> is (just first couple of lines):
>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1)  
>>>>> [       SimpleMethod.java:926:ERROR]
>>>>> ---- runtime exception report  
>>>>> --------------------------------------------------
>>>>> Error in simple-method operation [<field-to-list list-
>>>>> name="oiirailByProdMap.$
>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" field-
>>>>> name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:  
>>>>> java.lang.ClassCastException: java.lang.Long
>>>>> Exception: java.lang.ClassCastException
>>>>> Message: java.lang.Long
>>>>> ---- stack trace  
>>>>> ---------------------------------------------------------------
>>>>> java.lang.ClassCastException: java.lang.Long
>>>>> org
>>>>> .ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:
>>>>> 79)
>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>> Somehow the expression "${oiirailByProdMap.$
>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" is evaluation  
>>>>> to "-2,644" as evidenced by adding this log statement just  
>>>>> before line the line 65 mentioned above:
>>>>> <log level="info"  
>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=$
>>>>> {orderItemShipGrpInvResAndItemLocation.productId}  
>>>>> oiirailByProdMap value=${oiirailByProdMap.$
>>>>> {orderItemShipGrpInvResAndItemLocation.productId}"/> The log  
>>>>> shows:
>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1)  
>>>>> [                Log.java:110:INFO ]  
>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>> oiirailByProdMap value=
>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1)  
>>>>> [                Log.java:110:INFO ]  
>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>> oiirailByProdMap value=-2,644
>>>>> In other words, on the second line you can see where the  
>>>>> expression that should return a List object instead returns a  
>>>>> Long object with the value of "-2,644" which appears to be the  
>>>>> productId GZ-2644 parsed as an integer...
>>>>> Any ideas as to how this might be happening? I suspect it is an  
>>>>> issue with the UEL stuff Adrian recently added, since this was  
>>>>> working just a few days ago.
>>>>> I'm guessing this is happening in other places too...
>>>>> -David
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
In reply to this post by David E Jones-3
<field-to-list field-name="orderItemShipGrpInvResAndItemLocation"
list-name="oiirailByProdMap[orderItemShipGrpInvResAndItemLocation.productId]"/>

would be a better syntax. But that would mean the XML code would have to
be changed. I was trying to resolve this in a backwards-compatible way.

Keep in mind the exception could still get thrown even without the UEL:

<set field="helloString" value="Hello World!"/>
<set field="invalidType" value="2.0" type="Double"/>
<field-to-list field-name="helloString"
list-name="invalidType"/>

-Adrian


David E Jones wrote:

>
> But in this case it's not missing... there is actually a Map member
> (that is a List object) with the key "GZ-2644" and the simple-method
> code is try to access it, so we can't just treat it as missing when it
> comes back as the wrong type...
>
> In this case, and in many cases where the FlexibleStringExpander and
> FlexibleMapAccessor are used we are just trying to get the name of a
> "variable" (a Map member really), and we really don't need (or want... I
> don't think...) arithmetic operations. Is there any way to turn those off?
>
> -David
>
>
> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>
>> The code already expects the possibility that the object doesn't exist
>> and creates a new one if it's missing. The try-catch block just treats
>> an invalid object type as a missing object and then everything runs
>> the same as always.
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> How exactly would that fix the problem? Wouldn't it just make the
>>> code fail, but fail with less noise... and possibly fail without any
>>> notice at all, leading to incorrect results that the system treats as
>>> correct.
>>> In this case, we need the "GZ-2644" interpreted as a map key rather
>>> than as a minus operator in the middle of an expression... and unless
>>> there's something amazing going on here that I'm totally missing
>>> (which I acknowledge is possible), I don't think ignoring the type
>>> cast exception would help...
>>> -David
>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> To reproduce, from latest OFBiz revision and fresh database with it:
>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10
>>>>> (anything more than 5) of product "GZ-2644"; this will cause an
>>>>> inventory reservation against a bulk facility location, therefore
>>>>> needing a stock move before picking the order
>>>>> 2. place another order for "GZ-2644" so that there are at least 2
>>>>> reservations against the bulk location
>>>>> 3. go to the Facility -> Stock Moves tab for the facility
>>>>> WebStoreWarehouse
>>>>> (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse)
>>>>> When the page renders you'll get an error, the main exception is
>>>>> (just first couple of lines):
>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1) [      
>>>>> SimpleMethod.java:926:ERROR]
>>>>> ---- runtime exception report
>>>>> --------------------------------------------------
>>>>> Error in simple-method operation [<field-to-list
>>>>> list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>> field-name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:
>>>>> java.lang.ClassCastException: java.lang.Long
>>>>> Exception: java.lang.ClassCastException
>>>>> Message: java.lang.Long
>>>>> ---- stack trace
>>>>> ---------------------------------------------------------------
>>>>> java.lang.ClassCastException: java.lang.Long
>>>>> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>> Somehow the expression
>>>>> "${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>> is evaluation to "-2,644" as evidenced by adding this log statement
>>>>> just before line the line 65 mentioned above:
>>>>> <log level="info"
>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=${orderItemShipGrpInvResAndItemLocation.productId}  
>>>>> oiirailByProdMap
>>>>> value=${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
>>>>> The log shows:
>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1) [                
>>>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>> oiirailByProdMap value=
>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1) [                
>>>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>> oiirailByProdMap value=-2,644
>>>>> In other words, on the second line you can see where the expression
>>>>> that should return a List object instead returns a Long object with
>>>>> the value of "-2,644" which appears to be the productId GZ-2644
>>>>> parsed as an integer...
>>>>> Any ideas as to how this might be happening? I suspect it is an
>>>>> issue with the UEL stuff Adrian recently added, since this was
>>>>> working just a few days ago.
>>>>> I'm guessing this is happening in other places too...
>>>>> -David
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

David E Jones-3
In reply to this post by David E Jones-3

This is a little painful, but I finally got decent result with a  
syntax variation. If we can get louder complaining from UEL we might  
be okay with this... but there are probably LOTS of simple-methods and  
other places that will need this sort of change.

Instead of:

oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}

I changed it to:

oiirailByProdMap[&quot;$
{orderItemShipGrpInvResAndItemLocation.productId}&quot;]

and it works fine. I played with a few common syntax variations before  
getting to this one... and both the quotes AND the square braces are  
necessary (leave either out and it won't work, and there is no  
complaining about it either).

Of course, this means that pretty much every simple-method, screen,  
form, etc (anything that is using the old stuff) needs to be tested,  
and if UEL isn't complaining about any little issue it runs into even  
a complete code coverage test won't reveal all problems because of  
possible data variations like this (like a productId with a dash, aka  
"subtraction symbol" in it).

Any other ideas? I like the idea of moving to a more expressive  
expression language like UEL, but we do need to make sure all angles  
of the transition are covered and that we follow one of the main rules  
for committers, ie don't break stuff... which I acknowledge is not  
always easy.

However we do it, we really need stay away from suppressing errors,  
especially with interpreted artifacts... the faster it fails when we  
know there is a failure the better.

-David


On Dec 15, 2008, at 2:24 PM, David E Jones wrote:

>
> Also, is there any way to have UEL complain more? In this case what  
> does it do when it sees the reference to  
> "orderItemShipGrpInvResAndItemLocation.GZ"? Does it create a List  
> object and add it to the Map, or seeing it is part of an arithmetic  
> expression does it create it as some sort of numeric object? In the  
> old stuff it would know from context what type of object to create,  
> and if that is still around and it knows it should be a List then  
> with trying to do an arithmetic operation on a list it would be nice  
> if it complained.
>
> Is there any place where errors or warnings are being suppressed  
> instead of being thrown as exceptions... or at least logged?
>
> -David
>
>
> On Dec 15, 2008, at 2:14 PM, David E Jones wrote:
>
>>
>> But in this case it's not missing... there is actually a Map member  
>> (that is a List object) with the key "GZ-2644" and the simple-
>> method code is try to access it, so we can't just treat it as  
>> missing when it comes back as the wrong type...
>>
>> In this case, and in many cases where the FlexibleStringExpander  
>> and FlexibleMapAccessor are used we are just trying to get the name  
>> of a "variable" (a Map member really), and we really don't need (or  
>> want... I don't think...) arithmetic operations. Is there any way  
>> to turn those off?
>>
>> -David
>>
>>
>> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>>
>>> The code already expects the possibility that the object doesn't  
>>> exist and creates a new one if it's missing. The try-catch block  
>>> just treats an invalid object type as a missing object and then  
>>> everything runs the same as always.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> How exactly would that fix the problem? Wouldn't it just make the  
>>>> code fail, but fail with less noise... and possibly fail without  
>>>> any notice at all, leading to incorrect results that the system  
>>>> treats as correct.
>>>> In this case, we need the "GZ-2644" interpreted as a map key  
>>>> rather than as a minus operator in the middle of an expression...  
>>>> and unless there's something amazing going on here that I'm  
>>>> totally missing (which I acknowledge is possible), I don't think  
>>>> ignoring the type cast exception would help...
>>>> -David
>>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> To reproduce, from latest OFBiz revision and fresh database  
>>>>>> with it:
>>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10  
>>>>>> (anything more than 5) of product "GZ-2644"; this will cause an  
>>>>>> inventory reservation against a bulk facility location,  
>>>>>> therefore needing a stock move before picking the order
>>>>>> 2. place another order for "GZ-2644" so that there are at least  
>>>>>> 2 reservations against the bulk location
>>>>>> 3. go to the Facility -> Stock Moves tab for the facility  
>>>>>> WebStoreWarehouse (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse 
>>>>>> ) When the page renders you'll get an error, the main exception  
>>>>>> is (just first couple of lines):
>>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1)  
>>>>>> [       SimpleMethod.java:926:ERROR]
>>>>>> ---- runtime exception report  
>>>>>> --------------------------------------------------
>>>>>> Error in simple-method operation [<field-to-list list-
>>>>>> name="oiirailByProdMap.$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" field-
>>>>>> name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:  
>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>> Exception: java.lang.ClassCastException
>>>>>> Message: java.lang.Long
>>>>>> ---- stack trace  
>>>>>> ---------------------------------------------------------------
>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>> org
>>>>>> .ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:
>>>>>> 79)
>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>>> Somehow the expression "${oiirailByProdMap.$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" is  
>>>>>> evaluation to "-2,644" as evidenced by adding this log  
>>>>>> statement just before line the line 65 mentioned above:
>>>>>> <log level="info"  
>>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}  
>>>>>> oiirailByProdMap value=${oiirailByProdMap.$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}"/> The log  
>>>>>> shows:
>>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1)  
>>>>>> [                Log.java:110:INFO ]  
>>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>> oiirailByProdMap value=
>>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1)  
>>>>>> [                Log.java:110:INFO ]  
>>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>> oiirailByProdMap value=-2,644
>>>>>> In other words, on the second line you can see where the  
>>>>>> expression that should return a List object instead returns a  
>>>>>> Long object with the value of "-2,644" which appears to be the  
>>>>>> productId GZ-2644 parsed as an integer...
>>>>>> Any ideas as to how this might be happening? I suspect it is an  
>>>>>> issue with the UEL stuff Adrian recently added, since this was  
>>>>>> working just a few days ago.
>>>>>> I'm guessing this is happening in other places too...
>>>>>> -David
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
In reply to this post by Adam Heath-2
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

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

David E Jones-3
In reply to this post by Adrian Crum

See my other message... it looks like there may be no way around  
changing existing code (and we'll have to use quotes AND square braces  
together for it, it appears anyway).

However, whatever we do we can't hide errors. The stuff below isn't  
helpful as the intent is not to intentionally get an exception, but to  
get UEL (or something) to complain when something isn't right and to  
do so in a way that is as easy to understand (and therefore fix) as  
possible.

This error, for example, was not immediately evident, not until I dug  
a bit. It would be great to do something about that...

-David


On Dec 15, 2008, at 2:35 PM, Adrian Crum wrote:

> <field-to-list field-name="orderItemShipGrpInvResAndItemLocation"
> list-
> name
> ="oiirailByProdMap[orderItemShipGrpInvResAndItemLocation.productId]"/>
>
> would be a better syntax. But that would mean the XML code would  
> have to be changed. I was trying to resolve this in a backwards-
> compatible way.
>
> Keep in mind the exception could still get thrown even without the  
> UEL:
>
> <set field="helloString" value="Hello World!"/>
> <set field="invalidType" value="2.0" type="Double"/>
> <field-to-list field-name="helloString"
> list-name="invalidType"/>
>
> -Adrian
>
>
> David E Jones wrote:
>> But in this case it's not missing... there is actually a Map member  
>> (that is a List object) with the key "GZ-2644" and the simple-
>> method code is try to access it, so we can't just treat it as  
>> missing when it comes back as the wrong type...
>> In this case, and in many cases where the FlexibleStringExpander  
>> and FlexibleMapAccessor are used we are just trying to get the name  
>> of a "variable" (a Map member really), and we really don't need (or  
>> want... I don't think...) arithmetic operations. Is there any way  
>> to turn those off?
>> -David
>> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>>> The code already expects the possibility that the object doesn't  
>>> exist and creates a new one if it's missing. The try-catch block  
>>> just treats an invalid object type as a missing object and then  
>>> everything runs the same as always.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> How exactly would that fix the problem? Wouldn't it just make the  
>>>> code fail, but fail with less noise... and possibly fail without  
>>>> any notice at all, leading to incorrect results that the system  
>>>> treats as correct.
>>>> In this case, we need the "GZ-2644" interpreted as a map key  
>>>> rather than as a minus operator in the middle of an expression...  
>>>> and unless there's something amazing going on here that I'm  
>>>> totally missing (which I acknowledge is possible), I don't think  
>>>> ignoring the type cast exception would help...
>>>> -David
>>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> To reproduce, from latest OFBiz revision and fresh database  
>>>>>> with it:
>>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10  
>>>>>> (anything more than 5) of product "GZ-2644"; this will cause an  
>>>>>> inventory reservation against a bulk facility location,  
>>>>>> therefore needing a stock move before picking the order
>>>>>> 2. place another order for "GZ-2644" so that there are at least  
>>>>>> 2 reservations against the bulk location
>>>>>> 3. go to the Facility -> Stock Moves tab for the facility  
>>>>>> WebStoreWarehouse (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse 
>>>>>> ) When the page renders you'll get an error, the main exception  
>>>>>> is (just first couple of lines):
>>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1)  
>>>>>> [       SimpleMethod.java:926:ERROR]
>>>>>> ---- runtime exception report  
>>>>>> --------------------------------------------------
>>>>>> Error in simple-method operation [<field-to-list list-
>>>>>> name="oiirailByProdMap.$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" field-
>>>>>> name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:  
>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>> Exception: java.lang.ClassCastException
>>>>>> Message: java.lang.Long
>>>>>> ---- stack trace  
>>>>>> ---------------------------------------------------------------
>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>> org
>>>>>> .ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:
>>>>>> 79)
>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>>> Somehow the expression "${oiirailByProdMap.$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" is  
>>>>>> evaluation to "-2,644" as evidenced by adding this log  
>>>>>> statement just before line the line 65 mentioned above:
>>>>>> <log level="info"  
>>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}  
>>>>>> oiirailByProdMap value=${oiirailByProdMap.$
>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}"/> The log  
>>>>>> shows:
>>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1)  
>>>>>> [                Log.java:110:INFO ]  
>>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>> oiirailByProdMap value=
>>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1)  
>>>>>> [                Log.java:110:INFO ]  
>>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>> oiirailByProdMap value=-2,644
>>>>>> In other words, on the second line you can see where the  
>>>>>> expression that should return a List object instead returns a  
>>>>>> Long object with the value of "-2,644" which appears to be the  
>>>>>> productId GZ-2644 parsed as an integer...
>>>>>> Any ideas as to how this might be happening? I suspect it is an  
>>>>>> issue with the UEL stuff Adrian recently added, since this was  
>>>>>> working just a few days ago.
>>>>>> I'm guessing this is happening in other places too...
>>>>>> -David

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
In reply to this post by David E Jones-3
I "log verbose" UEL exceptions because the spec dictates that an
exception is thrown whenever a variable isn't found - which happens a
lot in OFBiz.

The expression "orderItemShipGrpInvResAndItemLocation.GZ" would return
null if GZ isn't an element of orderItemShipGrpInvResAndItemLocation.

Let me work on this some more and I'll let you know if I find some other
options.

-Adrian

David E Jones wrote:

>
> Also, is there any way to have UEL complain more? In this case what does
> it do when it sees the reference to
> "orderItemShipGrpInvResAndItemLocation.GZ"? Does it create a List object
> and add it to the Map, or seeing it is part of an arithmetic expression
> does it create it as some sort of numeric object? In the old stuff it
> would know from context what type of object to create, and if that is
> still around and it knows it should be a List then with trying to do an
> arithmetic operation on a list it would be nice if it complained.
>
> Is there any place where errors or warnings are being suppressed instead
> of being thrown as exceptions... or at least logged?
>
> -David
>
>
> On Dec 15, 2008, at 2:14 PM, David E Jones wrote:
>
>>
>> But in this case it's not missing... there is actually a Map member
>> (that is a List object) with the key "GZ-2644" and the simple-method
>> code is try to access it, so we can't just treat it as missing when it
>> comes back as the wrong type...
>>
>> In this case, and in many cases where the FlexibleStringExpander and
>> FlexibleMapAccessor are used we are just trying to get the name of a
>> "variable" (a Map member really), and we really don't need (or want...
>> I don't think...) arithmetic operations. Is there any way to turn
>> those off?
>>
>> -David
>>
>>
>> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>>
>>> The code already expects the possibility that the object doesn't
>>> exist and creates a new one if it's missing. The try-catch block just
>>> treats an invalid object type as a missing object and then everything
>>> runs the same as always.
>>>
>>> -Adrian
>>>
>>> David E Jones wrote:
>>>> How exactly would that fix the problem? Wouldn't it just make the
>>>> code fail, but fail with less noise... and possibly fail without any
>>>> notice at all, leading to incorrect results that the system treats
>>>> as correct.
>>>> In this case, we need the "GZ-2644" interpreted as a map key rather
>>>> than as a minus operator in the middle of an expression... and
>>>> unless there's something amazing going on here that I'm totally
>>>> missing (which I acknowledge is possible), I don't think ignoring
>>>> the type cast exception would help...
>>>> -David
>>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> To reproduce, from latest OFBiz revision and fresh database with it:
>>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10
>>>>>> (anything more than 5) of product "GZ-2644"; this will cause an
>>>>>> inventory reservation against a bulk facility location, therefore
>>>>>> needing a stock move before picking the order
>>>>>> 2. place another order for "GZ-2644" so that there are at least 2
>>>>>> reservations against the bulk location
>>>>>> 3. go to the Facility -> Stock Moves tab for the facility
>>>>>> WebStoreWarehouse
>>>>>> (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse)
>>>>>> When the page renders you'll get an error, the main exception is
>>>>>> (just first couple of lines):
>>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1) [      
>>>>>> SimpleMethod.java:926:ERROR]
>>>>>> ---- runtime exception report
>>>>>> --------------------------------------------------
>>>>>> Error in simple-method operation [<field-to-list
>>>>>> list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>>> field-name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:
>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>> Exception: java.lang.ClassCastException
>>>>>> Message: java.lang.Long
>>>>>> ---- stack trace
>>>>>> ---------------------------------------------------------------
>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
>>>>>>
>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>>> Somehow the expression
>>>>>> "${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>>> is evaluation to "-2,644" as evidenced by adding this log
>>>>>> statement just before line the line 65 mentioned above:
>>>>>> <log level="info"
>>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=${orderItemShipGrpInvResAndItemLocation.productId}  
>>>>>> oiirailByProdMap
>>>>>> value=${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
>>>>>> The log shows:
>>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1) [                
>>>>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>> oiirailByProdMap value=
>>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1) [                
>>>>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>> oiirailByProdMap value=-2,644
>>>>>> In other words, on the second line you can see where the
>>>>>> expression that should return a List object instead returns a Long
>>>>>> object with the value of "-2,644" which appears to be the
>>>>>> productId GZ-2644 parsed as an integer...
>>>>>> Any ideas as to how this might be happening? I suspect it is an
>>>>>> issue with the UEL stuff Adrian recently added, since this was
>>>>>> working just a few days ago.
>>>>>> I'm guessing this is happening in other places too...
>>>>>> -David
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
In reply to this post by David E Jones-3
I could add a log message to the catch block: "Expected some type, got
some other type..."

-Adrian

David E Jones wrote:

>
> See my other message... it looks like there may be no way around
> changing existing code (and we'll have to use quotes AND square braces
> together for it, it appears anyway).
>
> However, whatever we do we can't hide errors. The stuff below isn't
> helpful as the intent is not to intentionally get an exception, but to
> get UEL (or something) to complain when something isn't right and to do
> so in a way that is as easy to understand (and therefore fix) as possible.
>
> This error, for example, was not immediately evident, not until I dug a
> bit. It would be great to do something about that...
>
> -David
>
>
> On Dec 15, 2008, at 2:35 PM, Adrian Crum wrote:
>
>> <field-to-list field-name="orderItemShipGrpInvResAndItemLocation"
>> list-name="oiirailByProdMap[orderItemShipGrpInvResAndItemLocation.productId]"/>
>>
>>
>> would be a better syntax. But that would mean the XML code would have
>> to be changed. I was trying to resolve this in a backwards-compatible
>> way.
>>
>> Keep in mind the exception could still get thrown even without the UEL:
>>
>> <set field="helloString" value="Hello World!"/>
>> <set field="invalidType" value="2.0" type="Double"/>
>> <field-to-list field-name="helloString"
>> list-name="invalidType"/>
>>
>> -Adrian
>>
>>
>> David E Jones wrote:
>>> But in this case it's not missing... there is actually a Map member
>>> (that is a List object) with the key "GZ-2644" and the simple-method
>>> code is try to access it, so we can't just treat it as missing when
>>> it comes back as the wrong type...
>>> In this case, and in many cases where the FlexibleStringExpander and
>>> FlexibleMapAccessor are used we are just trying to get the name of a
>>> "variable" (a Map member really), and we really don't need (or
>>> want... I don't think...) arithmetic operations. Is there any way to
>>> turn those off?
>>> -David
>>> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>>>> The code already expects the possibility that the object doesn't
>>>> exist and creates a new one if it's missing. The try-catch block
>>>> just treats an invalid object type as a missing object and then
>>>> everything runs the same as always.
>>>>
>>>> -Adrian
>>>>
>>>> David E Jones wrote:
>>>>> How exactly would that fix the problem? Wouldn't it just make the
>>>>> code fail, but fail with less noise... and possibly fail without
>>>>> any notice at all, leading to incorrect results that the system
>>>>> treats as correct.
>>>>> In this case, we need the "GZ-2644" interpreted as a map key rather
>>>>> than as a minus operator in the middle of an expression... and
>>>>> unless there's something amazing going on here that I'm totally
>>>>> missing (which I acknowledge is possible), I don't think ignoring
>>>>> the type cast exception would help...
>>>>> -David
>>>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>> To reproduce, from latest OFBiz revision and fresh database with it:
>>>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10
>>>>>>> (anything more than 5) of product "GZ-2644"; this will cause an
>>>>>>> inventory reservation against a bulk facility location, therefore
>>>>>>> needing a stock move before picking the order
>>>>>>> 2. place another order for "GZ-2644" so that there are at least 2
>>>>>>> reservations against the bulk location
>>>>>>> 3. go to the Facility -> Stock Moves tab for the facility
>>>>>>> WebStoreWarehouse
>>>>>>> (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse)
>>>>>>> When the page renders you'll get an error, the main exception is
>>>>>>> (just first couple of lines):
>>>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1) [      
>>>>>>> SimpleMethod.java:926:ERROR]
>>>>>>> ---- runtime exception report
>>>>>>> --------------------------------------------------
>>>>>>> Error in simple-method operation [<field-to-list
>>>>>>> list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>>>> field-name="orderItemShipGrpInvResAndItemLocation"
>>>>>>> map-name=""/>]: java.lang.ClassCastException: java.lang.Long
>>>>>>> Exception: java.lang.ClassCastException
>>>>>>> Message: java.lang.Long
>>>>>>> ---- stack trace
>>>>>>> ---------------------------------------------------------------
>>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>>> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
>>>>>>>
>>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>>>> Somehow the expression
>>>>>>> "${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>>>> is evaluation to "-2,644" as evidenced by adding this log
>>>>>>> statement just before line the line 65 mentioned above:
>>>>>>> <log level="info"
>>>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=${orderItemShipGrpInvResAndItemLocation.productId}  
>>>>>>> oiirailByProdMap
>>>>>>> value=${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
>>>>>>> The log shows:
>>>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1) [                
>>>>>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>>> oiirailByProdMap value=
>>>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1) [                
>>>>>>> Log.java:110:INFO ] [StockMoveServices.xml#findStockMovesNeeded]
>>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>>> oiirailByProdMap value=-2,644
>>>>>>> In other words, on the second line you can see where the
>>>>>>> expression that should return a List object instead returns a
>>>>>>> Long object with the value of "-2,644" which appears to be the
>>>>>>> productId GZ-2644 parsed as an integer...
>>>>>>> Any ideas as to how this might be happening? I suspect it is an
>>>>>>> issue with the UEL stuff Adrian recently added, since this was
>>>>>>> working just a few days ago.
>>>>>>> I'm guessing this is happening in other places too...
>>>>>>> -David
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

David E Jones-3

Do you mean as an alternative to the ClassCastException? I don't think  
that would help a lot, since that is just what a ClassCastException  
means.

I was thinking more of errors in UEL, like an attempt to perform an  
arithmetic operation on a non-numeric class (namely a List object), or  
errors like that which are more closely related to the cause of the  
problem rather than just a symptom of the actual cause that happens  
later on (which is what the ClassCastException is).

-David


On Dec 15, 2008, at 3:15 PM, Adrian Crum wrote:

> I could add a log message to the catch block: "Expected some type,  
> got some other type..."
>
> -Adrian
>
> David E Jones wrote:
>> See my other message... it looks like there may be no way around  
>> changing existing code (and we'll have to use quotes AND square  
>> braces together for it, it appears anyway).
>> However, whatever we do we can't hide errors. The stuff below isn't  
>> helpful as the intent is not to intentionally get an exception, but  
>> to get UEL (or something) to complain when something isn't right  
>> and to do so in a way that is as easy to understand (and therefore  
>> fix) as possible.
>> This error, for example, was not immediately evident, not until I  
>> dug a bit. It would be great to do something about that...
>> -David
>> On Dec 15, 2008, at 2:35 PM, Adrian Crum wrote:
>>> <field-to-list field-name="orderItemShipGrpInvResAndItemLocation"
>>> list-
>>> name
>>> =
>>> "oiirailByProdMap
>>> [orderItemShipGrpInvResAndItemLocation.productId]"/>
>>>
>>> would be a better syntax. But that would mean the XML code would  
>>> have to be changed. I was trying to resolve this in a backwards-
>>> compatible way.
>>>
>>> Keep in mind the exception could still get thrown even without the  
>>> UEL:
>>>
>>> <set field="helloString" value="Hello World!"/>
>>> <set field="invalidType" value="2.0" type="Double"/>
>>> <field-to-list field-name="helloString"
>>> list-name="invalidType"/>
>>>
>>> -Adrian
>>>
>>>
>>> David E Jones wrote:
>>>> But in this case it's not missing... there is actually a Map  
>>>> member (that is a List object) with the key "GZ-2644" and the  
>>>> simple-method code is try to access it, so we can't just treat it  
>>>> as missing when it comes back as the wrong type...
>>>> In this case, and in many cases where the FlexibleStringExpander  
>>>> and FlexibleMapAccessor are used we are just trying to get the  
>>>> name of a "variable" (a Map member really), and we really don't  
>>>> need (or want... I don't think...) arithmetic operations. Is  
>>>> there any way to turn those off?
>>>> -David
>>>> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>>>>> The code already expects the possibility that the object doesn't  
>>>>> exist and creates a new one if it's missing. The try-catch block  
>>>>> just treats an invalid object type as a missing object and then  
>>>>> everything runs the same as always.
>>>>>
>>>>> -Adrian
>>>>>
>>>>> David E Jones wrote:
>>>>>> How exactly would that fix the problem? Wouldn't it just make  
>>>>>> the code fail, but fail with less noise... and possibly fail  
>>>>>> without any notice at all, leading to incorrect results that  
>>>>>> the system treats as correct.
>>>>>> In this case, we need the "GZ-2644" interpreted as a map key  
>>>>>> rather than as a minus operator in the middle of an  
>>>>>> expression... and unless there's something amazing going on  
>>>>>> here that I'm totally missing (which I acknowledge is  
>>>>>> possible), I don't think ignoring the type cast exception would  
>>>>>> help...
>>>>>> -David
>>>>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>> David E Jones wrote:
>>>>>>>> To reproduce, from latest OFBiz revision and fresh database  
>>>>>>>> with it:
>>>>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10  
>>>>>>>> (anything more than 5) of product "GZ-2644"; this will cause  
>>>>>>>> an inventory reservation against a bulk facility location,  
>>>>>>>> therefore needing a stock move before picking the order
>>>>>>>> 2. place another order for "GZ-2644" so that there are at  
>>>>>>>> least 2 reservations against the bulk location
>>>>>>>> 3. go to the Facility -> Stock Moves tab for the facility  
>>>>>>>> WebStoreWarehouse (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse 
>>>>>>>> ) When the page renders you'll get an error, the main  
>>>>>>>> exception is (just first couple of lines):
>>>>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1)  
>>>>>>>> [       SimpleMethod.java:926:ERROR]
>>>>>>>> ---- runtime exception report  
>>>>>>>> --------------------------------------------------
>>>>>>>> Error in simple-method operation [<field-to-list list-
>>>>>>>> name="oiirailByProdMap.$
>>>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" field-
>>>>>>>> name="orderItemShipGrpInvResAndItemLocation" map-name=""/>]:  
>>>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>>>> Exception: java.lang.ClassCastException
>>>>>>>> Message: java.lang.Long
>>>>>>>> ---- stack trace  
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>>>> org
>>>>>>>> .ofbiz
>>>>>>>> .minilang.method.envops.FieldToList.exec(FieldToList.java:79)
>>>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:
>>>>>>>> 921)
>>>>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>>>>> Somehow the expression "${oiirailByProdMap.$
>>>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}" is  
>>>>>>>> evaluation to "-2,644" as evidenced by adding this log  
>>>>>>>> statement just before line the line 65 mentioned above:
>>>>>>>> <log level="info"  
>>>>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=$
>>>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}  
>>>>>>>> oiirailByProdMap value=${oiirailByProdMap.$
>>>>>>>> {orderItemShipGrpInvResAndItemLocation.productId}"/> The log  
>>>>>>>> shows:
>>>>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1)  
>>>>>>>> [                Log.java:110:INFO ]  
>>>>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>>>> oiirailByProdMap value=
>>>>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1)  
>>>>>>>> [                Log.java:110:INFO ]  
>>>>>>>> [StockMoveServices.xml#findStockMovesNeeded]  
>>>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>>>> oiirailByProdMap value=-2,644
>>>>>>>> In other words, on the second line you can see where the  
>>>>>>>> expression that should return a List object instead returns a  
>>>>>>>> Long object with the value of "-2,644" which appears to be  
>>>>>>>> the productId GZ-2644 parsed as an integer...
>>>>>>>> Any ideas as to how this might be happening? I suspect it is  
>>>>>>>> an issue with the UEL stuff Adrian recently added, since this  
>>>>>>>> was working just a few days ago.
>>>>>>>> I'm guessing this is happening in other places too...
>>>>>>>> -David

Reply | Threaded
Open this post in threaded view
|

Re: Issue with expression evaluation (possibly UEL related?)

Adrian Crum
That would be great, but how will UEL know what object type we want?
There is a way to specify the desired class in JUEL, but the
mini-language and screen widget architecture doesn't support that. I
came up with an idea to add that support (based an Adam's replies), but
it won't be an immediate fix.

So, what should I do? Revert the UEL stuff until mini-language and
screen widgets can be redesigned to better support it, or commit the
try-catch blocks - which fixes the problem but isn't ideal?

-Adrian

David E Jones wrote:

>
> Do you mean as an alternative to the ClassCastException? I don't think
> that would help a lot, since that is just what a ClassCastException means.
>
> I was thinking more of errors in UEL, like an attempt to perform an
> arithmetic operation on a non-numeric class (namely a List object), or
> errors like that which are more closely related to the cause of the
> problem rather than just a symptom of the actual cause that happens
> later on (which is what the ClassCastException is).
>
> -David
>
>
> On Dec 15, 2008, at 3:15 PM, Adrian Crum wrote:
>
>> I could add a log message to the catch block: "Expected some type, got
>> some other type..."
>>
>> -Adrian
>>
>> David E Jones wrote:
>>> See my other message... it looks like there may be no way around
>>> changing existing code (and we'll have to use quotes AND square
>>> braces together for it, it appears anyway).
>>> However, whatever we do we can't hide errors. The stuff below isn't
>>> helpful as the intent is not to intentionally get an exception, but
>>> to get UEL (or something) to complain when something isn't right and
>>> to do so in a way that is as easy to understand (and therefore fix)
>>> as possible.
>>> This error, for example, was not immediately evident, not until I dug
>>> a bit. It would be great to do something about that...
>>> -David
>>> On Dec 15, 2008, at 2:35 PM, Adrian Crum wrote:
>>>> <field-to-list field-name="orderItemShipGrpInvResAndItemLocation"
>>>> list-name="oiirailByProdMap[orderItemShipGrpInvResAndItemLocation.productId]"/>
>>>>
>>>>
>>>> would be a better syntax. But that would mean the XML code would
>>>> have to be changed. I was trying to resolve this in a
>>>> backwards-compatible way.
>>>>
>>>> Keep in mind the exception could still get thrown even without the UEL:
>>>>
>>>> <set field="helloString" value="Hello World!"/>
>>>> <set field="invalidType" value="2.0" type="Double"/>
>>>> <field-to-list field-name="helloString"
>>>> list-name="invalidType"/>
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> David E Jones wrote:
>>>>> But in this case it's not missing... there is actually a Map member
>>>>> (that is a List object) with the key "GZ-2644" and the
>>>>> simple-method code is try to access it, so we can't just treat it
>>>>> as missing when it comes back as the wrong type...
>>>>> In this case, and in many cases where the FlexibleStringExpander
>>>>> and FlexibleMapAccessor are used we are just trying to get the name
>>>>> of a "variable" (a Map member really), and we really don't need (or
>>>>> want... I don't think...) arithmetic operations. Is there any way
>>>>> to turn those off?
>>>>> -David
>>>>> On Dec 15, 2008, at 2:07 PM, Adrian Crum wrote:
>>>>>> The code already expects the possibility that the object doesn't
>>>>>> exist and creates a new one if it's missing. The try-catch block
>>>>>> just treats an invalid object type as a missing object and then
>>>>>> everything runs the same as always.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>> David E Jones wrote:
>>>>>>> How exactly would that fix the problem? Wouldn't it just make the
>>>>>>> code fail, but fail with less noise... and possibly fail without
>>>>>>> any notice at all, leading to incorrect results that the system
>>>>>>> treats as correct.
>>>>>>> In this case, we need the "GZ-2644" interpreted as a map key
>>>>>>> rather than as a minus operator in the middle of an expression...
>>>>>>> and unless there's something amazing going on here that I'm
>>>>>>> totally missing (which I acknowledge is possible), I don't think
>>>>>>> ignoring the type cast exception would help...
>>>>>>> -David
>>>>>>> On Dec 15, 2008, at 1:10 PM, 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?
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>> David E Jones wrote:
>>>>>>>>> To reproduce, from latest OFBiz revision and fresh database
>>>>>>>>> with it:
>>>>>>>>> 1. in ecommerce (or Order Manager) place a sales order for 10
>>>>>>>>> (anything more than 5) of product "GZ-2644"; this will cause an
>>>>>>>>> inventory reservation against a bulk facility location,
>>>>>>>>> therefore needing a stock move before picking the order
>>>>>>>>> 2. place another order for "GZ-2644" so that there are at least
>>>>>>>>> 2 reservations against the bulk location
>>>>>>>>> 3. go to the Facility -> Stock Moves tab for the facility
>>>>>>>>> WebStoreWarehouse
>>>>>>>>> (https://localhost:8443/facility/control/PickMoveStock?facilityId=WebStoreWarehouse)
>>>>>>>>> When the page renders you'll get an error, the main exception
>>>>>>>>> is (just first couple of lines):
>>>>>>>>> 2008-12-15 02:12:58,331 (http-0.0.0.0-8443-1) [      
>>>>>>>>> SimpleMethod.java:926:ERROR]
>>>>>>>>> ---- runtime exception report
>>>>>>>>> --------------------------------------------------
>>>>>>>>> Error in simple-method operation [<field-to-list
>>>>>>>>> list-name="oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>>>>>> field-name="orderItemShipGrpInvResAndItemLocation"
>>>>>>>>> map-name=""/>]: java.lang.ClassCastException: java.lang.Long
>>>>>>>>> Exception: java.lang.ClassCastException
>>>>>>>>> Message: java.lang.Long
>>>>>>>>> ---- stack trace
>>>>>>>>> ---------------------------------------------------------------
>>>>>>>>> java.lang.ClassCastException: java.lang.Long
>>>>>>>>> org.ofbiz.minilang.method.envops.FieldToList.exec(FieldToList.java:79)
>>>>>>>>>
>>>>>>>>> org.ofbiz.minilang.SimpleMethod.runSubOps(SimpleMethod.java:921)
>>>>>>>>> This is happening in the StockMoveServices.xml file on line 65.
>>>>>>>>> Somehow the expression
>>>>>>>>> "${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"
>>>>>>>>> is evaluation to "-2,644" as evidenced by adding this log
>>>>>>>>> statement just before line the line 65 mentioned above:
>>>>>>>>> <log level="info"
>>>>>>>>> message="orderItemShipGrpInvResAndItemLocation.productId=${orderItemShipGrpInvResAndItemLocation.productId}  
>>>>>>>>> oiirailByProdMap
>>>>>>>>> value=${oiirailByProdMap.${orderItemShipGrpInvResAndItemLocation.productId}"/>
>>>>>>>>> The log shows:
>>>>>>>>> 2008-12-15 02:18:46,896 (http-0.0.0.0-8443-1) [                
>>>>>>>>> Log.java:110:INFO ]
>>>>>>>>> [StockMoveServices.xml#findStockMovesNeeded]
>>>>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>>>>> oiirailByProdMap value=
>>>>>>>>> 2008-12-15 02:18:46,897 (http-0.0.0.0-8443-1) [                
>>>>>>>>> Log.java:110:INFO ]
>>>>>>>>> [StockMoveServices.xml#findStockMovesNeeded]
>>>>>>>>> orderItemShipGrpInvResAndItemLocation.productId=GZ-2644  
>>>>>>>>> oiirailByProdMap value=-2,644
>>>>>>>>> In other words, on the second line you can see where the
>>>>>>>>> expression that should return a List object instead returns a
>>>>>>>>> Long object with the value of "-2,644" which appears to be the
>>>>>>>>> productId GZ-2644 parsed as an integer...
>>>>>>>>> Any ideas as to how this might be happening? I suspect it is an
>>>>>>>>> issue with the UEL stuff Adrian recently added, since this was
>>>>>>>>> working just a few days ago.
>>>>>>>>> I'm guessing this is happening in other places too...
>>>>>>>>> -David
>
>