JUEL libraries are not TCK compliant

In order to improve the consumability and management of Shindig in enterprise deployments, Shindig Java components  should rely on Java Compatibility Kit (JCK) compliant libraries. 

It's come to our attention that JUEL libraries are not JCK compliant. Fortunately, Jasper is. However, there is a minor discrepancy between the library APIs. The newly created 2.0 stream affords an opportunity to become JCK compliant and adjust the code accordingly. 

The issue is org.apache.shindig.expressions.ShindigTypeConverter.java 
implements JUEL interface de.odysseus.el.misc.TypeConverter which is not provided by Jasper. Therefore in the process of switching from JUEL to Jasper, most of the negation test cases fail in these two functions in the ExpressionTest.java class
        public void booleanCoercionOfNumbers() and public void booleanCoercionOfString()

Here's the preliminary patch, any thought on where or how we can find a replacement equivalent to TypeConverter.java for use with jasper to get these testcases passing?

[Paul Lindner, 2010-06-01 17:56:27]

move library definitions to top level pom.xml

I don't know much about TypeConverter stuff.

Also some performance tests would be useful to insure that jasper isn't
significantly slower than juel.

[Han Nguyen, 2010-06-15 15:13:29]

On 2010/06/01 17:56:27, Paul Lindner wrote:
> move library definitions to top level pom.xml
> 
> I don't know much about TypeConverter stuff.
> 
> Also some performance tests would be useful to insure that jasper isn't
> significantly slower than juel.

Hi Paul,
Mark Nesbitt from my team has kindly created some quick unit tests to test out
jasper performance compared to juel.  We looped each of the expressions unit
tests 500,000 and measured the time (in milliseconds) it takes juel versus
modified el jasper code.  This is with default JUEL caching mechanism.  This is
probably pretty simplified testcase as we only use a couple of variables at most
and do repeated evaluations on that. - but so far a good sign as jasper is doing
well..  


DefaultTemplateProcessor tests -   10000 iterations
Test Name	                  Jasper with code changes	JUEL
testTextNode	                                    1678	2187
testTopVariable	                                    1360	1766
testCurVariable	                                    1343	1766
testMyVariable	                                    1328	1828
testPlainText	                                    1438	1859
testNodeEscaping	                            1375	1797
testAppending	                                    4109	5828
testEscapedExpressions	                            2766	3578
testElement	                                    1765	2422
testAttributeEscaping	                            1735	2203
testRepeat	                                    1890	2125
testRepeatScalar	                            1719	2047
testCurAttribute	                            1546	1985
testConditional	                                    1985	2500
testCustomTag	                                    2000	2141
testBooleanAttributes	                            1579	2062
testSafeCrossDomainDocumentCloning	            3671	4391
		



Expression Tests - 500,000 iterations
Test Name	                Jasper with code changes	JUEL
arraySupport 	                                    1172	3890
listSuport	                                     906	3360
mapSupport 	                                     797	2812
jsonObjectSupport	                             1343	2500
jsonArraySupport 	                             1110	4000
jsonArrayCoercionOfStatic	                     1187	1141
jsonArrayCoercion	                             1125	1719
missingJSONSubproperty	                             828	2531
missingMapSubproperty 	                             344	1687
booleanCoercionOfBooleans	                     1047	3985
BooleanCoercisionOfNull	                             469	1969
iterableCoercionOfScalar	                     312	1047
iterableCoercionOfNull	                             250	1000
iterableCoercionOfCollectionRun	                     453	1188
iterableCoercionOfJSONArray	                    1156	2453
iterableCoercionOfJSONObjectWithListProperty	    1532	3297
iterableCoercisionOfJSONObjectWithoutListProperty   1156	2313

[Paul Lindner, 2010-06-16 18:21:45]

numbers look good.

What happens when you deploy into a tomcat container older than 6.0.26?  Will
there be a conflict between the provided jasper and the one that's included
here?

[Paul Lindner, 2010-06-17 23:04:09]

also, to get this in you have to figure out some workaround for the
typeconverter code...

[awiner1, 2010-06-22 18:24:51]

I like the faster performance - though I strongly recommend checking out:

  http://code.google.com/p/caliper/wiki/JavaMicrobenchmarks

... before you take results from a looping test as gospel (Caliper has some
useful frameworks for gathering results).  (Also, consider upgrading to JUEL
2.2.1, which has fixes and may have performance improvements.)

The new dependency from DefaultTemplateProcessor to ShindigTypeConverter is ugly
and dangerous - all know-how of how to handle type coercion needs to stay in
org.apache.shindig.expressions (by a ValueExpression wrapper, if necessary), not
into other code.  Don't assume that all expression evaluation happens in
DefaultTemplateProcessor.

The critical thing is that Opensocial spec compliance is paramount, *not* TCK,
so commenting out existing tests is a blocker.

A major plus would be implementing this such that the choice of JUEL vs. Jasper
is a Guice binding - support *both*, and let downstream vendors choose when/if
to switch.  That shouldn't be that hard - and if we reach a point where Jasper
is clearly the right way to go, we can kill the JUEL support.  In particular, it
would let us do real-world testing of Jasper.  For example, it's possible that
Jasper uses less CPU but more memory than JUEL, and for some deployments that
may be a critical difference.

http://codereview.appspot.com/1376043/diff/1/4
File
java/common/src/main/java/org/apache/shindig/expressions/ShindigTypeConverter.java
(right):

http://codereview.appspot.com/1376043/diff/1/4#newcode54
java/common/src/main/java/org/apache/shindig/expressions/ShindigTypeConverter.java:54:
public static <T> T convert(Object obj, Class<T> type) throws ELException {
Making these functions static is bad - best practices in Guice land is to avoid
statics.  Note the @Inject above - you're breaking anyone that's chosen to
override the type converter.

If you need to call this code from somewhere that didn't need it before, the
proper fix is injecting an instance of this class into the target.

http://codereview.appspot.com/1376043/diff/1/5
File
java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java
(right):

http://codereview.appspot.com/1376043/diff/1/5#newcode134
java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java:134:
/*@Test
if you're going to suppress a test in JUnit 4, never comment it out.  Add the 
@Ignore annotation, and include a String explaining why the tests is ignored.

That said, these tests exist for a reason - they are required to comply with the
Opensocial specification.  Switching to a faster EL engine is a good thing, but
you can only do so if you can make these tests pass.  It's a non-starter if they
don't (or you have to suppress them).

http://codereview.appspot.com/1376043/diff/1/5#newcode223
java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java:223:
ValueExpression expr= null;
please avoid tabs in all Shindig code.

http://codereview.appspot.com/1376043/diff/1/8
File
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java
(right):

http://codereview.appspot.com/1376043/diff/1/8#newcode124
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:124:
resolver.setCtx(this.elContext);
Comments as to what this is for?  Why is the ELContext passed to the resolver
ever wrong?

http://codereview.appspot.com/1376043/diff/1/8#newcode487
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:487:
Object result = expr.getValue(elContext);
shindig code pretty uniformly uses { } around all branches

http://codereview.appspot.com/1376043/diff/1/8#newcode493
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:493:
return defaultValue;
call this function only once

http://codereview.appspot.com/1376043/diff/1/8#newcode494
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:494:
}
odd indents

http://codereview.appspot.com/1376043/diff/1/9
File
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java
(right):

http://codereview.appspot.com/1376043/diff/1/9#newcode57
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:57:
public void setCtx(ELContext ctx) {
Name this method setContext(), or setELContext();  eschew abbreviations.

That said: can you add Javadoc explaining the conditions under which you'd need
this, or why it's necessary below?  It's highly unusual to ignore the ELContext
passed to a function (and why only in some ELResolver APIs?).

http://codereview.appspot.com/1376043/diff/1/9#newcode58
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:58:
this.ctx = ctx;
odd indent here.

http://codereview.appspot.com/1376043/diff/1/9#newcode98
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:98:
context = ctx;
Add a comment explaining what's going on here.

[Han Nguyen, 2010-07-06 14:27:40]

Revised patch - Mark Nesbitt to add details soon after

[marknesb, 2010-07-06 14:47:17]

On 2010/07/06 14:27:40, Han Nguyen wrote:
> Revised patch - Mark Nesbitt to add details soon after

Overview of changes with this patch:

 1: Moved all conversion logic in unnecessary
locations(DefaultTemplateProcessor) and into Expressions.java.
Created new interfaces for ExpressionsProvider and ELTypeConverter  - and guice
modules and implementations for Juel (same version) and Jasper 6.0.2.26).
Default implementation is Juel  to stay consistent with past code.

2: Modified expression test cases to run both Juel and Jasper expression test
cases.  made minor changes to other  test cases to take advantage of the Juel
default.

3: Formatting corrected (hopefully).

4: Reworked the Jasper work around in the code and added comments.  Jasper-el
has a bug where it is not possible to access variable mapper from the context
passed in.  Will try to open an issue with jasper-el - but it will take time to
fix.  The work around does not cause any issues with Juel.  There might be a 
better way to do this work around and am open for suggestions.

5: Jasper still has an inability to do type conversions from numbers (and some
String issues) to booleans involving negation/and/or operations.  In the spec I
could only find one reference to an item where we have a failing test case  In
template section here:
"A Node, NodeList or non-empty string will evaluate to true'." -   Jasper has
issues with non-empty strings.

[Mark W., 2010-07-13 16:29:53]

I would like to add one thought to this reply, specifically around TCK
compliance.
> The critical thing is that Opensocial spec compliance is paramount, *not* TCK,
> so commenting out existing tests is a blocker.

On this point, I disagree. As OpenSocial evolves, and is used in more contexts,
specifically, in enterprise environments, compliance with standards becomes
paramount. Part of the reason for this is because the delivery model of the
software is different--customers are installing what you provide on site vs.
using a hosted/cloud based service. 

In many cases, what you deliver to customers MUST be compliant with the TCK.
This is a legal requirement, not a technical one. 

That said, I like the idea of making it easy to plug in Jasper for JUEL and
believe this is a good thing to do. Obviously, my concern would be for
inconsistent behavior between sites because some may use Jasper and other JUEL.
I would recommend that we establish a default position of being compliant with
the TCK.

Also, I think we should tighten up the language in spec so there is no
ambiguities in the behavior so that going forward, we can have a spec whose
implementation can be TCK compliant. 


On 2010/06/22 18:24:51, awiner1 wrote:
> I like the faster performance - though I strongly recommend checking out:
> 
>   http://code.google.com/p/caliper/wiki/JavaMicrobenchmarks
> 
> ... before you take results from a looping test as gospel (Caliper has some
> useful frameworks for gathering results).  (Also, consider upgrading to JUEL
> 2.2.1, which has fixes and may have performance improvements.)
> 
> The new dependency from DefaultTemplateProcessor to ShindigTypeConverter is
ugly
> and dangerous - all know-how of how to handle type coercion needs to stay in
> org.apache.shindig.expressions (by a ValueExpression wrapper, if necessary),
not
> into other code.  Don't assume that all expression evaluation happens in
> DefaultTemplateProcessor.
> 
> The critical thing is that Opensocial spec compliance is paramount, *not* TCK,
> so commenting out existing tests is a blocker.
> 
> A major plus would be implementing this such that the choice of JUEL vs.
Jasper
> is a Guice binding - support *both*, and let downstream vendors choose when/if
> to switch.  That shouldn't be that hard - and if we reach a point where Jasper
> is clearly the right way to go, we can kill the JUEL support.  In particular,
it
> would let us do real-world testing of Jasper.  For example, it's possible that
> Jasper uses less CPU but more memory than JUEL, and for some deployments that
> may be a critical difference.
> 
> http://codereview.appspot.com/1376043/diff/1/4
> File
>
java/common/src/main/java/org/apache/shindig/expressions/ShindigTypeConverter.java
> (right):
> 
> http://codereview.appspot.com/1376043/diff/1/4#newcode54
>
java/common/src/main/java/org/apache/shindig/expressions/ShindigTypeConverter.java:54:
> public static <T> T convert(Object obj, Class<T> type) throws ELException {
> Making these functions static is bad - best practices in Guice land is to
avoid
> statics.  Note the @Inject above - you're breaking anyone that's chosen to
> override the type converter.
> 
> If you need to call this code from somewhere that didn't need it before, the
> proper fix is injecting an instance of this class into the target.
> 
> http://codereview.appspot.com/1376043/diff/1/5
> File
> java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java
> (right):
> 
> http://codereview.appspot.com/1376043/diff/1/5#newcode134
>
java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java:134:
> /*@Test
> if you're going to suppress a test in JUnit 4, never comment it out.  Add the 
> @Ignore annotation, and include a String explaining why the tests is ignored.
> 
> That said, these tests exist for a reason - they are required to comply with
the
> Opensocial specification.  Switching to a faster EL engine is a good thing,
but
> you can only do so if you can make these tests pass.  It's a non-starter if
they
> don't (or you have to suppress them).
> 
> http://codereview.appspot.com/1376043/diff/1/5#newcode223
>
java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java:223:
> ValueExpression expr= null;
> please avoid tabs in all Shindig code.
> 
> http://codereview.appspot.com/1376043/diff/1/8
> File
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java
> (right):
> 
> http://codereview.appspot.com/1376043/diff/1/8#newcode124
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:124:
> resolver.setCtx(this.elContext);
> Comments as to what this is for?  Why is the ELContext passed to the resolver
> ever wrong?
> 
> http://codereview.appspot.com/1376043/diff/1/8#newcode487
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:487:
> Object result = expr.getValue(elContext);
> shindig code pretty uniformly uses { } around all branches
> 
> http://codereview.appspot.com/1376043/diff/1/8#newcode493
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:493:
> return defaultValue;
> call this function only once
> 
> http://codereview.appspot.com/1376043/diff/1/8#newcode494
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:494:
> }
> odd indents
> 
> http://codereview.appspot.com/1376043/diff/1/9
> File
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java
> (right):
> 
> http://codereview.appspot.com/1376043/diff/1/9#newcode57
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:57:
> public void setCtx(ELContext ctx) {
> Name this method setContext(), or setELContext();  eschew abbreviations.
> 
> That said: can you add Javadoc explaining the conditions under which you'd
need
> this, or why it's necessary below?  It's highly unusual to ignore the
ELContext
> passed to a function (and why only in some ELResolver APIs?).
> 
> http://codereview.appspot.com/1376043/diff/1/9#newcode58
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:58:
> this.ctx = ctx;
> odd indent here.
> 
> http://codereview.appspot.com/1376043/diff/1/9#newcode98
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:98:
> context = ctx;
> Add a comment explaining what's going on here.

[awiner1, 2010-07-13 16:54:48]

On Tue, Jul 13, 2010 at 9:29 AM, <weitzelm.ibm@gmail.com> wrote:

> I would like to add one thought to this reply, specifically around TCK
> compliance.
>
>> The critical thing is that Opensocial spec compliance is paramount,
>>
> *not* TCK,
>
>> so commenting out existing tests is a blocker.
>>
>
> On this point, I disagree. As OpenSocial evolves, and is used in more
> contexts, specifically, in enterprise environments, compliance with
> standards becomes paramount. Part of the reason for this is because the
> delivery model of the software is different--customers are installing
> what you provide on site vs. using a hosted/cloud based service.
>
> In many cases, what you deliver to customers MUST be compliant with the
> TCK. This is a legal requirement, not a technical one.
>

We're talking about two different things here.

It is really bad if installing Shindig in a J2EE environment replaces the
default EL implementation with one that is not TCK compliant, for standard
uses of javax.el in, say, JSP and JSF applications.

But it's irrelevant if the EL implementation used in
Shindig-as-an-OpenSocial-implementation is not TCK compliant;  the
compliance that matters there is OpenSocial compliance.  (OpenSocial is
silent on whether a Java implementation should use a javax.el implementation
at all;  that's only an implementation convenience in Shindig.  The use of
JSP EL as a baseline EL specification for OpenSocial was itself a
convenience, to let OpenSocial templating get out without designing an EL
from scratch, but the intention was never that OpenSocial use *exactly* JSP
EL.)

The challenge is getting those two requirements to coexist in a single
environment.  Removing META-INF/services/javax.el.ExpressionFactory from the
version of JUEL used by Shindig would probably be sufficient.  Poking enough
holes into Jasper to let Shindig use it in an OpenSocial-compliant way is
also fine.  Deciding that TCK compliance is more important than OpenSocial
compliance is not OK.

That said, I like the idea of making it easy to plug in Jasper for JUEL
> and believe this is a good thing to do. Obviously, my concern would be
> for inconsistent behavior between sites because some may use Jasper and
> other JUEL. I would recommend that we establish a default position of
> being compliant with the TCK.
>
> Also, I think we should tighten up the language in spec so there is no
> ambiguities in the behavior so that going forward, we can have a spec
> whose implementation can be TCK compliant.


Anything reducing ambiguity here would be a good thing.  But are some of the
issues instead specific differences between the OpenSocial and JavaEE
specifications, especially in the area of type conversion?


>
> On 2010/06/22 18:24:51, awiner1 wrote:
>
>> I like the faster performance - though I strongly recommend checking
>>
> out:
>
>    http://code.google.com/p/caliper/wiki/JavaMicrobenchmarks
>>
>
>  ... before you take results from a looping test as gospel (Caliper has
>>
> some
>
>> useful frameworks for gathering results).  (Also, consider upgrading
>>
> to JUEL
>
>> 2.2.1, which has fixes and may have performance improvements.)
>>
>
>  The new dependency from DefaultTemplateProcessor to
>>
> ShindigTypeConverter is ugly
>
>> and dangerous - all know-how of how to handle type coercion needs to
>>
> stay in
>
>> org.apache.shindig.expressions (by a ValueExpression wrapper, if
>>
> necessary), not
>
>> into other code.  Don't assume that all expression evaluation happens
>>
> in
>
>> DefaultTemplateProcessor.
>>
>
>  The critical thing is that Opensocial spec compliance is paramount,
>>
> *not* TCK,
>
>> so commenting out existing tests is a blocker.
>>
>
>  A major plus would be implementing this such that the choice of JUEL
>>
> vs. Jasper
>
>> is a Guice binding - support *both*, and let downstream vendors choose
>>
> when/if
>
>> to switch.  That shouldn't be that hard - and if we reach a point
>>
> where Jasper
>
>> is clearly the right way to go, we can kill the JUEL support.  In
>>
> particular, it
>
>> would let us do real-world testing of Jasper.  For example, it's
>>
> possible that
>
>> Jasper uses less CPU but more memory than JUEL, and for some
>>
> deployments that
>
>> may be a critical difference.
>>
>
>  http://codereview.appspot.com/1376043/diff/1/4
>> File
>>
>
>
>
java/common/src/main/java/org/apache/shindig/expressions/ShindigTypeConverter.java
>
>> (right):
>>
>
>  http://codereview.appspot.com/1376043/diff/1/4#newcode54
>>
>
>
>
java/common/src/main/java/org/apache/shindig/expressions/ShindigTypeConverter.java:54:
>
>> public static <T> T convert(Object obj, Class<T> type) throws
>>
> ELException {
>
>> Making these functions static is bad - best practices in Guice land is
>>
> to avoid
>
>> statics.  Note the @Inject above - you're breaking anyone that's
>>
> chosen to
>
>> override the type converter.
>>
>
>  If you need to call this code from somewhere that didn't need it
>>
> before, the
>
>> proper fix is injecting an instance of this class into the target.
>>
>
>  http://codereview.appspot.com/1376043/diff/1/5
>> File
>>
>
>
> java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java
>
>> (right):
>>
>
>  http://codereview.appspot.com/1376043/diff/1/5#newcode134
>>
>
>
>
java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java:134:
>
>> /*@Test
>> if you're going to suppress a test in JUnit 4, never comment it out.
>>
> Add the
>
>> @Ignore annotation, and include a String explaining why the tests is
>>
> ignored.
>
>  That said, these tests exist for a reason - they are required to
>>
> comply with the
>
>> Opensocial specification.  Switching to a faster EL engine is a good
>>
> thing, but
>
>> you can only do so if you can make these tests pass.  It's a
>>
> non-starter if they
>
>> don't (or you have to suppress them).
>>
>
>  http://codereview.appspot.com/1376043/diff/1/5#newcode223
>>
>
>
>
java/common/src/test/java/org/apache/shindig/expressions/ExpressionsTest.java:223:
>
>> ValueExpression expr= null;
>> please avoid tabs in all Shindig code.
>>
>
>  http://codereview.appspot.com/1376043/diff/1/8
>> File
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java
>
>> (right):
>>
>
>  http://codereview.appspot.com/1376043/diff/1/8#newcode124
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:124:
>
>> resolver.setCtx(this.elContext);
>> Comments as to what this is for?  Why is the ELContext passed to the
>>
> resolver
>
>> ever wrong?
>>
>
>  http://codereview.appspot.com/1376043/diff/1/8#newcode487
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:487:
>
>> Object result = expr.getValue(elContext);
>> shindig code pretty uniformly uses { } around all branches
>>
>
>  http://codereview.appspot.com/1376043/diff/1/8#newcode493
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:493:
>
>> return defaultValue;
>> call this function only once
>>
>
>  http://codereview.appspot.com/1376043/diff/1/8#newcode494
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java:494:
>
>> }
>> odd indents
>>
>
>  http://codereview.appspot.com/1376043/diff/1/9
>> File
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java
>
>> (right):
>>
>
>  http://codereview.appspot.com/1376043/diff/1/9#newcode57
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:57:
>
>> public void setCtx(ELContext ctx) {
>> Name this method setContext(), or setELContext();  eschew
>>
> abbreviations.
>
>  That said: can you add Javadoc explaining the conditions under which
>>
> you'd need
>
>> this, or why it's necessary below?  It's highly unusual to ignore the
>>
> ELContext
>
>> passed to a function (and why only in some ELResolver APIs?).
>>
>
>  http://codereview.appspot.com/1376043/diff/1/9#newcode58
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:58:
>
>> this.ctx = ctx;
>> odd indent here.
>>
>
>  http://codereview.appspot.com/1376043/diff/1/9#newcode98
>>
>
>
>
java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/TemplateELResolver.java:98:
>
>> context = ctx;
>> Add a comment explaining what's going on here.
>>
>
>
>
> http://codereview.appspot.com/1376043/show
>