Bug 48813 - Allow the parameter org.apache.el.parser.COERCE_TO_ZERO to be set on runtime
Allow the parameter org.apache.el.parser.COERCE_TO_ZERO to be set on runtime
Status: RESOLVED WONTFIX
Product: Tomcat 6
Classification: Unclassified
Component: Jasper
6.0.24
PC All
: P2 enhancement with 4 votes (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2010-02-24 19:16 UTC by Ramiro Pereira de Magalhães
Modified: 2011-03-14 21:08 UTC (History)
2 users (show)



Attachments
Adds 2 new classes (ELParameters and CoerceToZeroConfigurer) in a new package (org.apache.el.parser.parameters) while modifying the AstValue class, composing a solution proposal to this issue. (2.82 KB, application/octet-stream)
2010-02-24 19:16 UTC, Ramiro Pereira de Magalhães
Details
Solves this issue and fixes the problem pointed by Konstantin. (4.39 KB, text/plain)
2010-02-27 16:45 UTC, Ramiro Pereira de Magalhães
Details
Making the coerceToZero field final, as proposed. (4.40 KB, patch)
2010-02-28 23:01 UTC, Ramiro Pereira de Magalhães
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ramiro Pereira de Magalhães 2010-02-24 19:16:08 UTC
Created attachment 25055 [details]
Adds 2 new classes (ELParameters and CoerceToZeroConfigurer) in a new package (org.apache.el.parser.parameters) while modifying the AstValue class, composing a solution proposal to this issue.

The parameter "org.apache.el.parser.COERCE_TO_ZERO" can only be used while starting up Tomcat or any other application that uses the Jasper Expression Language implementation. I think that one should be able to set such parameter on runtime, specially while an application is being loaded.

The attached patch implements the requested feature.
Comment 1 Ramiro Pereira de Magalhães 2010-02-24 19:18:22 UTC
Please, notice that the patch was made against the trunk, revision 915902.
Comment 2 Konstantin Kolinko 2010-02-25 08:23:18 UTC
ELParameters#coerceToZero in the proposed patch is a static field, and thus will be shared among web applications. Thus this implementation will work no better than the old one. No good.
Comment 3 Ramiro Pereira de Magalhães 2010-02-25 19:25:43 UTC
Well, that's absolutely true... and somewhat embarassing too. It is really important that each application is able to set such parameter for itself. Right now I can't figure out a way of doing that. I'm thinking about setting attributes on the ServletContext or using ThreadLocal variables with help of a ServletContextListener or a ServletRequestListener, but I'm still having trouble figuring out how to retrieve those values. Well, I guess I'll think about it and try something else later.
Comment 4 Ramiro Pereira de Magalhães 2010-02-27 16:45:32 UTC
Created attachment 25067 [details]
Solves this issue and fixes the problem pointed by Konstantin.

This patch implements the mentioned feature and allows different web applications to set particular values of the parameter for themselves.
Comment 5 Sebb 2010-02-28 13:54:39 UTC
The private boolean field coerceToZero could - and should - be made final.
Comment 6 Ramiro Pereira de Magalhães 2010-02-28 23:01:44 UTC
Created attachment 25069 [details]
Making the coerceToZero field final, as proposed.

I agree with Sebb.
Comment 7 Ramiro Pereira de Magalhães 2010-05-21 12:22:26 UTC
Hi,

since I posted the last version of the patch I've not seen mutch discussion about it. I'd really like to have this feature implemented on Tomcat's EL. Will you implement it? Is there something avoiding you from doing it that I could help?
Comment 8 Mark Thomas 2010-05-21 12:36:15 UTC
-1 to the patch as written since it creates a dependency on the Servlet API. The EL implementation should stand on its own.
Comment 9 Ramiro Pereira de Magalhães 2010-05-25 20:51:10 UTC
Hum... This is an important point. Let me think a bit about this and see if I can make some new proposal that removes such dependency that's worth the effort.
Comment 10 Ramiro Pereira de Magalhães 2011-03-14 21:08:10 UTC
I'd like to close this issue. I needed it to run Mojarra 1.2 but on version 2.1 they found an workaround to the problems I had. Also I wasn't able to solve the problem exposed by Mark Thomas.

Thank you for your attention.