-
Notifications
You must be signed in to change notification settings - Fork 510
java.lang.UnsupportedOperationException when struts2 is running in same app. #623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I found a solution for the issue, in the xwork-core library(XWorkObjectPropertyAccessor) they set some values in the context. ` public class XWorkObjectPropertyAccessor extends ObjectPropertyAccessor {
Then i modified the class OGNLVariableExpressionEvaluator(thymeleaf) in the method "evaluate" in the part: `
` Changing the immutable map with a HashMap the issue was solved for my particular case.
` |
Hmmm… I'm not sure this actually has a solution. The main problem here is that OGNL is not really prepared to have more than one tenant executing it in the same application, a large part of its configuration being made by means of static methods and so. So Struts2 and Thymeleaf making use of OGNL leads to a conflict here. I think we can perfectly call this an OGNL limitation. The conflict consists on Struts2 adding a I understand this might be of some use for Struts2, but it definitely is an unexpected and undesired side effect from the Thymeleaf standpoint. The problem is that in this case these constant, unmodifiable context maps you've changed code for are very used. Actually, they are used for most expressions in a template because most expressions do not make use of expression objects. So a lot of map instantiations are saved (note that this code is executed for every expression in every template). The problem with changing this to a |
I had not thought about the performance issue, what do you think of a wrapper for the immutable map that does not throw errors and does not allow adding new elements?
And then use it like this:
|
I've had a look at the Struts 2 code, and I'm afraid I think the solution you propose would not be adequate. First, because it would be quite intrusive, adding to the Thymeleaf core a feature that would be merely a workaround –not really a fix– for a specific scenario in Struts 2; and Second, because such workaround in itself would in fact provoke an unexpected behaviour by swallowing errors. I mean, this could be OK in a very specific OGNL evaluator created for a very specific scenario… but not at the default OGNL evaluator at the Thymeleaf core. So given that the Alternatively, and given this behaviour seems to only appear in Struts 2 when So I'm going to close this ticket as a declined feature, given there is a valid workaround for user applications/libraries (create a custom evaluator), and applying such workarounds to the Thymeleaf core would IMHO create more issues than it would solve. |
Hi , i met the same error, and patched by replace the singleton map with hashmap. here is the code, but it may be only for my small project. and it will be slow and high memory cost. public static IDialect getDialect() {
StandardDialect dialect = new StandardDialect();
try {
Class.forName("com.opensymphony.xwork2.ognl.accessor.ObjectAccessor") //check has struts
} catch (ClassNotFoundException e) {
return dialect;
}
try {//replace the singleton map with hashmap
Field field = OGNLVariableExpressionEvaluator.class.getDeclaredField("CONTEXT_VARIABLES_MAP_NOEXPOBJECTS_RESTRICTIONS");
field.setAccessible(true);
field.set(null, new HashMap<String, Object>())
} catch (Exception e) {
throw new RuntimeException("Thymleaf can't work with struts.", e)
}
OGNLVariableExpressionEvaluator evaluator = new OGNLVariableExpressionEvaluator(true);
dialect.setVariableExpressionEvaluator(new IStandardVariableExpressionEvaluator() {
Object evaluate(IExpressionContext context, IStandardVariableExpression expression, StandardExpressionExecutionContext expContext) {
expContext = StandardExpressionExecutionContext.RESTRICTED; //false, false -> true, false
return evaluator.evaluate(context, expression, expContext);
}
})
return dialect
} It's just a transitional patch, i will later replace all struts with thymleaf/SpringMVC. |
Hello,
I have a application with thymeleaf 2.1.4.RELEASE and while i was trying to update to the 3.0.6.RELEASE version i found an issue with ognl.
VARIABLE
`public class Boss {
}
`
TEMPLATE
<div>
<h1>Thymeleaf 3 + Strut 2 example</h1>
<p>
Hello <span th:text="${boss.name}">Boss</span>!!!
</p>
</div>
In the same app i have a dependency with Struts 2.
It looks like Struts is replacing ognl.ObjectMethodAccessor
with com.opensymphony.xwork2.ognl.accessor.XWorkMethodAccessor.
Is that an error o is it thymeleaf and Struts2 fully incompatibles?
NOTE: Without Struts2 it works as expected.
app-example.zip
The text was updated successfully, but these errors were encountered: