[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-07-11 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063263#comment-13063263
 ] 

Henri Biestro commented on JEXL-113:


The reason for the SetListString would be to track both 'dot' operators and 
'bracketed' expressions since they dont differ in evaluation. Every 'dot' expr 
can be rewritten as a 'bracketed' expr (not the opposite because of 
restrictions in allowed characters for identifiers).

Anyway, reusing your example:
a + b.c + d[e][f] would return { {a}, {b, c}, {d, e, f} }
However, a + b[func()] would only return { {a}, {b} }

Cheers,
Henri

 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-07-11 Thread Max Tardiveau (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063518#comment-13063518
 ] 

Max Tardiveau commented on JEXL-113:


Got it. That makes sense.

Thanks,


-- Max




 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-07-11 Thread Gary D. Gregory (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063529#comment-13063529
 ] 

Gary D. Gregory commented on JEXL-113:
--

Hi Max, can you ping me at ggreg...@apache.org? I think we've worked together 
before...

 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau
Assignee: Henri Biestro

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-07-10 Thread Max Tardiveau (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13062697#comment-13062697
 ] 

Max Tardiveau commented on JEXL-113:


That would be ideal! But I'm not sure I understand the return value. If my 
expression is:

a + b.c + d.e.f

I assume I'd get:

{ {a}, {b, c}, {d, e, f} }

I think a return type of SetString would be sufficient, since parsing dots 
should probably be left to the caller (since only they know what the dots 
mean). So I'd just get:

{ a, b.c, d.e.f }

which would be adequate. Either way would work, of course, I'm just trying to 
figure out what makes the most sense.

Thanks!

-- Max




 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-07-09 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13062391#comment-13062391
 ] 

Henri Biestro commented on JEXL-113:


Hi Max,
So, your functional need is extracting which variables are used to evaluate a 
script. I've had the same need for a while. 
So maybe an 'extractDependencies' method could be more useful than fumbling 
with the 'dot' operator behavior.
Its signature could be: SetListString JexlEngine.extractDependencies(Script 
script). Each entry in the returned set would be the list of constant 'names' 
used in references aka dot or bracket expressions.
Would this be adequate ?
Cheers
Henri
PS/ thanks for the positive reinforcement :-)

 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-07-07 Thread Max Tardiveau (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13061618#comment-13061618
 ] 

Max Tardiveau commented on JEXL-113:


Hi Henri,

thanks for following up on this. My personal preference would be for an option 
to select between 1, 2 and the current behavior, but I don't know if that's 
just me?

We have a workaround for now, but if we had this option, we could throw away 
the workaround, so it would be quite useful.

In case you're curious, we need to determine dependencies from an expression -- 
which objects and attributes are accessed in the expression. We currently 
evaluate the expression and we use a custom context object that returns special 
objects that keep track of what gets accessed. It's not horrible, but it is 
more complicated than I'd like it to be.

Allow me to reiterate that this is a *very* useful library, and that we very 
much appreciate it.

Thanks again,

-- Max




 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-07-06 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060990#comment-13060990
 ] 

Henri Biestro commented on JEXL-113:


Hi Max,
Not sure which way to go:
1/ allow an option to prevent the 'dot' operator: all variables are 'antish' 
and array access is needed to get to properties?
2/ allow an option to prevent the 'antish' variables; no variable can be 
'antish', the 'dot' operator always accesses a property?
3/ another solution would be to white-list classes / properties to restrict 
which ones can participate in the 'dot'/'array-reference' resolution
Any opinion, preferred choice ?
Cheers
Henrib


 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-06-23 Thread Max Tardiveau (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13053809#comment-13053809
 ] 

Max Tardiveau commented on JEXL-113:




Hi Henri,

we love Jexl! It's not uncommon for this type of library to be widely used, but 
very much under-recognized. Please know that we use it, and we like it.

After some more thinking about this, I can now see that handling null values is 
a challenge. 

Maybe we could have the option to turn off the dot operator? That would allow 
us to resolve the dot operator in our context class, and perhaps come up with a 
way to handle nulls (e.g. return zero instead of null). This can be done now 
with proxy classes, or by encapsulating beans, but that seems like a lot of 
work.

In the meantime, we're going to turn on silent mode, and let nulls be treated 
as they are now.

Thanks for a valuable library!

-- Max





 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly with null values

2011-06-21 Thread Henri Biestro (JIRA)

[ 
https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052561#comment-13052561
 ] 

Henri Biestro commented on JEXL-113:


Jexl since 1.0 has always been supporting ant-ish variable naming as well as 
the dot operator; it was thus important to continue supporting this feature 
(especially since the jexl user community is scattered and mostly silent :-( ). 
I doagree this behavior is anyway under-documented.

Note that variable resolution does not (should not) confuse the case if a 
conflict can occur; ant-ish variables are only tried if no bean exists during 
the dotted-path resolution.

I'll try adding a 'no-antish vars' flag to the interpreter if this accommodates 
your needs and allows regaining sanity. If you were to attach a (junit) test 
case checking for the desired behavior(s), it will definitely help speed up 
coming up with a proper solution.


 Dot notation behaves unexpectedly with null values
 --

 Key: JEXL-113
 URL: https://issues.apache.org/jira/browse/JEXL-113
 Project: Commons JEXL
  Issue Type: Bug
Affects Versions: 2.0.1
 Environment: JDK 1.6
Reporter: Max Tardiveau

 When a variable of the form a.b is evaluated, the context is asked first for 
 the value of a. That value is then asked for the value of b.
 So far, so good: this is exactly what you'd expect from the dot operator.
 But if the value of b is null, the context is then asked for the value of 
 a.b, in other words the dot operator is ignored and a.b is considered to be 
 a single variable.
 This is at best confusing. Granted, this can be avoided with the a['b'] 
 notation, but that's clumsy.
 I assume this is an attempt to support both the dot operator and ant-style 
 variables. I don't think you can have both and remain sane.
 Suggestion: either document this behavior, or make it an option. My vote 
 would be to just use the value returned, even if it's null. Either dot is an 
 operator, or it's not. Perhaps make that configurable?
 Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira