Every attempt to replace OGNL by another EL library hits a big wall
because of the tight integration between xwork and OGNL. The biggest
problem comes from the "magical" instantiation of null objects in
expressions, and type conversion (applied together). This magic
instantiation is only used during parameter binding.
That being said, I am toying with a new implementation of the
parameter binding process, which does not use OGNL and is very simple.
It doesn't support any fancy expressions, besides nested and indexed
properties. The null handling (instantiation) and type conversion work
the same (existing classes are used). The advantages of using this
implementation are:
# decoupling. We don't depend on OGNL for parameter binding, so to
plugin in a new EL we just need to provide a new ValueStack (with its
helper classes) (then I can finally use my MVEL implementation..woot!)
# security. We don't need to worry about parameter names being
evaluated as evil expression ("System.exit(1)"="die die!")
# performance. Parameter binding will be faster (no big deal really)
I would say the main reason to do something like this, is that it give
us the possibility of getting rid of OGNL eventually, which is not
possible now, and as far as I know, OGNL is not maintained anymore.
thoughts?
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
