Return-Path: 
 <issues-return-19758-apmail-commons-issues-archive=commons.apache.org@commons.apache.org>
X-Original-To: apmail-commons-issues-archive@minotaur.apache.org
Delivered-To: apmail-commons-issues-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 56B194FCD
	for <apmail-commons-issues-archive@minotaur.apache.org>;
 Sat,  9 Jul 2011 14:45:41 +0000 (UTC)
Received: (qmail 5336 invoked by uid 500); 9 Jul 2011 14:45:40 -0000
Delivered-To: apmail-commons-issues-archive@commons.apache.org
Received: (qmail 5152 invoked by uid 500); 9 Jul 2011 14:45:39 -0000
Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@commons.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@commons.apache.org>
List-Post: <mailto:issues@commons.apache.org>
List-Id: <issues.commons.apache.org>
Reply-To: issues@commons.apache.org
Delivered-To: mailing list issues@commons.apache.org
Received: (qmail 5144 invoked by uid 99); 9 Jul 2011 14:45:39 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Jul 2011 14:45:39 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Jul 2011 14:45:38 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id 9BEF84F8EA
	for <issues@commons.apache.org>; Sat,  9 Jul 2011 14:45:17 +0000 (UTC)
Date: Sat, 9 Jul 2011 14:45:17 +0000 (UTC)
From: "Henri Biestro (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <67663475.14180.1310222717635.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1034640519.23317.1308630107425.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (JEXL-113) Dot notation behaves unexpectedly
 with null values
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/JEXL-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: Set<List<String>> 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