I was trying to figure out how to pass my own builder which will be
used to create an instance of OgnlContext which is kind of tricky
if everything is static :\
The only idea I came up was to use a static field used to assign my
custom builder, not really an elegant solution.
czw., 17 kwi 2025 o 0
Right now I stuck with migration as I'm getting class cast exceptions
when creating contexts using Ognl.createDefaultContext() - I assume it
can be related to "static" nature of the whole OGNL and maybe it won't
be possible to migrate the way I thought :\
I will try to dig a bit more, yet I'm cons
If we're confident that OGNL 3.5 is highly compatible then yeah I
think it should be fine. And it will need a stringent code review -
the draft PR already has a few snippets that make me wary such as
allowing the construction of OGNL contexts without injecting the
SecurityMemberAccess policy.
Ther
śr., 2 kwi 2025 o 02:12 Kusal Kithul-Godage
napisał(a):
> It seems the surface area of changes is large and has an API breaking
> impact on multiple extension points. I expect the OGNL upgrade itself
> could also cause breaking behavioural changes. If we're to abide by
> SemVer here, we should pro
Hi Lukasz,
Thank you for your work on this.
It seems the surface area of changes is large and has an API breaking
impact on multiple extension points. I expect the OGNL upgrade itself
could also cause breaking behavioural changes. If we're to abide by
SemVer here, we should probably release this
Hi,
I'm working on upgrading to the latest OGNL, I targeted 3.4.6 first,
but that won't work and I have started by introducing a more generic
OgnlContext in OGNL to support Struts requirements.
You can review this work here
https://github.com/apache/struts/pull/1249
Cheers
Łukasz
-
