Constructor of OgnlContext with single Map Parameter throws Runtime Exception
escv opened this issue · comments
Hello OGNL Team,
the latest available ognl library from maven central 3.2.4 will always give a RuntimeException when instantiate OgnlContext will only a Map parameter.
In the source code i found that internally the constructor:
public OgnlContext(MemberAccess memberAccess, ClassResolver classResolver, TypeConverter typeConverter, Map values)
will be called with null values for not given params. This gives a
throw new RuntimeException("MemberAccess implementation must be provided!")
My used library(thymelead) calls this single param constructor and i needed to patch it manually. Is there a default implementation for MemberAccess?
Nope but see FAQ
Hello, Sorry for my last question which was a bit overhasty. I found this info in the FAQ now. However, could it make sense to use it part of the single arg constructor? Currently, the constructor is not usable - and the Default class is part of sc/test so i need to copy it manually. Developers migrating from version 3.2 will get runtime exceptions.
Greetings
What's wrong in providing your own default implementation? Most of the security breaches were because a hacker was able to use the provided default implementation. Also providing your own implementation increases security awareness and allows users control how the security is applied.
Providing a custom Implementation is a good issue. In my case, i used a 3rd Party Library (thymeleaf) invoking the single arg constructor causing an exception. As it is now marked as deprecated will help here, so that libraries taking care of that issue. Thanks
using SpringTemplateEngine replace TemplateEngine,will fixed it
Providing a custom Implementation is a good issue. In my case, i used a 3rd Party Library (thymeleaf) invoking the single arg constructor causing an exception. As it is now marked as deprecated will help here, so that libraries taking care of that issue. Thanks
Hi, @escv . We have stuck in the exact same problem with thymeleaf (seems to be dead for years).
haven't you by chance solved the problem?
Maybe just in case of backward compatibility it would be good to introduce a in-fly creating implementation, still have the constructor marked as deprecated but useable.