I'd like to propose that we disable this per default. Thomas, would you want a vote for this?
Thanks, Paul Nicolucci On Thu, Jan 5, 2023 at 3:07 AM Thomas Andraschko < [email protected]> wrote: > Good question. > In theory it was just a nice experimental feature but it works quite fine > in real world and with performance benefits. > > But its configurable via context param, we just need to decide whether its > enabled or disabled per default. > > Am Do., 5. Jan. 2023 um 04:19 Uhr schrieb Paul Nicolucci < > [email protected]>: > >> Hi, >> >> While looking over some code in MyFaces I noticed in Faces 4.0 we have the >> following ELResolver: >> https://github.com/apache/myfaces/blob/main/impl/src/main/java/org/apache/myfaces/el/resolver/LambdaBeanELResolver.java >> >> This resolver is added to the resolver list here: >> https://github.com/apache/myfaces/blob/main/impl/src/main/java/org/apache/myfaces/el/DefaultELResolverBuilder.java#L154 >> >> Reading over the specification: >> https://jakarta.ee/specifications/faces/4.0/jakarta-faces-4.0.html#a2966 I >> wanted to >> start a discussion on the following point in the specification: >> *"These actual ELResolver instances must be added. It is not compliant to >> simply add other resolvers that preserve these semantics."* >> >> Do we think we're still spec compliant by not directly adding >> *jakarta.el.BeanELResolver* and instead adding*LambdaBeanELResolver* which >> extends *jakarta.el.BeanELResolver*? >> >> Regards, >> >> Paul Nicolucci >> >>
