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