[jira] [Created] (WW-5312) ExecuteAndWaitInterceptor inconsistent wait processing behaviour
James Chaplin created WW-5312: - Summary: ExecuteAndWaitInterceptor inconsistent wait processing behaviour Key: WW-5312 URL: https://issues.apache.org/jira/browse/WW-5312 Project: Struts 2 Issue Type: Bug Components: Core, Core Interceptors Affects Versions: 6.1.2 Environment: Java 8, Tomcat 8.5. The behaviour will likely be the same for other Java/Server combinations. Reporter: James Chaplin Fix For: 6.2.0 The _ExecuteAndWaitInterceptor_ processing appears to only execute as expected for the first run-through for any given session. This can be seen interactively using the Struts2 Showcase "_Execute and Wait Examples_", with the wait processing only functioning during the first attempt through each example in the same session. Clearing the session in the browser gives the expected wait behaviour again, but only one time (until clearing the session again). After debugging the _ExecuteAndWaitInterceptor_ flow, it appears that the removal from the _SessionMap_ did not perform as expected, resulting in a state divergence with the underlying session. A PR that attempts to fix the behaviour will be submitted soon. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (WW-5173) Implement additional OGNL cache configuration controls
[ https://issues.apache.org/jira/browse/WW-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Chaplin updated WW-5173: -- Attachment: S2_StarterApp_1.zip > Implement additional OGNL cache configuration controls > -- > > Key: WW-5173 > URL: https://issues.apache.org/jira/browse/WW-5173 > Project: Struts 2 > Issue Type: Improvement > Components: Core >Affects Versions: 6.0.0 >Reporter: James Chaplin >Priority: Minor > Fix For: 6.0.1 > > Attachments: S2_StarterApp_1.zip > > Time Spent: 50m > Remaining Estimate: 0h > > With Struts 2.6, there may be an opportunity to introduce some additional > OGNL cache configuration capabilities. One idea is to provide an cache size > control, and a toggle for an LRU cache mode. These configuration controls > could be applied to the expression cache and BeanInfo caches independently. > The new properties could be optional, with the framework using a standard > default cache if the properties are not provided. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WW-5173) Implement additional OGNL cache configuration controls
[
https://issues.apache.org/jira/browse/WW-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556560#comment-17556560
]
James Chaplin commented on WW-5173:
---
Hi [~lukaszlenart] and [~yasserzamani] .
Thanks for the feedback and suggestions.
I attempted to remove the default constructor, but that did not seem to help
(even after fixing the tests and calls that failed when the default constructor
was removed). A PR #573 was opened with some changes that at least got the
custom factory to be returned for _container.getInstance()_ .
Unfortunately, according to debugging, the default/bootstrap container
construction seems to only be able to utilize the default factory instances,
rather than the custom ones. It behaves as if the binding is "too early" to
allow for a custom implementation for the initial _OgnlUtil_ instances in
default/bootstrap containers. Maybe it requires a _ContainerProvider_ (similar
to {_}FileManagerFactoryProvider{_}) ? At this point I am thinking the
relationship between the _Ognl{+}Util{+}_ and _Container_ instances are somehow
different from a typical DI setup, but it is all guesses on my part (the DI has
subtleties that are beyond me so far).
Any other suggestions or recommendations are welcome. Thanks.
> Implement additional OGNL cache configuration controls
> --
>
> Key: WW-5173
> URL: https://issues.apache.org/jira/browse/WW-5173
> Project: Struts 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 6.0.0
>Reporter: James Chaplin
>Priority: Minor
>
> With Struts 2.6, there may be an opportunity to introduce some additional
> OGNL cache configuration capabilities. One idea is to provide an cache size
> control, and a toggle for an LRU cache mode. These configuration controls
> could be applied to the expression cache and BeanInfo caches independently.
> The new properties could be optional, with the framework using a standard
> default cache if the properties are not provided.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (WW-5173) Implement additional OGNL cache configuration controls
[
https://issues.apache.org/jira/browse/WW-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553175#comment-17553175
]
James Chaplin commented on WW-5173:
---
Hi [~yasserzamani] . Thanks for taking a look.
When I added code similar to the above to a test application, where I attempted
multiple different ways to register a custom {{ExpressionCacheFactory}} , the
result was always null (neither the custom bean, nor the default bean were
returned).
Prior to that, using interactive debugging of the same test application, at the
{{OgnlUtil}} construction the injected parameters were always null. More
recently, I noticed that only the default (no-parameter) constructor appears to
be being called, which accounts for the null parameters.
Based on the above, either I am not configuring the extension correctly, or the
extension point is not working as intended.
> Implement additional OGNL cache configuration controls
> --
>
> Key: WW-5173
> URL: https://issues.apache.org/jira/browse/WW-5173
> Project: Struts 2
> Issue Type: Improvement
> Components: Core
>Affects Versions: 6.0.0
>Reporter: James Chaplin
>Priority: Minor
>
> With Struts 2.6, there may be an opportunity to introduce some additional
> OGNL cache configuration capabilities. One idea is to provide an cache size
> control, and a toggle for an LRU cache mode. These configuration controls
> could be applied to the expression cache and BeanInfo caches independently.
> The new properties could be optional, with the framework using a standard
> default cache if the properties are not provided.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (WW-5173) Implement additional OGNL cache configuration controls
[ https://issues.apache.org/jira/browse/WW-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550254#comment-17550254 ] James Chaplin commented on WW-5173: --- Hi Struts Developers. An implementation for this item was provided in PR #528, for version 6.0.0 (a.k.a. 2.6). It appears that the default implementations are working, but the extension point (dependency-injection) may still not be functioning. While attempting to update some draft site documentation for the change, I was unable to get the extension point to work using a basic app (following the steps outlined in [https://struts.apache.org/plugins/plugins-architecture#extension-point-provided-by-the-core] ), with 6.0.0. It is possible that I am (still) not configuring things for the extension point(s) correctly, even after the guidance provided by [~lukaszlenart] . If anyone else can confirm that the extension point is working (or not), and the configuration steps used (if working), it would be appreciated. Regards, James. > Implement additional OGNL cache configuration controls > -- > > Key: WW-5173 > URL: https://issues.apache.org/jira/browse/WW-5173 > Project: Struts 2 > Issue Type: Improvement > Components: Core >Affects Versions: 6.0.0 >Reporter: James Chaplin >Priority: Minor > > With Struts 2.6, there may be an opportunity to introduce some additional > OGNL cache configuration capabilities. One idea is to provide an cache size > control, and a toggle for an LRU cache mode. These configuration controls > could be applied to the expression cache and BeanInfo caches independently. > The new properties could be optional, with the framework using a standard > default cache if the properties are not provided. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (WW-5173) Implement additional OGNL cache configuration controls
James Chaplin created WW-5173: - Summary: Implement additional OGNL cache configuration controls Key: WW-5173 URL: https://issues.apache.org/jira/browse/WW-5173 Project: Struts 2 Issue Type: Improvement Components: Core Affects Versions: 2.6 Reporter: James Chaplin With Struts 2.6, there may be an opportunity to introduce some additional OGNL cache configuration capabilities. One idea is to provide an cache size control, and a toggle for an LRU cache mode. These configuration controls could be applied to the expression cache and BeanInfo caches independently. The new properties could be optional, with the framework using a standard default cache if the properties are not provided. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (WW-5160) Template not found for name "Empty{name='templateDir'}/simple/hidden.ftl"
[
https://issues.apache.org/jira/browse/WW-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462990#comment-17462990
]
James Chaplin commented on WW-5160:
---
Hi [~lukaszlenart] .
After looking at the behaviour, using the reproducer (thanks for providing
that, [~Eduardo Quintanilla] ), it does not look like there is any simple way
to avoid the issue/collision when a _getParameters_ method exists in an action.
Maybe the tag model object should return to the top of the stack by default (as
it was prior to the behaviour change in 2.5.27), but there could be a global
opt-in configuration flag to allow a developer to have the action go to the top
of the stack ? Other than a global flag, maybe a new tag could be introduced
that could specify/control that stack ordering (for any tags declared within
its body) ?
(Those ideas are assuming that you think the WW-5117 fix behaviour should
remain at all, based on your comment above).
> Template not found for name "Empty{name='templateDir'}/simple/hidden.ftl"
> -
>
> Key: WW-5160
> URL: https://issues.apache.org/jira/browse/WW-5160
> Project: Struts 2
> Issue Type: Bug
>Affects Versions: 2.5.27, 2.5.28
> Environment: *Java:* 1.8.0_282
>
>Reporter: Eduardo Quintanilla
>Priority: Major
> Fix For: 2.6, 2.5.29
>
> Attachments: sample.zip, struts.log
>
>
> After updating from Struts 2.5.26 to 2.5.27 or 2.5.28 an exception happens of
> Template not found for name "Empty\{name='templateDir'}/simple/hidden.ftl"
>
> # Run sample
> # Navigate to /app-example/test.action
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (WW-5141) Support for JEE 9+
[ https://issues.apache.org/jira/browse/WW-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426476#comment-17426476 ] James Chaplin commented on WW-5141: --- Hi. There is definitely an interesting discussion on this topic. If refactoring servlet API dependencies into plugins is feasible to allow for running on both Java EE and Jakarta EE application servers, using a single code branch, then that might be the most elegant solution. Otherwise, another, less elegant option that might work, would be parallel branches (one targeting Java EE, another targeting Jakarta EE). > Support for JEE 9+ > --- > > Key: WW-5141 > URL: https://issues.apache.org/jira/browse/WW-5141 > Project: Struts 2 > Issue Type: New Feature > Components: Core >Reporter: Daniel Le Berre >Priority: Major > Fix For: 2.6 > > Attachments: pom.xml > > > JEE 9 breaks the JEE API by replacing javax domain by jakarta. > Tomcat 10 implements some specifications of JEE 9. > Struts 2.5 has some dependencies with the javax servlet API. > Struts would require some changes to run on Tomcat 10+. > Is there any plan to support JEE 9+ in the future? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5124) Tag attribute values cached
[
https://issues.apache.org/jira/browse/WW-5124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331324#comment-17331324
]
James Chaplin commented on WW-5124:
---
Hello [~dfliess] .
Thanks for reporting this issue, and providing a reproducer. :)
I was able to confirm the different behaviour, using your reproducer project on
Glassfish 5.0.1, when comparing the same on Tomcat 8.5.
I started working on a potential fix, but want to review it some more, before
potentially opening a PR.
> Tag attribute values cached
> ---
>
> Key: WW-5124
> URL: https://issues.apache.org/jira/browse/WW-5124
> Project: Struts 2
> Issue Type: Bug
> Environment: Here you have a repo that reproduce this:
> https://github.com/dfliess/struts2-tagpooling-bug
>Reporter: Diego Alejandro Fliess
>Priority: Major
> Fix For: 2.5.27, 2.6
>
>
> On some application servers, like glassfish, when handling jsp tag pooling,
> attribute values are cached or not reinitiallized.
> For example:
> {code:java}
>
> THIS TEXTFIELD SHOULD HAVE
> VALUE
> VALUE
>
>
> THIS TEXT FIELD SHOULDN'T HAVE
> VALUE
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-5117) %{id} evaluates different for data-* and value attribute
[
https://issues.apache.org/jira/browse/WW-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292556#comment-17292556
]
James Chaplin commented on WW-5117:
---
Hello.
After taking an initial look, I was unable to determine why the behaviour might
have changed since 2.5.20. Since both the hidden tag component and action in
this scenario have an "id" property, maybe the order or precedence of
processing changed in some way ?
There might be another workaround that does not involve introducing a var
alias/copy:
{noformat}
<%@ taglib prefix="s" uri="/struts-tags" %>
{noformat}
It seemed to work for me, but my local example might not match the reported
scenario exactly.
Since the "id" property name-clashes, if there is a way to avoid the name-clash
(with the s:set var workaround, or an alias getter in the action), that might
be a "safer" choice for an implementation.
> %{id} evaluates different for data-* and value attribute
>
>
> Key: WW-5117
> URL: https://issues.apache.org/jira/browse/WW-5117
> Project: Struts 2
> Issue Type: Bug
>Affects Versions: 2.5.26
>Reporter: Jonas Marczona
>Priority: Major
> Fix For: 2.5.27
>
>
> {{%\{id\}}} evaluates for "data-*" attributes in a different way than for the
> "value" attribute.
> in a very simple context where I have only one getter:
> {code}
> public Long getId() {
>return 27357L;
> }
> {code}
> The following two usages of "id" in one tag in a jsp evaluates in different
> ways:
> JSP:
> {noformat}
> <%@ taglib prefix="s" uri="/struts-tags"%>
>
>
> {noformat}
> Result:
> {noformat}
> data-wuffmiauww="einszwei">
>
> {noformat}
> I expect the Id of my getter - for both cases.
> The value for {{data-wuffmiauww}} is wrong.
> With struts2 version 2.5.20 the result was correct:
> {noformat}
> data-wuffmiauww="27357">
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (WW-5112) Add ability (control flag) for TextProviders to prioritize reads from the default resource bundlest.
James Chaplin created WW-5112: - Summary: Add ability (control flag) for TextProviders to prioritize reads from the default resource bundlest. Key: WW-5112 URL: https://issues.apache.org/jira/browse/WW-5112 Project: Struts 2 Issue Type: Improvement Components: Core Affects Versions: 2.6 Reporter: James Chaplin Fix For: 2.6 This proposed improvement derives from a discussion on the Struts Developer List, with the general idea introduced by Greg Huber. Improvement: Introduce a new STRUTS_I18N_SEARCH_DEFAULTBUNDLES_FIRST control flag constant, and accompanying logic, with the default setting being _false_. The new control flag will be used by AbstractLocalizedTextProvider descendants to identify alternative I18N resource bundle lookup logic that prioritizes key lookup in the default resource bundles (in cases where such a distinction makes sense). The StrutsLocalizedTextProvider will use the flag to determine whether searches for resources will check the default bundles first (if the flag is _true_) or last (if the flag is _false_) for a match to a lookup key. The GlobalLocalizedTextProvider only searches default bundles, so the flag will have no effect on it. The _false_ setting corresponds to the standard lookup logic for the TextProviders in Struts 2, and will be the default, so that there will be no impact to existing applications. Applications that wish to enable the alternate lookup will do so by setting the flag to _true_ in their Struts configuration. With a _true_ setting, if a key exists in a default resource bundle (such as the application's default resource bundle), it will supersede any such key in other bundles (such as ones at the package or class level). This will allow for a different resource bundle strategy when using the StrutsLocalizedTextProvider, and may be more efficient for applications that either only use a single global application resource bundle. or that use such a bundle for the vast majority of their I18N resource keys. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5110) java.lang.ClassCastException: org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter cannot be cast to jakarta.servlet.Filter
[
https://issues.apache.org/jira/browse/WW-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17257874#comment-17257874
]
James Chaplin commented on WW-5110:
---
Hi.
The failure appears to be due to Tomcat 10 implementing the Jakarta EE 9
specification. The Jakarta EE 9 specification is not namespace-compatible with
previous EE versions (JEE 8 or Jakarta EE 8), which can produce the sorts of
failures reported in this JIRA.
Attempting to support Jakarta EE 9+ directly would likely require a newly
refactored branch of Struts 2, and such a branch would no longer be compatible
with JEE 8 / Jakarta EE 8 or earlier web containers / application servers.
Assuming that, it would probably be something to consider for a future Struts 2
branch (may after 2.6 is released ?).
Until a (future) Jakarta EE 9+ version (branch) of Struts 2 is created,
developers can still use application servers / web containers that support
Jakarta EE 8 / JEE 8 or earlier. For Tomcat, that means running on Tomcat 9.x
or earlier.
Note: There appear to be a few tools for transforming existing (compiled) web
applications to move them to the new Jakarta EE 9 namespace (by modifying the
application's bytecode), but I do not think any of those tools are considered
"official" (meaning any developer using them would, presumably, be assuming any
risk that might be involved in their usage).
> java.lang.ClassCastException:
> org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter cannot be
> cast to jakarta.servlet.Filter
> -
>
> Key: WW-5110
> URL: https://issues.apache.org/jira/browse/WW-5110
> Project: Struts 2
> Issue Type: Bug
> Components: Integration
>Affects Versions: 2.5.26
>Reporter: Rsorrt
>Priority: Minor
> Fix For: 2.6
>
>
> *StrutsPrepareAndExecuteFilter is not compatible with jakarta servlet
> package*
> +in Web.xml+
> {quote}{{ }}
> {{ struts2 }}
>
> org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter
>
>
> }}
> struts2
> /*
>
> {quote}
>
> *starting TOMCAT 10.0.0:*
> {{{color:#ff}java.lang.ClassCastException:
> org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter cannot be
> cast to jakarta.servlet.Filter{color}}}
> {quote}27-Dec-2020 12:27:01.005 [main]
> org.apache.catalina.core.StandardContext.filterStart Exception starting
> filter [struts2]
> java.lang.ClassCastException:
> org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter cannot be
> cast to jakarta.servlet.Filter
> at
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:250)
> at
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:103)
> at
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4515)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5152)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:717)
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:706)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:631)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1830)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:526)
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:425)
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1576)
> at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:309)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
> at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:936)
> at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:843)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
> at
[jira] [Commented] (WW-5093) inconsistent scope for variables created with s:set and s:url
[
https://issues.apache.org/jira/browse/WW-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243676#comment-17243676
]
James Chaplin commented on WW-5093:
---
Hello [~lukaszlenart] .
Thanks for clarifying how the {{s:text}} {{var}} attribute can be retrieved
from the {{Request}} scope. :)
I had found the code where the text tag's {{var}} was pushed into the
{{Action}} scope, but had not thought to look for framework wrappers. The
information you provided makes the overall scenario make sense now.
> inconsistent scope for variables created with s:set and s:url
> -
>
> Key: WW-5093
> URL: https://issues.apache.org/jira/browse/WW-5093
> Project: Struts 2
> Issue Type: Bug
> Components: Core Tags
>Affects Versions: 2.5.22
>Reporter: nikos dimitrakas
>Priority: Major
> Labels: scope, tag, var
> Fix For: 2.6
>
>
> The implementation of s:set and s:url and s:text is not consistent and not
> well documented.
> Creating a variable with s:set puts the variable in a different default scope
> than creating a variable with s:url or s:text (with the attribute var). It is
> also not documented what the default scope is. After testing I could conclude
> that the scope for a variable created by s:url is request, while the default
> of s:set is not. Furthermore, s:set offers a possibility to specify the scope
> with an attribute, But s:url and s:text do not.
> Possible options would be offering the possibility to specify the scope
> attribute in s:url and s:text, or dropping support for the var attribute for
> s:url and s:text and only allow s:set to create variables (thus being forced
> to nest s:url and s:text inside an s:set). That would be symmetric with how
> s:property does not offer the var attribute. At minimum all three tags should
> have the same default and their default should be explicitly specified in the
> documentation (in the tld and the online manual / tag reference)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-5093) inconsistent scope for variables created with s:set and s:url
[
https://issues.apache.org/jira/browse/WW-5093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242028#comment-17242028
]
James Chaplin commented on WW-5093:
---
Hello.
I spent some time trying out some interactive examples based on [~nikos]'s
commentary, and tried to review some of the relevant code too.
Here is a summary of what I saw (using Struts 2.5.25) for a named var
attribute's result value using examples on a test JSP:
* s:text - The value is placed into Action scope and Request scope.
* s:url - The value is placed into Action scope and Request scope.
* s:set - The value is placed into the specified scope. If no scope is
provided, it defaults to Action scope. For scope Action, the value is +also+
placed into the Page scope.
The examples above use EL syntax on the JSP with the form ${var name}, which
can produce unexpected results when using the same var name in different tag
types on the JSP.
If we use s:property to retrieve a result (instead of EL), it should always use
the Action scope and provide consistent results, even when an s:iterator tag is
involved.
When a s:url and s:set (with no scope specified) tag both use the same var name
in an iterator, results are a bit weird with EL syntax ${var name}. The s:set
tag will set a reference at Page scope, which has precedence, so even if the
s:url tag is defined afterwards you will "see" the s:set tag's var result
(unless you specify scope in the EL as well, using ${requestScope.var name}).
Adding some additional information to the tag documentation might help clarify
how things behave (as was mentioned in the JIRA description).
It looks like there may one or two comment discrepancies in some of the
components, so a review of those to make sure they are accurate might be
helpful too.
As an aside, I could not track down the code for the s:text tag processing that
puts the var value into the Request scope, but interactive testing indicates it
does exist at that scope (when accessed by EL). If anyone can clarify how that
happens it would be appreciated.
> inconsistent scope for variables created with s:set and s:url
> -
>
> Key: WW-5093
> URL: https://issues.apache.org/jira/browse/WW-5093
> Project: Struts 2
> Issue Type: Bug
> Components: Core Tags
>Affects Versions: 2.5.22
>Reporter: nikos dimitrakas
>Priority: Major
> Labels: scope, tag, var
> Fix For: 2.6
>
>
> The implementation of s:set and s:url and s:text is not consistent and not
> well documented.
> Creating a variable with s:set puts the variable in a different default scope
> than creating a variable with s:url or s:text (with the attribute var). It is
> also not documented what the default scope is. After testing I could conclude
> that the scope for a variable created by s:url is request, while the default
> of s:set is not. Furthermore, s:set offers a possibility to specify the scope
> with an attribute, But s:url and s:text do not.
> Possible options would be offering the possibility to specify the scope
> attribute in s:url and s:text, or dropping support for the var attribute for
> s:url and s:text and only allow s:set to create variables (thus being forced
> to nest s:url and s:text inside an s:set). That would be symmetric with how
> s:property does not offer the var attribute. At minimum all three tags should
> have the same default and their default should be explicitly specified in the
> documentation (in the tld and the online manual / tag reference)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-414) multipart encoding bug...?
[
https://issues.apache.org/jira/browse/WW-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169306#comment-17169306
]
James Chaplin commented on WW-414:
--
Hello [~judypaul].
Since this is an old closed Struts issue, it may be that what you are
encountering is something different. Without more detail, it will be difficult
to provide any suggestions, either.
Please try posting your question to the Struts-User mailing list instead (see
[https://struts.apache.org/mail.html]). You will probably need to provide some
more information, such as the specific error(s) you are seeing in your logs
(and probably a portion of the Struts configuration being used as well).
Regards,
James.
> multipart encoding bug...?
> --
>
> Key: WW-414
> URL: https://issues.apache.org/jira/browse/WW-414
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
>Affects Versions: WW 2.0-beta2
>Reporter: Jonas Eriksson
>Priority: Major
> Fix For: WW 2.0
>
>
> Multipart encoding is hardcoded to utf-8 in PellMultiPartRequest. Can't be
> correct... but maybe it can be written over somewhere else?
> The following block is commented out in source. (setEncoding())
> ---
> /*
> String encoding = null;
> try {
> //encoding = Configuration.getString("webwork.i18n.encoding");
> if (encoding != null) {
> //NB: This should never be called at the same time as the
> constructor for
> //ServletMultiPartRequest, as it can cause problems.
> //See javadoc for MultipartRequest.setEncoding()
>
> http.utils.multipartrequest.MultipartRequest.setEncoding(encoding);
> }
>
> ---
> From email:
> Please submit a bug report and we'll get on it... You're probably the
> first one to stumble on it
> BTW, this stuff is exactly the same as in WW1.3 and 1.4, so we'll need
> to fix this there, too...
> Jason
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-5077) Unable to set long pathname variables
[
https://issues.apache.org/jira/browse/WW-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17155868#comment-17155868
]
James Chaplin commented on WW-5077:
---
Hello [~ghuber].
Thanks for reporting the issue that you are seeing with the log output.
You are seeing the new log entries (with _devMode_ true) when trying the Struts
2.5.23 test build, correct ?
The new log warnings you are seeing (with _devMode_ only) were intended to
advise more clearly when a given parameter is being rejected by the
_ParametersInterceptor_ (due to matching an exclusion pattern and/or not
matching any accepted pattern).
Maybe there needs to be an additional configuration flag that would allow these
new warnings with _devMode_ on to be suppressed (or set back to _++debug_ level
as they used to be) ?
If, after reviewing the log output, you determine those warnings are not
relevant information for your application, one thing you could try would be to
adjust the Log4j2 (or whichever logger you are using) logging level for the
_ParametersInterceptor_ to _error_. That should eliminate those _warn_ outputs
when _devMode_ is true.
Try adding something similar to the following to the section of
log4j2.xml for your application:
{code:java}
{code}
and see if that helps to suppress the warnings filling your logs with _devMode_
on.
Note: If you determine that your application actually _needs_ the rejected
parameters to be accepted, you _could_ try a custom acceptance pattern for the
_ParametersInterceptor_ (via "params.acceptParamNames"). +Use caution in
changing the default parameter acceptance patterns, as it can impact the safety
of the application+. From your logs above, that would mean a change to also
accept parameters with patterns like "(\:\w+\.\w+)|(\:\w+\!\w+)".
Please let us know if the above information (especially the logging level
setting) helps with the issue you reported (or not).
> Unable to set long pathname variables
> -
>
> Key: WW-5077
> URL: https://issues.apache.org/jira/browse/WW-5077
> Project: Struts 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.24
>Reporter: Stephan
>Priority: Major
> Fix For: 2.5.24, 2.6
>
> Attachments: Struts2Sample.zip, Struts2Sample2.zip
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
>
> I implemented a simple struts2+tiles (Struts 2 core version: 2.3.24.1) as a
> test case to verify an issue that have.
> In detail, i have the following Struts form:
> {code:java}
>
>
> value="Level-2_new" />
> name="metadataTest.metadataList[0].metadataList[0].name" value="Level-3_new"
> />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-4_new" />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-5_new" />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-6_new" />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-7_new" />
>
>
> {code}
> The metadataTest class:
> {code:java}
> public class Metadata implements Serializable {
> /** The Constant serialVersionUID. */
> private static final long serialVersionUID = 5902230367443812176L;
> private String name;
> private ArrayList metadataList;
> public Metadata() {
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> public ArrayList getMetadataList() {
> return metadataList;
> }
> public void setMetadataList(ArrayList metadataList) {
> this.metadataList = metadataList;
> }
> }
> {code}
> My issue here is following. When i submit this form, all values up to this
> level, are set correctly
> {code:java}
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-6_new" />
> {code}
> For some reason the below hidden element is never set, instead, the
> medataList at level 6 is null, while the name set by the hidden field above,
> is set correctly.
> {code:java}
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-7_new" />
> {code}
> Is there any kind of limitation by struts concerning the depth in a list
> hierarchie or maybe the length of path to set a value ? I could not find
> something related.
> *Note 1*: It surely has to do something with the length of the parameters.
> Once i changed the variable names to longer ones, i was able to set values
> only up to Level 3.
> *Note 2*:
[jira] [Commented] (WW-5075) Upgrade OSGi to the latest version
[
https://issues.apache.org/jira/browse/WW-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151745#comment-17151745
]
James Chaplin commented on WW-5075:
---
Hi.
There was a discussion on the topic, but no strong decision either way. Since
then, I have spent a fair amount of time trying to fix issues with the OSGi
plugin that appear (based on my testing) to have been happening since 2.3.x. I
believe that I have finally resolved the issues for 2.5.x (and 2.3.x), so after
cleaning up the code I will try to create a PR for 2.5.x (and a follow-up one
for 2.6.x).
Even if the OSGi plugin is deprecated or dropped later on, at least this way we
can have more up-to-date code in the repository first. :)
> Upgrade OSGi to the latest version
> --
>
> Key: WW-5075
> URL: https://issues.apache.org/jira/browse/WW-5075
> Project: Struts 2
> Issue Type: Dependency
> Components: Plugin - OSGi
>Reporter: Lukasz Lenart
>Priority: Major
> Fix For: 2.6
>
>
> Currently the OSGi plugin is using
> {code:xml}
>
> org.osgi
> org.osgi.core
> 4.3.1
>
> {code}
> but there is a new version 6.0.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-5075) Upgrade OSGi to the latest version
[
https://issues.apache.org/jira/browse/WW-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17141231#comment-17141231
]
James Chaplin commented on WW-5075:
---
Hello. I have been looking into this issue sporadically over the past few
weeks. Upgrading the libraries for Struts 2.6.x was straightforward, as was
some additional cleanup for the plugin. When I started manually testing the
plugin as part of a sample web project with the OSGi admin bundle, though, I
encountered issues that I was unable to resolve.
Trying manual tests with the latest Struts 2.5.x and 2.3.x releases produced
similar failures. I had to go back as far as version 2.3.3 before I could get
a combination that still worked. My plan is to start working forward through
the 2.3.x series to see if I can resolve the issues that arise (so far I have
been able to get things working with modified 2.3.4 and 2.3.5 versions).
Once enough additional progress has been made, or if I hit a roadblock, I will
provide an updated comment. If a solution is found, the hope is to generate
PRs for 2.6.x and 2.5.x.
> Upgrade OSGi to the latest version
> --
>
> Key: WW-5075
> URL: https://issues.apache.org/jira/browse/WW-5075
> Project: Struts 2
> Issue Type: Dependency
> Components: Plugin - OSGi
>Reporter: Lukasz Lenart
>Priority: Major
> Fix For: 2.6
>
>
> Currently the OSGi plugin is using
> {code:xml}
>
> org.osgi
> org.osgi.core
> 4.3.1
>
> {code}
> but there is a new version 6.0.0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-5079) Could not find StrutsPrepareAndExecuteFilter sometime in WAS server
[
https://issues.apache.org/jira/browse/WW-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120314#comment-17120314
]
James Chaplin commented on WW-5079:
---
Hello [~qman23].
Moving from Struts 2.3.35 to 2.5.22 in single release means multiple jars
changing, and the potential for different behaviour (compared to an upgrade
from 2.5.18 to 2.5.22, for instance). Since the error shows up after running
for a while, if you have any way of driving some load against your testing
environment instance (e.g. JMeter), you might want to do that to see if the
error can be made to occur in the testing environment.
The general symptom ("Could not find required filter class", presumably along
with a "java.lang.ClassNotFoundException") could mean an issue with the
application/server classloaders appearing after running for a while. You might
want to take a look at the classloader configuration for your application in
WAS, as well as any settings that might involve "dynamic reloading" of the
application.
With that in mind, some suggestions of things you could try if the error
persists:
+WebSphere Application Server+:
* Try configuring the application deployment in WAS with "Classes loaded with
local class loader first (parent last)".
* Try disabling hot deployment/dynamic reloading of the application, if it is
enabled in WAS.
+Struts+:
* Make sure you have devMode and dynamic reload options set as disabled
(false) in struts.xml for the build to your production system:
Please let us know if you have any success with downgrading to
javassist-3.25.0-GA.jar, trying some of the above configuration changes, or
something different you try on your own.
> Could not find StrutsPrepareAndExecuteFilter sometime in WAS server
> ---
>
> Key: WW-5079
> URL: https://issues.apache.org/jira/browse/WW-5079
> Project: Struts 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.22
> Environment: Please see our environment below:
> Application server: Websphere application server 8.5
> JDK version: 7.0
>Reporter: Lee
>Priority: Major
> Fix For: 2.6
>
> Attachments: dependency.png, err_log.txt
>
>
> We upgrade the Struts version to 2.5.22 recently.
> The new version working well in our testing enviroment. But after moved to
> production. After some time it's been used. The system throw out exception
> for 'Could not find required filter class -
> org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.class'.
> I used the minmal struts 2.5.22 jars download from Struts website, because of
> our security scan application notify that javassist-3.20.0-GA.jar is out of
> date, so i replace it to 3.26.0-GA. Could this issue related to this change?
> Thanks a lot.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-5079) Could not find StrutsPrepareAndExecuteFilter sometime in WAS server
[ https://issues.apache.org/jira/browse/WW-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17117396#comment-17117396 ] James Chaplin commented on WW-5079: --- Hello [~qman23] . The description states that you updated your project to Struts 2.5.22. +What version of Struts 2 were you using for the project before the upgrade+ (e.g. 2.3.37, 2.5.20) ? You indicated that you manually upgraded to javassist-3.26.0-GA.jar, and are running WAS on Java 7 ? It seems that +javassist-3.26.0-GA.jar (Javassist 3.26.0) is built for Java 8+ runtimes+, so that will probably result in failures if it gets called within a Java 7 Runtime. You +could try javassist-3.25.0-GA.jar (Javassist 3.25.0)+ as that seems to be +the most recent one built for Java 7+ runtimes+. I'm not sure if that will help or not, but it might be worth trying. As a last resort, after trying Javassist 3.25.0, you could try reverting back to Javassist 3.20.0 and see if that makes any difference. One last question. +Is there anything strange in your application's logs or the WAS logs that precedes the "Could not find required filter class" exception+ ? > Could not find StrutsPrepareAndExecuteFilter sometime in WAS server > --- > > Key: WW-5079 > URL: https://issues.apache.org/jira/browse/WW-5079 > Project: Struts 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.5.22 > Environment: Please see our environment below: > Application server: Websphere application server 8.5 > JDK version: 7.0 >Reporter: Lee >Priority: Major > Fix For: 2.6 > > Attachments: dependency.png, err_log.txt > > > We upgrade the Struts version to 2.5.22 recently. > The new version working well in our testing enviroment. But after moved to > production. After some time it's been used. The system throw out exception > for 'Could not find required filter class - > org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.class'. > I used the minmal struts 2.5.22 jars download from Struts website, because of > our security scan application notify that javassist-3.20.0-GA.jar is out of > date, so i replace it to 3.26.0-GA. Could this issue related to this change? > Thanks a lot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5077) Unable to set long pathname variables
[
https://issues.apache.org/jira/browse/WW-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17114920#comment-17114920
]
James Chaplin commented on WW-5077:
---
Hello.
Thanks, Stephan, for reporting the issue and providing both details and some
sample reproducer applications. (y)
Thanks, Lukasz, for identifying the cause, and creating a PR with improved
logging to assist developers in identifying when paramNameMaxLength is causing
a rejection of the parameter name. (y)
Even with the other safeguards against suspicious parameters, having a default
limit of 100 for parameter names is probably still reasonable.
I would vote to keep the limit in 2.6 (just add the improved logging in Lukasz'
PR), since a really long parameter name may be an indication of a bug in the
developer's application. The improved logging in Lukasz' PR makes it clear why
the rejection is happening, and developers can easily change the
paramNameMaxLength value via configuration if they need to support very long
parameter names.
> Unable to set long pathname variables
> -
>
> Key: WW-5077
> URL: https://issues.apache.org/jira/browse/WW-5077
> Project: Struts 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.24
>Reporter: Stephan
>Priority: Major
> Fix For: 2.5.23, 2.6
>
> Attachments: Struts2Sample.zip, Struts2Sample2.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
>
> I implemented a simple struts2+tiles (Struts 2 core version: 2.3.24.1) as a
> test case to verify an issue that have.
> In detail, i have the following Struts form:
> {code:java}
>
>
> value="Level-2_new" />
> name="metadataTest.metadataList[0].metadataList[0].name" value="Level-3_new"
> />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-4_new" />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-5_new" />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-6_new" />
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-7_new" />
>
>
> {code}
> The metadataTest class:
> {code:java}
> public class Metadata implements Serializable {
> /** The Constant serialVersionUID. */
> private static final long serialVersionUID = 5902230367443812176L;
> private String name;
> private ArrayList metadataList;
> public Metadata() {
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> public ArrayList getMetadataList() {
> return metadataList;
> }
> public void setMetadataList(ArrayList metadataList) {
> this.metadataList = metadataList;
> }
> }
> {code}
> My issue here is following. When i submit this form, all values up to this
> level, are set correctly
> {code:java}
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-6_new" />
> {code}
> For some reason the below hidden element is never set, instead, the
> medataList at level 6 is null, while the name set by the hidden field above,
> is set correctly.
> {code:java}
> name="metadataTest.metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].metadataList[0].name"
> value="Level-7_new" />
> {code}
> Is there any kind of limitation by struts concerning the depth in a list
> hierarchie or maybe the length of path to set a value ? I could not find
> something related.
> *Note 1*: It surely has to do something with the length of the parameters.
> Once i changed the variable names to longer ones, i was able to set values
> only up to Level 3.
> *Note 2*: Downgrading to Struts 2.1.6 resolves the issue. Also latest version
> 2.5.22 seems to be afffected from the exact same issue. Is there any
> workaround ?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WW-5076) struts2 redirecting to https to http
[ https://issues.apache.org/jira/browse/WW-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110557#comment-17110557 ] James Chaplin commented on WW-5076: --- Hello Manikanta. Could you please provide the redirect action mapping configuration from your struts.xml file, to show how it is configured in your application ? Even better, if you could provide and attach a very small reproducer application (one simple action, one simple JSP) to this Jira, that shows the issue in action, that would help. It might just be a configuration issue, but we will need to see the relevant section of the struts.xml configuration to get a better idea. Thanks, James. > struts2 redirecting to https to http > > > Key: WW-5076 > URL: https://issues.apache.org/jira/browse/WW-5076 > Project: Struts 2 > Issue Type: Bug > Components: Core >Affects Versions: 2.3.32 >Reporter: Manikanta Maddukuri >Priority: Blocker > > I deployed struts2 application and mapped a domain name,ssl . I am sending > https request and wherever i used struts2 redirection mapping, strut2 is > sending http redirect url instead of https redirect url. > > In result chrome is cancelling the http request. > > Error from chrome console: > Mixed Content: The page at 'https://.' was loaded over HTTPS, but > requested an insecure form action 'http://...'. This request has been > blocked; the content must be served over HTTPS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (WW-5074) Multiple ASM jar conflict in 2.6 build
James Chaplin created WW-5074:
-
Summary: Multiple ASM jar conflict in 2.6 build
Key: WW-5074
URL: https://issues.apache.org/jira/browse/WW-5074
Project: Struts 2
Issue Type: Bug
Components: Core
Affects Versions: 2.6
Environment: Any.
Reporter: James Chaplin
Fix For: 2.6
Hello Apache Struts Team.
During local testing of the 2.6 Showcase applications, some weird errors were
seen on the application server console logs. After some digging it was
determined to be the result of more than one ASM version jar being present in
the 2.6 build libraries, and carried into the Showcase applications.
I am guessing this probably came about as a side-effect of WW-5047 or WW-5068,
but did not confirm that for certain. The 2.6 build ends up with both ASM 7.x
and 3.x jars present, which causes sporadic issues during runtime for both
Showcase applications (builds fine).
A review of the Maven dependency tree shows multiple occurrences of:
{code:java}
| \- org.apache.struts:struts2-velocity-plugin:jar:2.6-SNAPSHOT:compile
| +- org.apache.velocity:velocity-engine-core:jar:2.2:compile
| +- org.apache.velocity.tools:velocity-tools-view:jar:3.0:compile
| | +- org.apache.velocity.tools:velocity-tools-generic:jar:3.0:compile
| | | +- commons-beanutils:commons-beanutils:jar:1.9.4:compile
| | | | \- commons-collections:commons-collections:jar:3.2.2:compile
| | | \- com.github.cliftonlabs:json-simple:jar:3.0.2:compile
| | \- org.apache.commons:commons-digester3:jar:3.2:compile
| | \- cglib:cglib:jar:2.2.2:compile
| |\- asm:asm:jar:3.3.1:compile
| \- org.apache.velocity.tools:velocity-tools-view-jsp:jar:3.0:compile
{code}
which seems to indicate ASM 3.3.1 is included due to
velocity-tools-view/commons-digester3/cglib dependencies.
This issue +does not impact the 2.5.x builds+ (2.5.22 or 2.5.23-SNAPSHOT),
+only the 2.6 build+.
After some trial-and-error it looks like a workaround limited to modification
of 2 POMs in the project resolves the issue. A PR with a proposed fix to do
this will follow shortly.
Removing the ASM 3.3.1 jar manually also works, but it would be better to avoid
the issue at build time if possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (WW-5072) Minor bug in single file upload example of the Showcase application
James Chaplin created WW-5072: - Summary: Minor bug in single file upload example of the Showcase application Key: WW-5072 URL: https://issues.apache.org/jira/browse/WW-5072 Project: Struts 2 Issue Type: Bug Components: Example Applications Affects Versions: 2.5.22 Environment: All Reporter: James Chaplin Fix For: 2.5.23, 2.6 A broader range of default excluded packages introduced with the previous Struts 2 release produces a failure for the single file upload example of the Showcase application. The issue was discovered by Lukasz Lenart during work on the 2.6 release. It appears to be possible to fix this without adjusting the excluded packages. A PR to resolve this should be available soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5069) Improve build behaviour on JDK9+
[ https://issues.apache.org/jira/browse/WW-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087305#comment-17087305 ] James Chaplin commented on WW-5069: --- Hello. A proposed PR has been created to address the unit test issue with JDK11 (presumed same for JDK9+) when building on Windows 10. This issue could affect other environments using non-US locales as well. *Note*: Struts 2 builds with JDK11 on Windows 10 appear to still fail due to an apache-rat-plugin failure. Applying "-Drat.skip=true" to the Maven build is a workaround to build with JDK11 (not needed for JDK7 or JDK8). > Improve build behaviour on JDK9+ > > > Key: WW-5069 > URL: https://issues.apache.org/jira/browse/WW-5069 > Project: Struts 2 > Issue Type: Improvement > Components: Build Management >Affects Versions: 2.5.22 > Environment: Windows 10, JDK 11 >Reporter: James Chaplin >Priority: Minor > Labels: build, pull-request-available > Fix For: 2.5.23, 2.6 > > > While performing builds of Struts2 Core on Windows 10 with JDK11, some > failures were encountered with unit tests. > This Jiira will track any fixes to improve the build behaviour for JDK9+, > where reasonable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (WW-5069) Improve build behaviour on JDK9+
James Chaplin created WW-5069: - Summary: Improve build behaviour on JDK9+ Key: WW-5069 URL: https://issues.apache.org/jira/browse/WW-5069 Project: Struts 2 Issue Type: Improvement Components: Build Management Affects Versions: 2.5.22 Environment: Windows 10, JDK 11 Reporter: James Chaplin Fix For: 2.5.23, 2.6 While performing builds of Struts2 Core on Windows 10 with JDK11, some failures were encountered with unit tests. This Jiira will track any fixes to improve the build behaviour for JDK9+, where reasonable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (WW-5068) Update multiple Struts 2.6.x libraries / Maven build plugin versions
[ https://issues.apache.org/jira/browse/WW-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Chaplin updated WW-5068: -- Description: Hello Apache Struts Team. This Jira is to track proposed introduction of newer (believed to be compatible) library versions for the Struts 2.6.x line, as well as newer (believed to be compatible) Maven build plugin versions for the build. Modifications to some pom.xml build files will be all that is required. As no code changes are involved, the risk should be pretty low and if back-levelling is required it can take place before 2.6.x is released. If any Maven build plugin version change presents an issue it can be easily reverted in the PR. The proposed list of library version updates is: -- cdi-api 1.0-SP4 -> 1.2 weld-core 1.0.1-SP4 -> 2.2.16.SP1 weld-se 1.0.1-Final -> weld-se-core 2.2.16.SP1 htmlunit 2.37.0 -> 2.39.0 slf4j-api 1.7.29 -> 1.7.30 slf4j-simple 1.7.29 -> 1.7.30 log4j2 2.12.1 - > 2.13.1 jackson 2.10.1 -> 2.10.3 ognl 3.2.12 -> 3.2.14 asm 7.2 -> 7.3.1 spring 4.3.25.RELEASE -> 4.3.26.RELEASE fluido-skin 1.8 -> 1.9 freemarker 2.3.28 -> 2.3.30 org.apache.felix.main 4.6.1 -> 6.0.3 velocity 2.1 -> 2.2 junit 4.12 -> 4.13 easymock 3.5.1 -> 4.2 javax.el 3.0.1-b10 -> 3.0.1-b11 jstl 1.1.2 -> 1.2 tomcat-jasper 8.5.37 -> 8.5.53 tomcat-api 8.5.37 -> 8.5.53 tomcat-juli 8.5.37 -> 8.5.53 commons-lang3 3.9 -> 3.10 assertj-core 2.9.1 -> 3.15.0 mockito-core 2.23.0 -> 3.3.3 testng 5.14.10 -> 7.1.0 juneau-marshall 7.2.2 -> 8.1.3 validation-api 1.1.0.Final -> 2.0.1.Final hibernate-validator 5.4.3.Final -> 6.1.2.Final jaxb-impl 2.3.1 -> 2.3.2 -- The proposed list of Maven plugin version updates is: -- maven-project-info-reports-plugin 2.7 -> 3.0.0 updateimpact-maven-plugin 1.0.10 -> 1.0.12 maven-surefire-plugin 2.22.2 -> 3.0.0-M4 jacoco-maven-plugin 0.8.4 - > 0.8.5 maven-war-plugin 3.2.2 -> 3.2.3 maven-bundle-plugin 3.5.0 -> 4.2.1 maven-dependency-plugin 3.1.1 -> 3.1.2 dependency-check-maven 5.2.4 -> 5.3.2 maven-enforcer-plugin 3.0.0-M2 -> 3.0.0-M3 maven-failsafe-plugin 2.22.2 -> 3.0.0-M4 maven-site-plugin 3.8.2 -> 3.9.0 doxia-core 1.9 -> 1.9.1 doxia-module-markdown 1.9 -> 1.9.1 -- A PR for this proposal should be available shortly for review. was: Hello Apache Struts Team. This Jira is to track proposed introduction of newer (believed to be compatible) library versions for the Struts 2.6.x line, as well as newer (believed to be compatible) Maven build plugin versions for the build. Modifications to some pom.xml build files will be all that is required. As no code changes are involved, the risk should be pretty low and if back-levelling is required it can take place before 2.6.x is released. If any Maven build plugin version change presents an issue it can be easily reverted in the PR. The proposed list of library version updates is: -- cdi-api 1.0-SP4 -> 1.2 weld-core 1.0.1-SP4 -> 2.2.16.SP1 weld-se 1.0.1-Final -> weld-se-core 2.2.16.SP1 htmlunit 2.37.0 -> 2.39.0 slf4j-api 1.7.28 -> 1.7.30 slf4j-simple 1.7.28 -> 1.7.30 jackson 2.10.0 -> 2.10.3 ognl 3.2.12 -> 3.2.14 asm 7.2 -> 7.3.1 spring 4.3.25.RELEASE -> 4.3.26.RELEASE fluido-skin 1.8 -> 1.9 freemarker 2.3.28 -> 2.3.30 org.apache.felix.main 4.6.1 -> 6.0.3 velocity 2.1 -> 2.2 junit 4.12 -> 4.13 easymock 3.5.1 -> 4.2 javax.el 3.0.1-b10 -> 3.0.1-b11 jstl 1.1.2 -> 1.2 tomcat-jasper 8.5.37 -> 8.5.53 tomcat-api 8.5.37 -> 8.5.53 tomcat-juli 8.5.37 -> 8.5.53 commons-lang3 3.9 -> 3.10 assertj-core 2.9.1 -> 3.15.0 mockito-core 2.23.0 -> 3.3.3 (required exclusion for objenesis) testng 5.14.10 -> 7.1.0 juneau-marshall 7.2.2 -> 8.1.3 validation-api 1.1.0.Final -> 2.0.1.Final hibernate-validator 5.4.3.Final -> 6.1.2.Final jaxb-impl 2.3.1 -> 2.3.2 -- The proposed list of Maven plugin version updates is: -- maven-project-info-reports-plugin 2.7 -> 3.0.0 updateimpact-maven-plugin 1.0.10 -> 1.0.12 maven-surefire-plugin 2.22.1 -> 3.0.0-M4 jacoco-maven-plugin 0.8.4 - > 0.8.5 maven-war-plugin 2.1 -> 3.2.3 maven-bundle-plugin 3.5.0 -> 4.2.1 maven-dependency-plugin 2.10 -> 3.1.2 dependency-check-maven 3.3.4 -> 5.3.2 maven-enforcer-plugin 3.0.0-M2 -> 3.0.0-M3 maven-failsafe-plugin 2.22.2 -> 3.0.0-M4 maven-site-plugin 3.8.2 -> 3.9.0 doxia-core 1.8 -> 1.9.1 doxia-module-markdown 1.7 -> 1.9.1 -- A PR for this proposal should be available shortly for review. > Update multiple Struts 2.6.x libraries / Maven build plugin versions > > > Key: WW-5068 > URL: https://issues.apache.org/jira/browse/WW-5068 > Project: Struts 2 > Issue Type: Dependency > Components: Build Management, Other >Affects Versions: 2.6 > Environment: All >Reporter: James Chaplin >Priority: Minor >
[jira] [Created] (WW-5068) Update multiple Struts 2.6.x libraries / Maven build plugin versions
James Chaplin created WW-5068: - Summary: Update multiple Struts 2.6.x libraries / Maven build plugin versions Key: WW-5068 URL: https://issues.apache.org/jira/browse/WW-5068 Project: Struts 2 Issue Type: Dependency Components: Build Management, Other Affects Versions: 2.6 Environment: All Reporter: James Chaplin Fix For: 2.6 Hello Apache Struts Team. This Jira is to track proposed introduction of newer (believed to be compatible) library versions for the Struts 2.6.x line, as well as newer (believed to be compatible) Maven build plugin versions for the build. Modifications to some pom.xml build files will be all that is required. As no code changes are involved, the risk should be pretty low and if back-levelling is required it can take place before 2.6.x is released. If any Maven build plugin version change presents an issue it can be easily reverted in the PR. The proposed list of library version updates is: -- cdi-api 1.0-SP4 -> 1.2 weld-core 1.0.1-SP4 -> 2.2.16.SP1 weld-se 1.0.1-Final -> weld-se-core 2.2.16.SP1 htmlunit 2.37.0 -> 2.39.0 slf4j-api 1.7.28 -> 1.7.30 slf4j-simple 1.7.28 -> 1.7.30 jackson 2.10.0 -> 2.10.3 ognl 3.2.12 -> 3.2.14 asm 7.2 -> 7.3.1 spring 4.3.25.RELEASE -> 4.3.26.RELEASE fluido-skin 1.8 -> 1.9 freemarker 2.3.28 -> 2.3.30 org.apache.felix.main 4.6.1 -> 6.0.3 velocity 2.1 -> 2.2 junit 4.12 -> 4.13 easymock 3.5.1 -> 4.2 javax.el 3.0.1-b10 -> 3.0.1-b11 jstl 1.1.2 -> 1.2 tomcat-jasper 8.5.37 -> 8.5.53 tomcat-api 8.5.37 -> 8.5.53 tomcat-juli 8.5.37 -> 8.5.53 commons-lang3 3.9 -> 3.10 assertj-core 2.9.1 -> 3.15.0 mockito-core 2.23.0 -> 3.3.3 (required exclusion for objenesis) testng 5.14.10 -> 7.1.0 juneau-marshall 7.2.2 -> 8.1.3 validation-api 1.1.0.Final -> 2.0.1.Final hibernate-validator 5.4.3.Final -> 6.1.2.Final jaxb-impl 2.3.1 -> 2.3.2 -- The proposed list of Maven plugin version updates is: -- maven-project-info-reports-plugin 2.7 -> 3.0.0 updateimpact-maven-plugin 1.0.10 -> 1.0.12 maven-surefire-plugin 2.22.1 -> 3.0.0-M4 jacoco-maven-plugin 0.8.4 - > 0.8.5 maven-war-plugin 2.1 -> 3.2.3 maven-bundle-plugin 3.5.0 -> 4.2.1 maven-dependency-plugin 2.10 -> 3.1.2 dependency-check-maven 3.3.4 -> 5.3.2 maven-enforcer-plugin 3.0.0-M2 -> 3.0.0-M3 maven-failsafe-plugin 2.22.2 -> 3.0.0-M4 maven-site-plugin 3.8.2 -> 3.9.0 doxia-core 1.8 -> 1.9.1 doxia-module-markdown 1.7 -> 1.9.1 -- A PR for this proposal should be available shortly for review. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (WW-5067) Update multiple Struts 2.5.x libraries / Maven build plugin versions
James Chaplin created WW-5067: - Summary: Update multiple Struts 2.5.x libraries / Maven build plugin versions Key: WW-5067 URL: https://issues.apache.org/jira/browse/WW-5067 Project: Struts 2 Issue Type: Dependency Components: Build Management, Other Affects Versions: 2.5.22 Environment: All Reporter: James Chaplin Fix For: 2.5.23 Hello Apache Struts Team. This Jira is to track proposed introduction of newer (believed to be compatible) library versions for the Struts 2.5.x line, as well as newer (believed to be compatible) Maven build plugin versions for the build. Modifications to some pom.xml build files will be all that is required. As no code changes are involved, the risk should be pretty low and end-users could manually back-level any problematic jars if issues arise. If any Maven build plugin version change presents an issue it can be easily reverted in the PR. The proposed list of library version updates is: -- * cdi-api 1.0-SP4 -> 1.2 * weld-core 1.0.1-SP4 -> 2.2.16.SP1 * weld-se 1.0.1-Final -> weld-se-core 2.2.16.SP1 * slf4j-api 1.7.28 -> 1.7.30 * slf4j-simple 1.7.28 -> 1.7.30 * jackson 2.10.0 -> 2.10.3 * ognl 3.1.26 -> 3.1.28 * asm 7.1 -> 7.3.1 * spring 4.3.25.RELEASE -> 4.3.26.RELEASE * freemarker 2.3.28 -> 2.3.30 * org.apache.felix.main 4.6.1 -> 6.0.3 -- The proposed list of Maven plugin version updates is: -- * doxia-core 1.8 -> 1.9.1 * doxia-module-markdown 1.7 -> 1.9.1 * maven-project-info-reports-plugin 2.7 -> 3.0.0 * updateimpact-maven-plugin 1.0.10 -> 1.0.12 * maven-surefire-plugin 2.22.1 -> 3.0.0-M4 * maven-war-plugin 2.1 -> 3.2.3 * maven-dependency-plugin 2.10 -> 3.1.2 * dependency-check-maven 3.3.4 -> 5.3.2 Note: Unable to upgrade maven-bundle-plugin past 2.1.0 as it introduced OOM during JDK7 builds with default heap settings. -- A PR for this proposal should be available shortly for review. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5030) ClassNotFoundException - MockPortletResponse
[ https://issues.apache.org/jira/browse/WW-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070378#comment-17070378 ] James Chaplin commented on WW-5030: --- Hi. Before considering a separate plugin, adding a refactored set of portlet mocks to the struts2-junit-plugin was (briefly) attempted. One drawback of that attempt was purely an increase in the size of the struts2-junit-plugin-xxx.jar (it essentially tripled in size). Since most users of the junit-plugin won't need or use those portlet mocks, moving them into a separate plugin seemed to make sense to avoid "extra baggage" for the junit-plugin. Placing the portlet mocks in a separate plugin should (in theory) help isolate changes in the future, keeping the vast majority of the portlet-related elements in the portlet-related plugins. It also decouples the mocks so they could be used without tying them to a particular test framework. The mocks package names were also refactored in the plugin to avoid potential classpath clashes with Spring 4.x (or older versions). A separate portlet-mocks plugin will mean some documentation changes for Struts 2.6.x, but at least they should be pretty straightforward (adding the struts2-portlet-mocks-plugin as a dependency for a build and search/replace the mock package names in projects). It is unlikely that a backport of a portlet-mocks plugin to 2.5.x would be undertaken, but it would be a consideration for migration to Struts 2.6.x. Regards, James. > ClassNotFoundException - MockPortletResponse > > > Key: WW-5030 > URL: https://issues.apache.org/jira/browse/WW-5030 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - Portlet >Affects Versions: 2.5.18 >Reporter: John Bush >Priority: Major > Fix For: 2.6 > > Attachments: TestStrutsPortlet.zip, fail.txt, success.txt > > > WW-3826 solved a problem running JUnit tests on portlet actions that use the > struts2-portlet-plugin and struts2-junit-plugin. The solution used Spring's > org.springframework.mock.web.portlet package in the spring-test framework. > Spring Portlet MVC is no longer supported (SPR-14129) and the package has > been removed starting with Spring 5. I'm not able to upgrade to Spring 5 > without loosing my unit testing since having both versions of spring-test in > my classpath creates many other issues. > I've attached a zipped portlet project for testing (TestStrutsPortlet.zip), > console log from a successful test (success.txt) and console log from a > failed test (fail.txt). All that needs to change is the spring-version in the > POM to recreate the testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (WW-5030) ClassNotFoundException - MockPortletResponse
[ https://issues.apache.org/jira/browse/WW-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070031#comment-17070031 ] James Chaplin edited comment on WW-5030 at 3/29/20, 2:44 PM: - Hello John. The intention was to consider a plugin which could enable continued usage of a subset of portlet-related mocks from spring-test (Spring 4.3.x). It was hoped it could provide the mock functionality without introducing a new dependency for Struts 2 on PortletMVC4Spring (simply for the mocks). It was just an initial attempt, and the choice of plugin name may not have been the best. ;) A refactored version, named portlet-mocks-plugin (as suggested by Lukasz - along with some other changes he also suggested), has been applied via updates to the PR. It should be a cleaner plugin implementation now at any rate. Regards, James. (*Edited*: Corrected reference to spring-webmvc-portlet above, as per John's comment below. There was a single mock related to this package, but it was not the principal package involved.) was (Author: jchaplin): Hello John. The intention was to consider a plugin which could enable continued usage of a subset of portlet-related mocks from spring-test (Spring 4.3.x). It was hoped it could provide the mock functionality without introducing a new dependency for Struts 2 on PortletMVC4Spring (simply for the mocks). It was just an initial attempt, and the choice of plugin name may not have been the best. ;) A refactored version, named portlet-mocks-plugin (as suggested by Lukasz - along with some other changes he also suggested), has been applied via updates to the PR. It should be a cleaner plugin implementation now at any rate. Regards, James. (*Edited*: Corrected incorrect reference to spring-webmvc-portlet above, as per John's comment below) > ClassNotFoundException - MockPortletResponse > > > Key: WW-5030 > URL: https://issues.apache.org/jira/browse/WW-5030 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - Portlet >Affects Versions: 2.5.18 >Reporter: John Bush >Priority: Major > Fix For: 2.6 > > Attachments: TestStrutsPortlet.zip, fail.txt, success.txt > > > WW-3826 solved a problem running JUnit tests on portlet actions that use the > struts2-portlet-plugin and struts2-junit-plugin. The solution used Spring's > org.springframework.mock.web.portlet package in the spring-test framework. > Spring Portlet MVC is no longer supported (SPR-14129) and the package has > been removed starting with Spring 5. I'm not able to upgrade to Spring 5 > without loosing my unit testing since having both versions of spring-test in > my classpath creates many other issues. > I've attached a zipped portlet project for testing (TestStrutsPortlet.zip), > console log from a successful test (success.txt) and console log from a > failed test (fail.txt). All that needs to change is the spring-version in the > POM to recreate the testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (WW-5030) ClassNotFoundException - MockPortletResponse
[ https://issues.apache.org/jira/browse/WW-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070031#comment-17070031 ] James Chaplin edited comment on WW-5030 at 3/29/20, 2:26 PM: - Hello John. The intention was to consider a plugin which could enable continued usage of a subset of portlet-related mocks from spring-test (Spring 4.3.x). It was hoped it could provide the mock functionality without introducing a new dependency for Struts 2 on PortletMVC4Spring (simply for the mocks). It was just an initial attempt, and the choice of plugin name may not have been the best. ;) A refactored version, named portlet-mocks-plugin (as suggested by Lukasz - along with some other changes he also suggested), has been applied via updates to the PR. It should be a cleaner plugin implementation now at any rate. Regards, James. (*Edited*: Corrected incorrect reference to spring-webmvc-portlet above, as per John's comment below) was (Author: jchaplin): Hello John. The intention was to consider a plugin which could enable continued usage of a subset of portlet-related mocks from spring-webmvc-portlet (Spring 4.3.x). It was hoped it could provide the mock functionality without introducing a new dependency for Struts 2 on PortletMVC4Spring (simply for the mocks). It was just an initial attempt, and the choice of plugin name may not have been the best. ;) A refactored version, named portlet-mocks-plugin (as suggested by Lukasz - along with some other changes he also suggested), has been applied via updates to the PR. It should be a cleaner plugin implementation now at any rate. Regards, James. > ClassNotFoundException - MockPortletResponse > > > Key: WW-5030 > URL: https://issues.apache.org/jira/browse/WW-5030 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - Portlet >Affects Versions: 2.5.18 >Reporter: John Bush >Priority: Major > Fix For: 2.6 > > Attachments: TestStrutsPortlet.zip, fail.txt, success.txt > > > WW-3826 solved a problem running JUnit tests on portlet actions that use the > struts2-portlet-plugin and struts2-junit-plugin. The solution used Spring's > org.springframework.mock.web.portlet package in the spring-test framework. > Spring Portlet MVC is no longer supported (SPR-14129) and the package has > been removed starting with Spring 5. I'm not able to upgrade to Spring 5 > without loosing my unit testing since having both versions of spring-test in > my classpath creates many other issues. > I've attached a zipped portlet project for testing (TestStrutsPortlet.zip), > console log from a successful test (success.txt) and console log from a > failed test (fail.txt). All that needs to change is the spring-version in the > POM to recreate the testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5030) ClassNotFoundException - MockPortletResponse
[ https://issues.apache.org/jira/browse/WW-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17070031#comment-17070031 ] James Chaplin commented on WW-5030: --- Hello John. The intention was to consider a plugin which could enable continued usage of a subset of portlet-related mocks from spring-webmvc-portlet (Spring 4.3.x). It was hoped it could provide the mock functionality without introducing a new dependency for Struts 2 on PortletMVC4Spring (simply for the mocks). It was just an initial attempt, and the choice of plugin name may not have been the best. ;) A refactored version, named portlet-mocks-plugin (as suggested by Lukasz - along with some other changes he also suggested), has been applied via updates to the PR. It should be a cleaner plugin implementation now at any rate. Regards, James. > ClassNotFoundException - MockPortletResponse > > > Key: WW-5030 > URL: https://issues.apache.org/jira/browse/WW-5030 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - Portlet >Affects Versions: 2.5.18 >Reporter: John Bush >Priority: Major > Fix For: 2.6 > > Attachments: TestStrutsPortlet.zip, fail.txt, success.txt > > > WW-3826 solved a problem running JUnit tests on portlet actions that use the > struts2-portlet-plugin and struts2-junit-plugin. The solution used Spring's > org.springframework.mock.web.portlet package in the spring-test framework. > Spring Portlet MVC is no longer supported (SPR-14129) and the package has > been removed starting with Spring 5. I'm not able to upgrade to Spring 5 > without loosing my unit testing since having both versions of spring-test in > my classpath creates many other issues. > I've attached a zipped portlet project for testing (TestStrutsPortlet.zip), > console log from a successful test (success.txt) and console log from a > failed test (fail.txt). All that needs to change is the spring-version in the > POM to recreate the testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5030) ClassNotFoundException - MockPortletResponse
[ https://issues.apache.org/jira/browse/WW-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048182#comment-17048182 ] James Chaplin commented on WW-5030: --- Hi. When I looked at the code spring-webmvc-portlet (Spring 4.3.x) and PortletMVC4Spring (Liferay) it seems that the older spring-webmvc-portlet mock implementation should be sufficient to satisfy the struts2-portlet-plugin and struts2-junit-plugin needs. The idea would not be a "full fork", but rather a "limited fork" (i.e. copying while preserving the notices) of the mock object package from spring-webmvc-portlet (plus one interface the mocks depend on). Since that is from Spring 4.3.x I thought the Spring folks would be the ones to give a "friendly notice" to in that circumstance ... if one is needed or looked upon as polite. Rather than going as far as a common library, I was thinking the relevant portlet mock support package could be made into a Struts Plugin that the struts2-portlet-plugin depends on. Please let me know if and/or how the Struts Team would like to proceed. > ClassNotFoundException - MockPortletResponse > > > Key: WW-5030 > URL: https://issues.apache.org/jira/browse/WW-5030 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - Portlet >Affects Versions: 2.5.18 >Reporter: John Bush >Priority: Major > Fix For: 2.6 > > Attachments: TestStrutsPortlet.zip, fail.txt, success.txt > > > WW-3826 solved a problem running JUnit tests on portlet actions that use the > struts2-portlet-plugin and struts2-junit-plugin. The solution used Spring's > org.springframework.mock.web.portlet package in the spring-test framework. > Spring Portlet MVC is no longer supported (SPR-14129) and the package has > been removed starting with Spring 5. I'm not able to upgrade to Spring 5 > without loosing my unit testing since having both versions of spring-test in > my classpath creates many other issues. > I've attached a zipped portlet project for testing (TestStrutsPortlet.zip), > console log from a successful test (success.txt) and console log from a > failed test (fail.txt). All that needs to change is the spring-version in the > POM to recreate the testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5030) ClassNotFoundException - MockPortletResponse
[ https://issues.apache.org/jira/browse/WW-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039704#comment-17039704 ] James Chaplin commented on WW-5030: --- Hello. Although Lukasz has identified a possible workaround using PortletMVC4Spring, as John commented it would involve creating a new dependency just for the mock classes. It looks like the Spring Project source code is licensed under Apache License 2.0, so my understanding is that should (in theory) make it possible to "fork" a portion of the spring-mvc-portlet source ? If Lukasz is in agreement that forking the mock elements needed for JUnit/Portlet testing with Struts 2 is permissible, I could try to come up with a PR for consideration (for the 2.6.x series only). I would need guidance on how to ensure licensing compliance in that case. Another thought - if a "fork" of the mocks is possible is there an etiquette for contacting the Spring Framework team to get their official or unofficial "blessing" ? Regards, James. > ClassNotFoundException - MockPortletResponse > > > Key: WW-5030 > URL: https://issues.apache.org/jira/browse/WW-5030 > Project: Struts 2 > Issue Type: Bug > Components: Plugin - Portlet >Affects Versions: 2.5.18 >Reporter: John Bush >Priority: Major > Fix For: 2.6 > > Attachments: TestStrutsPortlet.zip, fail.txt, success.txt > > > WW-3826 solved a problem running JUnit tests on portlet actions that use the > struts2-portlet-plugin and struts2-junit-plugin. The solution used Spring's > org.springframework.mock.web.portlet package in the spring-test framework. > Spring Portlet MVC is no longer supported (SPR-14129) and the package has > been removed starting with Spring 5. I'm not able to upgrade to Spring 5 > without loosing my unit testing since having both versions of spring-test in > my classpath creates many other issues. > I've attached a zipped portlet project for testing (TestStrutsPortlet.zip), > console log from a successful test (success.txt) and console log from a > failed test (fail.txt). All that needs to change is the spring-version in the > POM to recreate the testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WW-5043) trouble with Enum subclassing
[
https://issues.apache.org/jira/browse/WW-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17037860#comment-17037860
]
James Chaplin commented on WW-5043:
---
Hi Patrice.
New versions of OGNL (3.1.x, 3.2.x) have been released with a change that
hopefully will address this Jira's issue.
Could you please retry your local application again with Struts 2.5.22 and OGNL
3.1.28 (by overriding the version in your build or manually fetching the new
version from a trusted Maven repository) ?
Please reply with a comment to this Jira advising whether the new OGNL version
resolves the reported issue or not.
Thanks,
James.
> trouble with Enum subclassing
> -
>
> Key: WW-5043
> URL: https://issues.apache.org/jira/browse/WW-5043
> Project: Struts 2
> Issue Type: Bug
>Reporter: Patrice DUROUX
>Priority: Major
> Fix For: 2.6
>
>
> Hi,
> I found the following problem using Struts (2.5.20) based on OGNL (3.1.21)
> and same result forcing OGNL (3.1.25, as 3.2.x series seem to be not
> compatible with this version of Struts).
> The situation can be summarize with the following 2 enums:
> {code:java}
> enum Normal { A, B; }
> enum Strange {A {}, B{}; } // mainly for implementing abstract method(s)
> {code}
> and the following expressions are:
> {noformat}
> @Normal@A==@Normal@A // true
> @Normal@A!=@Normal@A // false
> @Normal@A==@Normal@B // false
> @Normal@A!=@Normal@B // true{noformat}
> whereas the following expressions are:
> {noformat}
> @Strange@A==@Strange@A // true
> @Strange@A!=@Strange@A // false
> @Strange@A==@Strange@B // false (with warn log)
> @Strange@A!=@Strange@B // false (with warn log){noformat}
> and the origin of the wrong test value was discover activating WARN log level
> in Struts (using struts.devMode).
> Thanks,
> Patrice
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (WW-5057) Cleanup and/or improvements to Showcase Applications
James Chaplin created WW-5057: - Summary: Cleanup and/or improvements to Showcase Applications Key: WW-5057 URL: https://issues.apache.org/jira/browse/WW-5057 Project: Struts 2 Issue Type: Improvement Components: Example Applications Affects Versions: 2.6 Reporter: James Chaplin Fix For: 2.6 Please refer to this Jira for tracking any cleanup or improvements to the Showcase Applications on the 2.6 branch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (WW-5035) Provide mechanism to clear OgnlUtil caches
James Chaplin created WW-5035:
-
Summary: Provide mechanism to clear OgnlUtil caches
Key: WW-5035
URL: https://issues.apache.org/jira/browse/WW-5035
Project: Struts 2
Issue Type: Improvement
Components: Core
Environment: All
Reporter: James Chaplin
Fix For: 2.5.21
Hello Apache Struts Team.
This Jira proposes to provide some cache-clearing methods for the OgnlUtil
class, as well as methods to check the current cache element count.
These methods will allow applications to clear the OgnlUtil expression cache
and BeanInfo cache when necessary (using application-specific usage profile).
Currently the only OgnlUtil cache control available to applications is to
enable/disable the OgnlUtil expressionCache
({{struts.ognl.enableExpressionCache flag}}).
Using the new methods applications that have resource (memory) leak issues with
the caches may be able to use the caches to gain some performance benefits,
while periodically clearing them to recover memory resources. Application
developers can determine how frequently (e.g. hourly, daily) such cache
clearing is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (WW-5034) Minor enhancement/fix to AbstractLocalizedTextProvider
James Chaplin created WW-5034: - Summary: Minor enhancement/fix to AbstractLocalizedTextProvider Key: WW-5034 URL: https://issues.apache.org/jira/browse/WW-5034 Project: Struts 2 Issue Type: Improvement Components: Core Affects Versions: 2.5.20 Reporter: James Chaplin Fix For: 2.5.21 Hello Apache Struts Team. This Jira issue is to track a minor enhancement/fix for the AbstractLocalizedTextProvider. - Made a "constant" static to save an initialization for instance members. - Updated clearBundle() method comment for accuracy, added debug log output. - Introduced a protected clearBundle(bundle, locale) method, with debug log output. - Introduced protected clearMissingBundlesCache() method, with debug log output. The additional methods could allow for more flexible custom AbstractLocalizedTextProvider descendants for use in scenarios where applications desire different behaviour. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-5033) Update a few Struts 2.5.x libraries to more recent versions
James Chaplin created WW-5033: - Summary: Update a few Struts 2.5.x libraries to more recent versions Key: WW-5033 URL: https://issues.apache.org/jira/browse/WW-5033 Project: Struts 2 Issue Type: Dependency Components: Build Management, Other Affects Versions: 2.5.20 Reporter: James Chaplin Fix For: 2.5.21 Hello Apache Struts Team. This Jira issue is intended to track introduction of newer (compatible) library versions for the Struts 2.5.x line. Please find below a list of library version updates for the 2.5.x build line, for which the regression build completes successfully. - Update Struts 2.5.20 build with some newer (compatible) library versions. Change the main pom.xml library versions for the following: - Jackson 2.9.8 -> 2.9.9 - Log4j2 2.11.1 -> 2.11.2 - OGNL 3.1.22 -> 3.1.23 - There is an open PR #356 demonstrating the CI build completes with the above library upgrades. Please review and consider for inclusion in 2.5.21. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WW-4970) Struts 2.3.36 - InvalidPathException: Illegal char <:> on JDK 9,10,11 on windows
[
https://issues.apache.org/jira/browse/WW-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840073#comment-16840073
]
James Chaplin commented on WW-4970:
---
Hello [~broncace] and [~kkleinwi] .
As per the announcements and statements by [~lukaszlenart] and [~yasser.zamani]
, it appears there will not be an official fix for the Struts 2.3.x series with
respect to this Jira's issue (Java 9-11 and Windows).
A *DEVELOPMENT-ONLY back-port* of relevant "com.opensymphony.xwork2.util.fs"
package changes from 2.5.x has been attempted in order to produce a
2.3.38-SNAPSHOT of the xwork-core.jar. *It is NOT an official build, so
+any-and-all-risks of its usage must be accepted by any individuals or
organizations that use the unofficial xwork-core.jar+* (+contained in
WW-4970_xwork-core-2.3.38-SNAPSHOT-DEVELOPMENT-ONLY.zip attached to this
Jira+). *It is clearly identified as a "SNAPSHOT" release and it must NOT be
used in any Production applications - it is only intended for debugging
purposes on Windows as per* [~kkleinwi]*'s comment above*.
Using this *development-only* xwork-core-2.3.38-SNAPSHOT.jar to replace the
standard one it was possible to launch the Struts 2.3.37 Showcase Application
and navigate successfully using Tomcat 8.5/OpenJDK 11.0.2 on Windows 10. It
may or may not help with Windows development debugging needs while migrating
from Struts 2.3.x to 2.5.x.
> Struts 2.3.36 - InvalidPathException: Illegal char <:> on JDK 9,10,11 on
> windows
>
>
> Key: WW-4970
> URL: https://issues.apache.org/jira/browse/WW-4970
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
>Affects Versions: 2.3.36
>Reporter: Brice Roncace
>Priority: Major
> Labels: Java10, Java11, java9
> Fix For: 2.3.37
>
> Attachments: WW-4970_xwork-core-2.3.38-SNAPSHOT-DEVELOPMENT-ONLY.zip
>
>
> This issue was fixed in Struts 2.5.14 but the fix never made it to the Struts
> 2.3 branch.
> {code:java}
> java.nio.file.InvalidPathException: Illegal char <:> at index 3:
> jar:file:\C:\development\projects\AcademyIntegration\AcademyIntegration\target\AcademyIntegration-0.1\WEB-INF\lib\struts2-core-2.3.36.jar
>
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> java.base/java.io.File.toPath(File.java:2290)
> java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1222)
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:726)
> java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:843)
> java.base/java.util.zip.ZipFile.(ZipFile.java:246)
> java.base/java.util.zip.ZipFile.(ZipFile.java:176)
> java.base/java.util.jar.JarFile.(JarFile.java:346)
> java.base/java.util.jar.JarFile.(JarFile.java:317)
> java.base/java.util.jar.JarFile.(JarFile.java:256)
>
> com.opensymphony.xwork2.util.fs.JarEntryRevision.needsReloading(JarEntryRevision.java:76)
>
> com.opensymphony.xwork2.util.fs.DefaultFileManager.fileNeedsReloading(DefaultFileManager.java:66)
>
> com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.needsReload(XmlConfigurationProvider.java:397)
>
> org.apache.struts2.config.StrutsXmlConfigurationProvider.needsReload(StrutsXmlConfigurationProvider.java:169)
>
> com.opensymphony.xwork2.config.ConfigurationManager.needReloadContainerProviders(ConfigurationManager.java:215)
>
> com.opensymphony.xwork2.config.ConfigurationManager.conditionalReload(ConfigurationManager.java:179)
>
> com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:73)
> org.apache.struts2.dispatcher.Dispatcher.getContainer(Dispatcher.java:978)
>
> org.apache.struts2.dispatcher.ng.PrepareOperations.createActionContext(PrepareOperations.java:81)
>
> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:89)
>
> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
>
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
>
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:186)
>
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
>
>
[jira] [Updated] (WW-4970) Struts 2.3.36 - InvalidPathException: Illegal char <:> on JDK 9,10,11 on windows
[
https://issues.apache.org/jira/browse/WW-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Chaplin updated WW-4970:
--
Attachment: WW-4970_xwork-core-2.3.38-SNAPSHOT-DEVELOPMENT-ONLY.zip
> Struts 2.3.36 - InvalidPathException: Illegal char <:> on JDK 9,10,11 on
> windows
>
>
> Key: WW-4970
> URL: https://issues.apache.org/jira/browse/WW-4970
> Project: Struts 2
> Issue Type: Bug
> Components: Dispatch Filter
>Affects Versions: 2.3.36
>Reporter: Brice Roncace
>Priority: Major
> Labels: Java10, Java11, java9
> Fix For: 2.3.37
>
> Attachments: WW-4970_xwork-core-2.3.38-SNAPSHOT-DEVELOPMENT-ONLY.zip
>
>
> This issue was fixed in Struts 2.5.14 but the fix never made it to the Struts
> 2.3 branch.
> {code:java}
> java.nio.file.InvalidPathException: Illegal char <:> at index 3:
> jar:file:\C:\development\projects\AcademyIntegration\AcademyIntegration\target\AcademyIntegration-0.1\WEB-INF\lib\struts2-core-2.3.36.jar
>
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> java.base/java.io.File.toPath(File.java:2290)
> java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1222)
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:726)
> java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:843)
> java.base/java.util.zip.ZipFile.(ZipFile.java:246)
> java.base/java.util.zip.ZipFile.(ZipFile.java:176)
> java.base/java.util.jar.JarFile.(JarFile.java:346)
> java.base/java.util.jar.JarFile.(JarFile.java:317)
> java.base/java.util.jar.JarFile.(JarFile.java:256)
>
> com.opensymphony.xwork2.util.fs.JarEntryRevision.needsReloading(JarEntryRevision.java:76)
>
> com.opensymphony.xwork2.util.fs.DefaultFileManager.fileNeedsReloading(DefaultFileManager.java:66)
>
> com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.needsReload(XmlConfigurationProvider.java:397)
>
> org.apache.struts2.config.StrutsXmlConfigurationProvider.needsReload(StrutsXmlConfigurationProvider.java:169)
>
> com.opensymphony.xwork2.config.ConfigurationManager.needReloadContainerProviders(ConfigurationManager.java:215)
>
> com.opensymphony.xwork2.config.ConfigurationManager.conditionalReload(ConfigurationManager.java:179)
>
> com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:73)
> org.apache.struts2.dispatcher.Dispatcher.getContainer(Dispatcher.java:978)
>
> org.apache.struts2.dispatcher.ng.PrepareOperations.createActionContext(PrepareOperations.java:81)
>
> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:89)
>
> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
>
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
>
> org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:186)
>
> org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160)
>
> org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343)
>
> org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260)
>
> org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:180)
>
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
> {code}
>
> Running on JDK 11
> {code:java}
> C:\>java -version
> openjdk version "11" 2018-09-25
> OpenJDK Runtime Environment 18.9 (build 11+28)
> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode){code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (WW-5026) Double-submit of TokenSessionStoreInterceptor broken since 2.5.16
James Chaplin created WW-5026: - Summary: Double-submit of TokenSessionStoreInterceptor broken since 2.5.16 Key: WW-5026 URL: https://issues.apache.org/jira/browse/WW-5026 Project: Struts 2 Issue Type: Bug Components: Core Interceptors Affects Versions: 2.5.20, 2.5.16 Environment: Tomcat 7.0.x (but should reproduce on any application server) Reporter: James Chaplin Fix For: 2.5.21 With recent fixes to the Showcase application it was discovered that the 3rd Token example (for TokenSessionStoreInterceptor) is failing upon the double-submit with Struts versions 2.5.16 - 2.5.20 (and 2.5.21 snapshot). Steps to reproduce: 1) Launch Struts 2.5.21-snapshot showcase application 2) Open the Examples, Token, Example 3. 3) Click on submit (wait for completion), back button in browser, then submit again. 4) Application container returns a response code 500. The issue appears to have been introduced with fixes for WW-4873. A proposed fix for this issue will be provided in a PR shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-5023) Upgrade SLF4J to latest 1.7.x version
James Chaplin created WW-5023: - Summary: Upgrade SLF4J to latest 1.7.x version Key: WW-5023 URL: https://issues.apache.org/jira/browse/WW-5023 Project: Struts 2 Issue Type: Improvement Components: Core Affects Versions: 2.5.20, 2.6 Environment: All Reporter: James Chaplin Fix For: 2.5.21, 2.6 Upgrade both the 2.5.x and 2.6 Struts branches to utilize SLF4J 1.7.26, which was recently released. A PR for each Struts branch will be created to update the SLF4J version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-5022) Struts 2.6 escaping behaviour change for s:a (anchor) tag
James Chaplin created WW-5022: - Summary: Struts 2.6 escaping behaviour change for s:a (anchor) tag Key: WW-5022 URL: https://issues.apache.org/jira/browse/WW-5022 Project: Struts 2 Issue Type: Bug Components: Core Affects Versions: 2.6 Environment: Tomcat 7.0, 8.5 using Java 8 and 11. Reporter: James Chaplin Fix For: 2.6 While interacting with the current 2.6 Showcase application I recently noticed that+ the "Home" glyph icon was not displaying correctly+. Instead of the icon, +the page displayed the body content literally in the browser+. Checking the page source (view source in browser) it turns out the body content of the tag was HTML-escaped. I double-checked and this does not happen to Struts 2.5.21 (snapshot) or older 2.6 Showcase apps. This behaviour might affect other tags, but +it was noticed and confirmed with "s:a"+ (the JSP anchor tag). After some digging (using older commits from GitHub and building the 2.6 Showcase app from them) it appears the automatic body escaping did not occur prior to January 2nd 2019, but was introduced with one of the multiple commits applied on January 3rd 2019. It could be an interaction between earlier mid-December 2018 commits that changed the Freemarker configuration version in FreemarkerManager (Configuration.VERSION_2_3_0) to a new one (Configuration.VERSION_2_3_28), combined with the January 3rd commits. Couldn't find the exact cause, but perhaps one of the Struts Team might be able to do so. Given the original/old behaviour +it seems that auto-escaping the tag body might be a bug+. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-5012) Make a public state check the first acceptance check in SecurityMemberAccess
James Chaplin created WW-5012: - Summary: Make a public state check the first acceptance check in SecurityMemberAccess Key: WW-5012 URL: https://issues.apache.org/jira/browse/WW-5012 Project: Struts 2 Issue Type: Improvement Components: Core Affects Versions: 2.5.20 Environment: All environments. Reporter: James Chaplin Fix For: 2.5.21, 2.6 During discussion for WW-5004, a recommendation was made by two Apache Struts Team members to adjust the sequence of calls in the SecurityMemberAccess module. The recommendation was to make the member's public state check (e.g. checkPublicMemberAccess()) the absolute first check made during acceptance checks). This improvement would look at implementing this change for the access check ordering, and any minor enhancements that are applicable to the ordering change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WW-5004) No more calling of a static variable in Struts 2.8.20 available
[
https://issues.apache.org/jira/browse/WW-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16747696#comment-16747696
]
James Chaplin commented on WW-5004:
---
Hello.
For 2.5.x it seems that the flag _struts.allowStaticMethodAccess_ does produce
a change, to allow the field access, but as commented above that wasn't
necessary to access public static fields in 2.5.18.
There's a recent PR for OGNL 3.1.x that might mitigate the issue for 2.5.21,
but downgrading to OGNL 3.1.18 also worked for me with 2.5.20 (at least
according to a test page created to simulate the scenario).
> No more calling of a static variable in Struts 2.8.20 available
> ---
>
> Key: WW-5004
> URL: https://issues.apache.org/jira/browse/WW-5004
> Project: Struts 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.5.20
> Environment: Java 7.1 and JSP Websites
>Reporter: Deniz Renkligül
>Priority: Critical
> Labels: build, features, patch, usability
> Fix For: 2.5.21, 2.6
>
>
> After the update from Struts 2.5.18 to 2.5.20 it is not more possible to call
> a java static variable in JSP like
> {code:java}
>
> {code}
> Please see for more details the release notes of 2.5.20
> [link
> https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.5.20|https://cwiki.apache.org/confluence/display/WW/Version+Notes+2.5.20]
> and I tried without success the following description assigned above in the
> release version notes 2.5.20 with :
> {code:java}
>
>
> {code}
> https://issues.apache.org/jira/browse/WW-4984
>
> Thanks in advance for your support.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (WW-4995) Enhancement for s:set tag to improve tag body whitespace control.
James Chaplin created WW-4995: - Summary: Enhancement for s:set tag to improve tag body whitespace control. Key: WW-4995 URL: https://issues.apache.org/jira/browse/WW-4995 Project: Struts 2 Issue Type: Improvement Components: Core Tags Affects Versions: 2.5.18 Environment: All environments. Reporter: James Chaplin Fix For: 2.5.19 Hello Apache Struts Team. The current s:set tag performs an automatic _trim()_ on any body content used (when using the something style with a body). The current behaviour limits white-space control for the text body passed to the s:set tag (and makes assigning a single-or-muliple-character whitespace set - e.g. " " impossible via the tag body).. A proposed improvement is to introduce two optional attributes to the s:set tag which will permit the following: * Allow an override to prevent the trim() from happening (helps to preserve existing whitespace).. * Allow the optional removal of all line-breaks from the tag body content (to allow vertical collapsing of tag body content without impacting anything else). There is a PR available with a proposed implementation for the enhancement. I believe having this additional flexibility will be beneficial for some JSP content generation scenarios. Please review and advise if this minor enhancement can be considered for inclusion in 2.5.19 (and then ported forward for 2.6). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-4993) Update OGNL versions for 2.6 and 2.5.x builds
James Chaplin created WW-4993: - Summary: Update OGNL versions for 2.6 and 2.5.x builds Key: WW-4993 URL: https://issues.apache.org/jira/browse/WW-4993 Project: Struts 2 Issue Type: Dependency Components: Build Management Affects Versions: 2.5.18, 2.6 Reporter: James Chaplin Fix For: 2.6, 2.5.19 Hello Apache Struts Team. This Jira is for consideration of an upgrade to the OGNL libraries used in the Struts 2.5.x and 2.6 build lines. The most recent applicable versions available at this time are 3.1.21 (for 2.5.x) and 3.2.9 (for 2.6). There is an open PR #293 for 2.5.x and PR #294 for 2.6 available. The regression tests all pass for 2.5.19-snapshot and 2.6 using the versions listed above. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WW-4988) Upgrade DWR from 1.x to 2.x (for DWR plugin)
[ https://issues.apache.org/jira/browse/WW-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16710853#comment-16710853 ] James Chaplin commented on WW-4988: --- Good job [~yasser.zamani] ! :) Thanks for your effort - and the addition to the showcase app. Upgrading to DWR3 (and DWR2 just prior) appears to allow the automated Jenkins builds to get further (past the DWR plugin for sure ;) ). > Upgrade DWR from 1.x to 2.x (for DWR plugin) > > > Key: WW-4988 > URL: https://issues.apache.org/jira/browse/WW-4988 > Project: Struts 2 > Issue Type: Dependency > Components: Plugin - DWR >Affects Versions: 2.6 > Environment: All environments >Reporter: James Chaplin >Priority: Minor > Labels: pull-request-available > Fix For: 2.6 > > > Hello Apache Struts Team. > There appears to be a failure/warning reported in the automated nightly > Jenkins builds in relation to the DWR plugin component (reported by > org.owasp:dependency-check-maven). > A PR ([https://github.com/apache/struts/pull/283)] has been opened in hopes > of addressing this by _upgrading the Struts 2.6 DWR plugin to the most recent > API-compatible version of DWR_ (2.x series). > > Since _only manual testing/verification is possible at this time_ (requires > modification of the showcase application web.xml, see above PR for details), > _there is a risk that upgrading the DWR dependency might introduce issues for > the DWR plugin_. > > If there is anyone who has _suggestions on creating an automated (preferably > self-contained) test for the DWR plugin_ within the regression suite please > advise by commenting on this JIRA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-4988) Upgrade DWR from 1.x to 2.x (for DWR plugin)
James Chaplin created WW-4988: - Summary: Upgrade DWR from 1.x to 2.x (for DWR plugin) Key: WW-4988 URL: https://issues.apache.org/jira/browse/WW-4988 Project: Struts 2 Issue Type: Dependency Components: Plugin - DWR Affects Versions: 2.6 Environment: All environments Reporter: James Chaplin Fix For: 2.6 Hello Apache Struts Team. There appears to be a failure/warning reported in the automated nightly Jenkins builds in relation to the DWR plugin component (reported by org.owasp:dependency-check-maven). A PR ([https://github.com/apache/struts/pull/283)] has been opened in hopes of addressing this by _upgrading the Struts 2.6 DWR plugin to the most recent API-compatible version of DWR_ (2.x series). Since _only manual testing/verification is possible at this time_ (requires modification of the showcase application web.xml, see above PR for details), _there is a risk that upgrading the DWR dependency might introduce issues for the DWR plugin_. If there is anyone who has _suggestions on creating an automated (preferably self-contained) test for the DWR plugin_ within the regression suite please advise by commenting on this JIRA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-4979) Update multiple Struts 2.6.x libraries to more recent versions
James Chaplin created WW-4979: - Summary: Update multiple Struts 2.6.x libraries to more recent versions Key: WW-4979 URL: https://issues.apache.org/jira/browse/WW-4979 Project: Struts 2 Issue Type: Dependency Components: Build Management, Other Affects Versions: 2.6 Environment: All. Reporter: James Chaplin Fix For: 2.6 Hello Apache Struts Team. This Jira issue is intended to request/track introduction of newer (believed to be compatible) library versions for the unreleased Struts 2.6.x line. This can be achieved by modifications to one or more pom.xml build files for the project. Since multiple library version upgrades are being attempted at the same time there is some risk, but the build regression does complete without failure. The number of library upgrades could be reduced (broken into smaller sets and slowly introduced) if necessary. End users would also have the option of manually back-leveling specific jars. Please find below a list of library version updates that appear to be compatible with the current versions in the 2.6.x build line. - Update Struts 2.6 build with some newer (compatible) library versions. Change the main pom.xml library versions for the following: - spring.platformVersion 4.3.13.RELEASE -> 4.3.20.RELEASE - oval 1.31 -> 1.90 (Note: required unit test fix for OValValidationInterceptorTest.java AND code fix for OvalValidationInterceptor.java. Oval 1.70 was the most recent that could be used without a fix to OvalValidationInterceptor.) - jackson 2.9.6 -> 2.9.7 - fluido-skin.version 1.6 -> 1.7 - slf4j (slf4j-api, slf4j-simple) 1.7.12 -> 1.7.25 - xstream 1.4.10 -> 1.4.11.1 - jetty 6.1.9 -> 6.1.26 (last in 6.1.x line) - xerces 2.10.0 - > 2.12.0 - org.owasp 3.1.1 -> 3.3.4 - versions-maven-plugin 2.5 -> 2.7 - doxia-core 1.7 -> 1.8 - doxia-module-markdown 1.3 -> 1.7 - org.apache.felix.main 4.0.3 -> 4.6.1 (Note: most recent 4.x) - easymock 3.4 -> 3.5.1 - javax.el 3.0 -> 3.0.1-b10 - jasper 6.0.18 -> 6.0.53 (Note: most recent 6.0.x) - juli 6.0.18 -> 6.0.53 (Note: most recent 6.0.x) - commons-logging 1.1.3 -> 1.2 - commons-collections4 4.1 -> 4.2 - commons-io 2.5 -> 2.6 - commons-lang3 3.6 -> 3.8.1 - commons-text 1.2 -> 1.3 (Note: most recent compatible with Java 7) - commons-validator 1.5.1 -> 1.6 - mockito 1.9.5 -> 1.10.19 (Note: most recent 1.x) - cdi-api 1.0-SP1 -> 1.0-SP4 (Note: most recent 1.0.x) - weld-core 1.0.1-Final -> 1.0.1-SP4 (Note: most recent 1.0.x) - cglib 2.2 -> 2.2.2 (Note: most recent 2.2.x, as 2.2.3's status is uncertain) Note: cglib-nodep version appears to be determined by the jmock-cglib requirement for JMock 1.2.0. Leaving the cglib-nodep version is probably safest for now. However for 2.6.x the cglib dependency can probably go to 2.2.2 for the build. There might be consideration for the cglib 3.x series, but that might impact other components. - There is an open PR #265 which demonstrates the build/regression completes using the above version changes. The main Showcase application (not the REST one) appears to work interactively as well, but there are no demonstrator applications for the Plugins. Please note: The struts2-rest-showcase application does not work (initialization fails due to: com.opensymphony.xwork2.config.ConfigurationException: Unable to find interceptor class referenced by ref-name profiling). The init failed before the library version changes, so it doesn't appear to be related. Please review the above and see if some or all of the library updates appear appropriate for the 2.6.x build line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-4978) Update multiple Struts 2.5.x libraries to more recent versions
James Chaplin created WW-4978: - Summary: Update multiple Struts 2.5.x libraries to more recent versions Key: WW-4978 URL: https://issues.apache.org/jira/browse/WW-4978 Project: Struts 2 Issue Type: Dependency Components: Build Management, Other Affects Versions: 2.5.18 Environment: All. Reporter: James Chaplin Fix For: 2.5.19 Hello Apache Struts Team. This Jira issue is intended to request/track introduction of newer (believed to be compatible) library versions for the Struts 2.5.x line. This can be achieved by modifications to one or more pom.xml build files for the project. Since multiple library version upgrades are being attempted at the same time there is some risk, but the build regression does complete without failure. The number of library upgrades could be reduced (broken into smaller sets and slowly introduced) if necessary. End users would also have the option of manually back-leveling specific jars. Please find below a list of library version updates that appear to be compatible with the current versions in the 2.5.x build line. - Update Struts 2.5.19 build with some newer (compatible) library versions. Change the main pom.xml library versions for the following: - spring.platformVersion 4.3.13.RELEASE -> 4.3.20.RELEASE - ognl 3.1.15 -> 3.1.18 (Note: newest version that passes unit tests) - oval 1.31 -> 1.90 (Note: requires unit test fix for OValValidationInterceptorTest.java) - tiles 3.0.7 -> 3.0.8 - tiles-request 1.0.6 -> 1.0.7 - log4j 2.10.0 -> 2.11.1 - jackson 2.9.5 -> 2.9.7 - fluido-skin.version 1.6 -> 1.7 - slf4j 1.7.12 -> 1.7.25 - xtream 1.4.10 -> 1.4.11.1 - jetty 6.1.9 -> 6.1.26 (last in 6.1.x line) - xerces 2.10.0 - > 2.12.0 - org.owasp 3.1.1 -> 3.3.4 - versions-maven-plugin 2.5 -> 2.7 - doxia-core 1.7 -> 1.8 - doxia-markdown 1.3 -> 1.7 - freemarker 2.3.26-incubating -> 2.3.28 - org.apache.felix.main 4.0.3 -> 4.6.1 (Note: most recent 4.x) - easymock 3.4 -> 3.5.1 - javax.el 3.0 -> 3.0.1-b10 - jasper 6.0.18 -> 6.0.53 (Note: most recent 6.0.x) - juli 6.0.18 -> 6.0.53 (Note: most recent 6.0.x) - commons-logging 1.1.3 -> 1.2 - commons-collections4 4.1 -> 4.2 - commons-io 2.5 -> 2.6 - commons-lang 3.6 -> 3.8.1 - commons-beanutils 1.9.2 -> 1.9.3 - commons-validator 1.5.1 -> 1.6 - mockito 1.9.5 -> 1.10.19 (Note: most recent 1.x) - cdi-api 1.0-SP1 -> 1.0-SP4 (Note: most recent 1.0.x) - weld-core 1.0.1-Final -> 1.0.1-SP4 (Note: most recent 1.0.x) Note: cglib-nodep version appears to be determined by the jmock-cglib requirement for JMock 1.2.0. Seems safer to leave cglib/cglib-nodep alone for 2.5.x series builds. - There is an open PR #264 which demonstrates the build/regression completes using the above version changes. The Showcase applications appear to work interactively as well, but there are no demonstrator applications for the Plugins. Please review the above and see if some or all of the library updates appear appropriate for the 2.5.x build line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (WW-4971) s:include tag fails with truncated content in certain circumstances
[ https://issues.apache.org/jira/browse/WW-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Chaplin updated WW-4971: -- Attachment: WW4791_Reproducer.war > s:include tag fails with truncated content in certain circumstances > --- > > Key: WW-4971 > URL: https://issues.apache.org/jira/browse/WW-4971 > Project: Struts 2 > Issue Type: Bug > Components: Core Tags >Affects Versions: 2.3.36, 2.5.18 > Environment: Windows 10, Java 7/8 (but issue isn't environment > specific) >Reporter: James Chaplin >Priority: Major > Fix For: 2.6 > > Attachments: WW4791_Reproducer.war > > > Hello Apache Struts Team. > There is an issue with the Struts include tag (s:include) when processing > includes on a page that isn't using UTF-8 encoding (e.g. ISO-8859-1 or > Windows-1252 page encoding). > In some circumstances the s:include tag results in truncated content from the > child page (i.e. the parent page including the child page via s:include > experiences incomplete rendering of the included content). This happens when > the included page contains certain characters (e.g. 'ç') in a non-UTF8 > encoding (whether directly or from a resource bundle). > There are no warnings produced in the logs (even in debug mode), so the issue > can only be detected visually when things fail. > Changing all the content to UTF-8 is a workaround, but that is not feasible > in all circumstances. Given the preceding and the lack of warnings I'm > initially submitting it as a major priority. > I will attempt to submit a bugfix for consideration shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (WW-4971) s:include tag fails with truncated content in certain circumstances
James Chaplin created WW-4971: - Summary: s:include tag fails with truncated content in certain circumstances Key: WW-4971 URL: https://issues.apache.org/jira/browse/WW-4971 Project: Struts 2 Issue Type: Bug Components: Core Tags Affects Versions: 2.5.18, 2.3.36 Environment: Windows 10, Java 7/8 (but issue isn't environment specific) Reporter: James Chaplin Fix For: 2.5.x Hello Apache Struts Team. There is an issue with the Struts include tag (s:include) when processing includes on a page that isn't using UTF-8 encoding (e.g. ISO-8859-1 or Windows-1252 page encoding). In some circumstances the s:include tag results in truncated content from the child page (i.e. the parent page including the child page via s:include experiences incomplete rendering of the included content). This happens when the included page contains certain characters (e.g. 'ç') in a non-UTF8 encoding (whether directly or from a resource bundle). There are no warnings produced in the logs (even in debug mode), so the issue can only be detected visually when things fail. Changing all the content to UTF-8 is a workaround, but that is not feasible in all circumstances. Given the preceding and the lack of warnings I'm initially submitting it as a major priority. I will attempt to submit a bugfix for consideration shortly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
[ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15843644#comment-15843644 ] James Chaplin commented on WW-4734: --- Hello Lukasz. Everything seems to work as expected with the 2.5.9 test build (revision 18023, as per your test build comment above), no additional issues noted during an interactive sanity check. > I18Interceptor ignores session or cookie Locale after first lookup failure > -- > > Key: WW-4734 > URL: https://issues.apache.org/jira/browse/WW-4734 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors >Affects Versions: 2.5.8 >Reporter: James Chaplin >Assignee: Lukasz Lenart >Priority: Blocker > Labels: interceptors > Fix For: 2.5.10 > > > In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the > locale state set programmatically via session (e.g. > session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). > Struts 2.5.8 ignores a locale state set programmatically via session (or at > least it does so after the 1st failed lookup). > *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour > causes "storage == Storage.NONE" after 1st lookup failure, and > i18nInterceptor will never again check session/cookie scopes for a locale. > Appears to have been introduced with changes for WW-4722. > *Bug elements: > 1) readStoredLocale() - Never checks session/cookie level for a saved > locale (after first lookup failure sets "storage = Storage.NONE"). > 2) readStoredLocale() - The "if block" checks are inverted. When "storage > == Storage.COOKIE" it checks session, when "storage == Storage.SESSION" it > checks cookie (appears this was addressed in update to WW-4722 on 2017/01/11). > 3) LocaleFinder/saveLocale() - No longer provides default lookup at session > level, no longer preserves the storage level where the lookup succeded. > *Suggested remedy: > 1) Restore logic equivalent to 2.5.5 and earlier that will always check > session and cookie scopes for Locale, irrespective of what the current i18n > interceptor instance's storage value is set to. > Change readStoredLocale() to check all scopes, restore storage scope > state to LocaleFinder and calls to saveLocale(). Use LocaleFilender's scope > state (tracking immediate request's locale storage level) during request > processing (and if possible, leave i18n interceptor's scope fixed/unchanged). > 2) Add logic to I18nInterceptor that preserves the initially configured > storage type/scope for the lifetime of the i18n interceptor. This could be > done by adding a new protected member to I18nInterceptor (e.g. protected > configuredStorage), which gets initialized similarly to "storage" but only > modified in the initial setLocaleStorage() call (so its value stays intact > until explicitly changed by configuration). > Either way it appears the I18nInterceptor needs a mechanism to ensure that it > will always look for Locale at the session/cookie level (or at the very least > the level that was initially configured for the interceptor), irrespective of > what the current storage value is set to. Without such logic the i18n > interceptor stops looking for anything other than the request/invocation > context level (after the first lookup failure, irrespective of original > storage setting). Tracking the configured storage scope (global) and the > immediate request's scope (local) separately might be appropriate. > *Note: API documentation for I18nInterceptor "storage" parameter appears > incorrect as well. The new configuration parameter in 2.5.8 should indicate > "localeStorage" for configuring the locale storage parameter (it indicates > "storage" currently, but that fails as it doesn't match the setter's name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
[ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828685#comment-15828685 ] James Chaplin commented on WW-4734: --- Ok sorry - I definitely mis-interpreted then :). I don't think the missing JavaDoc description is a blocker for the published 2.5.9 test build. > I18Interceptor ignores session or cookie Locale after first lookup failure > -- > > Key: WW-4734 > URL: https://issues.apache.org/jira/browse/WW-4734 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors >Affects Versions: 2.5.8 >Reporter: James Chaplin >Assignee: Lukasz Lenart >Priority: Blocker > Labels: interceptors > Fix For: 2.5.9 > > > In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the > locale state set programmatically via session (e.g. > session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). > Struts 2.5.8 ignores a locale state set programmatically via session (or at > least it does so after the 1st failed lookup). > *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour > causes "storage == Storage.NONE" after 1st lookup failure, and > i18nInterceptor will never again check session/cookie scopes for a locale. > Appears to have been introduced with changes for WW-4722. > *Bug elements: > 1) readStoredLocale() - Never checks session/cookie level for a saved > locale (after first lookup failure sets "storage = Storage.NONE"). > 2) readStoredLocale() - The "if block" checks are inverted. When "storage > == Storage.COOKIE" it checks session, when "storage == Storage.SESSION" it > checks cookie (appears this was addressed in update to WW-4722 on 2017/01/11). > 3) LocaleFinder/saveLocale() - No longer provides default lookup at session > level, no longer preserves the storage level where the lookup succeded. > *Suggested remedy: > 1) Restore logic equivalent to 2.5.5 and earlier that will always check > session and cookie scopes for Locale, irrespective of what the current i18n > interceptor instance's storage value is set to. > Change readStoredLocale() to check all scopes, restore storage scope > state to LocaleFinder and calls to saveLocale(). Use LocaleFilender's scope > state (tracking immediate request's locale storage level) during request > processing (and if possible, leave i18n interceptor's scope fixed/unchanged). > 2) Add logic to I18nInterceptor that preserves the initially configured > storage type/scope for the lifetime of the i18n interceptor. This could be > done by adding a new protected member to I18nInterceptor (e.g. protected > configuredStorage), which gets initialized similarly to "storage" but only > modified in the initial setLocaleStorage() call (so its value stays intact > until explicitly changed by configuration). > Either way it appears the I18nInterceptor needs a mechanism to ensure that it > will always look for Locale at the session/cookie level (or at the very least > the level that was initially configured for the interceptor), irrespective of > what the current storage value is set to. Without such logic the i18n > interceptor stops looking for anything other than the request/invocation > context level (after the first lookup failure, irrespective of original > storage setting). Tracking the configured storage scope (global) and the > immediate request's scope (local) separately might be appropriate. > *Note: API documentation for I18nInterceptor "storage" parameter appears > incorrect as well. The new configuration parameter in 2.5.8 should indicate > "localeStorage" for configuring the locale storage parameter (it indicates > "storage" currently, but that fails as it doesn't match the setter's name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
[ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828661#comment-15828661 ] James Chaplin commented on WW-4734: --- I might not be understanding the difference between blocker for 2.5.9 and 2.5.8. My intent was to indicate the code fix should definitely be included in 2.5.9 (given the behaviour issue with 2.5.8). Since 2.5.8 was already GA I thought the blocker status could only be applied to 2.5.9. (If we're talking about the JavaDoc item _storage_ vs. _localeStorage_, that could be corrected after 2.5.9 since param _localeStorage_ works). > I18Interceptor ignores session or cookie Locale after first lookup failure > -- > > Key: WW-4734 > URL: https://issues.apache.org/jira/browse/WW-4734 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors >Affects Versions: 2.5.8 >Reporter: James Chaplin >Assignee: Lukasz Lenart >Priority: Blocker > Labels: interceptors > Fix For: 2.5.9 > > > In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the > locale state set programmatically via session (e.g. > session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). > Struts 2.5.8 ignores a locale state set programmatically via session (or at > least it does so after the 1st failed lookup). > *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour > causes "storage == Storage.NONE" after 1st lookup failure, and > i18nInterceptor will never again check session/cookie scopes for a locale. > Appears to have been introduced with changes for WW-4722. > *Bug elements: > 1) readStoredLocale() - Never checks session/cookie level for a saved > locale (after first lookup failure sets "storage = Storage.NONE"). > 2) readStoredLocale() - The "if block" checks are inverted. When "storage > == Storage.COOKIE" it checks session, when "storage == Storage.SESSION" it > checks cookie (appears this was addressed in update to WW-4722 on 2017/01/11). > 3) LocaleFinder/saveLocale() - No longer provides default lookup at session > level, no longer preserves the storage level where the lookup succeded. > *Suggested remedy: > 1) Restore logic equivalent to 2.5.5 and earlier that will always check > session and cookie scopes for Locale, irrespective of what the current i18n > interceptor instance's storage value is set to. > Change readStoredLocale() to check all scopes, restore storage scope > state to LocaleFinder and calls to saveLocale(). Use LocaleFilender's scope > state (tracking immediate request's locale storage level) during request > processing (and if possible, leave i18n interceptor's scope fixed/unchanged). > 2) Add logic to I18nInterceptor that preserves the initially configured > storage type/scope for the lifetime of the i18n interceptor. This could be > done by adding a new protected member to I18nInterceptor (e.g. protected > configuredStorage), which gets initialized similarly to "storage" but only > modified in the initial setLocaleStorage() call (so its value stays intact > until explicitly changed by configuration). > Either way it appears the I18nInterceptor needs a mechanism to ensure that it > will always look for Locale at the session/cookie level (or at the very least > the level that was initially configured for the interceptor), irrespective of > what the current storage value is set to. Without such logic the i18n > interceptor stops looking for anything other than the request/invocation > context level (after the first lookup failure, irrespective of original > storage setting). Tracking the configured storage scope (global) and the > immediate request's scope (local) separately might be appropriate. > *Note: API documentation for I18nInterceptor "storage" parameter appears > incorrect as well. The new configuration parameter in 2.5.8 should indicate > "localeStorage" for configuring the locale storage parameter (it indicates > "storage" currently, but that fails as it doesn't match the setter's name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
[ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828612#comment-15828612 ] James Chaplin commented on WW-4734: --- No problem. I think this issue/fix should probably be a _blocker_ for the 2.5.9 release. The only workaround for this issue in 2.5.8 involves replacing the i18n interceptor with a custom implementation (no quick fix via configuration possible), otherwise i18n localization effectively doesn't work for session/cookie (compared to previous 2.5.x and 2.3.x releases). > I18Interceptor ignores session or cookie Locale after first lookup failure > -- > > Key: WW-4734 > URL: https://issues.apache.org/jira/browse/WW-4734 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors >Affects Versions: 2.5.8 >Reporter: James Chaplin >Assignee: Lukasz Lenart > Labels: interceptors > Fix For: 2.5.9 > > > In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the > locale state set programmatically via session (e.g. > session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). > Struts 2.5.8 ignores a locale state set programmatically via session (or at > least it does so after the 1st failed lookup). > *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour > causes "storage == Storage.NONE" after 1st lookup failure, and > i18nInterceptor will never again check session/cookie scopes for a locale. > Appears to have been introduced with changes for WW-4722. > *Bug elements: > 1) readStoredLocale() - Never checks session/cookie level for a saved > locale (after first lookup failure sets "storage = Storage.NONE"). > 2) readStoredLocale() - The "if block" checks are inverted. When "storage > == Storage.COOKIE" it checks session, when "storage == Storage.SESSION" it > checks cookie (appears this was addressed in update to WW-4722 on 2017/01/11). > 3) LocaleFinder/saveLocale() - No longer provides default lookup at session > level, no longer preserves the storage level where the lookup succeded. > *Suggested remedy: > 1) Restore logic equivalent to 2.5.5 and earlier that will always check > session and cookie scopes for Locale, irrespective of what the current i18n > interceptor instance's storage value is set to. > Change readStoredLocale() to check all scopes, restore storage scope > state to LocaleFinder and calls to saveLocale(). Use LocaleFilender's scope > state (tracking immediate request's locale storage level) during request > processing (and if possible, leave i18n interceptor's scope fixed/unchanged). > 2) Add logic to I18nInterceptor that preserves the initially configured > storage type/scope for the lifetime of the i18n interceptor. This could be > done by adding a new protected member to I18nInterceptor (e.g. protected > configuredStorage), which gets initialized similarly to "storage" but only > modified in the initial setLocaleStorage() call (so its value stays intact > until explicitly changed by configuration). > Either way it appears the I18nInterceptor needs a mechanism to ensure that it > will always look for Locale at the session/cookie level (or at the very least > the level that was initially configured for the interceptor), irrespective of > what the current storage value is set to. Without such logic the i18n > interceptor stops looking for anything other than the request/invocation > context level (after the first lookup failure, irrespective of original > storage setting). Tracking the configured storage scope (global) and the > immediate request's scope (local) separately might be appropriate. > *Note: API documentation for I18nInterceptor "storage" parameter appears > incorrect as well. The new configuration parameter in 2.5.8 should indicate > "localeStorage" for configuring the locale storage parameter (it indicates > "storage" currently, but that fails as it doesn't match the setter's name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
[ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15828519#comment-15828519 ] James Chaplin commented on WW-4734: --- Hello Lukasz. The refactored *I18nInterceptor.java* appears to work as expected now (tried both using the source directly to replace the default i18n interceptor for 2.5.8, and using "struts2-core-2.5.9-20170115.171851-15" core jar). *Thanks* for looking into the bug and producing a fix for it. *Note 1*: JavaDoc comment for I18nInterceptor.java states: _storage (optional) -_, but should be _localeStorage (optional) -_ to match the setter (corresponding to _session_ in the configuration). *Note 2*: According to the old 2.5.5 code it appears that if _Storage.COOKIE_ was configured, _storeLocale()_ stored it in the cookie then set storage type to _Storage.SESSION_ (which caused it also to be stored in session if available). After that the i18n interceptor would be stuck in _Storage.SESSION_ (but lookups would still find things programmatically stored by cookie ... I think). I don't think that wrinkle would negatively impact any 2.5.x apps using _Storage.COOKIE_ with the latest implementation, but I figured it was worth mentioning. In any event the recent I18nInterceptor refactoring seems cleaner than the 2.5.5 and 2.5.8 revisions (the configured storage level for the interceptor remains invariant over invocations), and appears to work for _Storage.SESSION_ as expected. If I note any problem later on I will advise. Thanks again. > I18Interceptor ignores session or cookie Locale after first lookup failure > -- > > Key: WW-4734 > URL: https://issues.apache.org/jira/browse/WW-4734 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors >Affects Versions: 2.5.8 >Reporter: James Chaplin >Assignee: Lukasz Lenart > Labels: interceptors > Fix For: 2.5.9 > > > In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the > locale state set programmatically via session (e.g. > session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). > Struts 2.5.8 ignores a locale state set programmatically via session (or at > least it does so after the 1st failed lookup). > *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour > causes "storage == Storage.NONE" after 1st lookup failure, and > i18nInterceptor will never again check session/cookie scopes for a locale. > Appears to have been introduced with changes for WW-4722. > *Bug elements: > 1) readStoredLocale() - Never checks session/cookie level for a saved > locale (after first lookup failure sets "storage = Storage.NONE"). > 2) readStoredLocale() - The "if block" checks are inverted. When "storage > == Storage.COOKIE" it checks session, when "storage == Storage.SESSION" it > checks cookie (appears this was addressed in update to WW-4722 on 2017/01/11). > 3) LocaleFinder/saveLocale() - No longer provides default lookup at session > level, no longer preserves the storage level where the lookup succeded. > *Suggested remedy: > 1) Restore logic equivalent to 2.5.5 and earlier that will always check > session and cookie scopes for Locale, irrespective of what the current i18n > interceptor instance's storage value is set to. > Change readStoredLocale() to check all scopes, restore storage scope > state to LocaleFinder and calls to saveLocale(). Use LocaleFilender's scope > state (tracking immediate request's locale storage level) during request > processing (and if possible, leave i18n interceptor's scope fixed/unchanged). > 2) Add logic to I18nInterceptor that preserves the initially configured > storage type/scope for the lifetime of the i18n interceptor. This could be > done by adding a new protected member to I18nInterceptor (e.g. protected > configuredStorage), which gets initialized similarly to "storage" but only > modified in the initial setLocaleStorage() call (so its value stays intact > until explicitly changed by configuration). > Either way it appears the I18nInterceptor needs a mechanism to ensure that it > will always look for Locale at the session/cookie level (or at the very least > the level that was initially configured for the interceptor), irrespective of > what the current storage value is set to. Without such logic the i18n > interceptor stops looking for anything other than the request/invocation > context level (after the first lookup failure, irrespective of original > storage setting). Tracking the configured storage scope (global) and the > immediate request's scope (local) separately might be appropriate. > *Note: API documentation for I18nInterceptor "storage" parameter appears > incorrect as well. The new
[jira] [Commented] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
[ https://issues.apache.org/jira/browse/WW-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822520#comment-15822520 ] James Chaplin commented on WW-4734: --- (Apologies - I'm not used to the text formatting options yet so I'm sticking to plain text). Hello Lukasz. The change for WW-4722 you mention in the comment above is related, but only part of the issue noted here (it corresponds to element 2 of the bug described above). Even with that latest change the I18nInterceptor behaviour will still be different compared to 2.5.5 and before. For example during an initial login (with no previous session or cookie present) the I18nInterceptor will not find a Locale at the session scope and has its storage type set to Storage.NONE. After that even if a Locale is added to that session (I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE) the i18n interceptor will never find it. That appears to hold true forever afterwards (the interceptor's storage type becomes "stuck" at none). In 2.5.5 and prior one could set the Locale programmatically (e.g. during or after a login) and the i18n interceptor would find/honour the value. With 2.5.8 it appears broken. Even looking at the 2.5.5 and earlier code it isn't clear to me clear why the I18nInterceptor's storage value was dynamically changing anyway. It seems that to work consistently it would always need to search session/cookie in the event there wasn't a specific Locale request parameter (unless I'm missing something ?). > I18Interceptor ignores session or cookie Locale after first lookup failure > -- > > Key: WW-4734 > URL: https://issues.apache.org/jira/browse/WW-4734 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors >Affects Versions: 2.5.8 >Reporter: James Chaplin >Assignee: Lukasz Lenart > Labels: interceptors > Fix For: 2.5.next > > > In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the > locale state set programmatically via session (e.g. > session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). > Struts 2.5.8 ignores a locale state set programmatically via session (or at > least it does so after the 1st failed lookup). > *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour > causes "storage == Storage.NONE" after 1st lookup failure, and > i18nInterceptor will never again check session/cookie scopes for a locale. > Appears to have been introduced with changes for WW-4722. > *Bug elements: > 1) readStoredLocale() - Never checks session/cookie level for a saved > locale (after first lookup failure sets "storage = Storage.NONE"). > 2) readStoredLocale() - The "if block" checks are inverted. When "storage > == Storage.COOKIE" it checks session, when "storage == Storage.SESSION" it > checks cookie (appears this was addressed in update to WW-4722 on 2017/01/11). > 3) LocaleFinder/saveLocale() - No longer provides default lookup at session > level, no longer preserves the storage level where the lookup succeded. > *Suggested remedy: > 1) Restore logic equivalent to 2.5.5 and earlier that will always check > session and cookie scopes for Locale, irrespective of what the current i18n > interceptor instance's storage value is set to. > Change readStoredLocale() to check all scopes, restore storage scope > state to LocaleFinder and calls to saveLocale(). Use LocaleFilender's scope > state (tracking immediate request's locale storage level) during request > processing (and if possible, leave i18n interceptor's scope fixed/unchanged). > 2) Add logic to I18nInterceptor that preserves the initially configured > storage type/scope for the lifetime of the i18n interceptor. This could be > done by adding a new protected member to I18nInterceptor (e.g. protected > configuredStorage), which gets initialized similarly to "storage" but only > modified in the initial setLocaleStorage() call (so its value stays intact > until explicitly changed by configuration). > Either way it appears the I18nInterceptor needs a mechanism to ensure that it > will always look for Locale at the session/cookie level (or at the very least > the level that was initially configured for the interceptor), irrespective of > what the current storage value is set to. Without such logic the i18n > interceptor stops looking for anything other than the request/invocation > context level (after the first lookup failure, irrespective of original > storage setting). Tracking the configured storage scope (global) and the > immediate request's scope (local) separately might be appropriate. > *Note: API documentation for I18nInterceptor "storage" parameter appears > incorrect as well. The new configuration parameter in 2.5.8
[jira] [Created] (WW-4734) I18Interceptor ignores session or cookie Locale after first lookup failure
James Chaplin created WW-4734: - Summary: I18Interceptor ignores session or cookie Locale after first lookup failure Key: WW-4734 URL: https://issues.apache.org/jira/browse/WW-4734 Project: Struts 2 Issue Type: Bug Components: Core Interceptors Affects Versions: 2.5.8 Reporter: James Chaplin In Struts 2.5.5 and prior 2.5.x/2.3.x, the I18nInterceptor honoured the locale state set programmatically via session (e.g. session.put(I18nInterceptor.DEFAULT_SESSION_ATTRIBUTE, localeForUser); ). Struts 2.5.8 ignores a locale state set programmatically via session (or at least it does so after the 1st failed lookup). *Issue cause: Changes in 2.5.8 storeLocale()/readStoredLocale() behaviour causes "storage == Storage.NONE" after 1st lookup failure, and i18nInterceptor will never again check session/cookie scopes for a locale. Appears to have been introduced with changes for WW-4722. *Bug elements: 1) readStoredLocale() - Never checks session/cookie level for a saved locale (after first lookup failure sets "storage = Storage.NONE"). 2) readStoredLocale() - The "if block" checks are inverted. When "storage == Storage.COOKIE" it checks session, when "storage == Storage.SESSION" it checks cookie (appears this was addressed in update to WW-4722 on 2017/01/11). 3) LocaleFinder/saveLocale() - No longer provides default lookup at session level, no longer preserves the storage level where the lookup succeded. *Suggested remedy: 1) Restore logic equivalent to 2.5.5 and earlier that will always check session and cookie scopes for Locale, irrespective of what the current i18n interceptor instance's storage value is set to. Change readStoredLocale() to check all scopes, restore storage scope state to LocaleFinder and calls to saveLocale(). Use LocaleFilender's scope state (tracking immediate request's locale storage level) during request processing (and if possible, leave i18n interceptor's scope fixed/unchanged). 2) Add logic to I18nInterceptor that preserves the initially configured storage type/scope for the lifetime of the i18n interceptor. This could be done by adding a new protected member to I18nInterceptor (e.g. protected configuredStorage), which gets initialized similarly to "storage" but only modified in the initial setLocaleStorage() call (so its value stays intact until explicitly changed by configuration). Either way it appears the I18nInterceptor needs a mechanism to ensure that it will always look for Locale at the session/cookie level (or at the very least the level that was initially configured for the interceptor), irrespective of what the current storage value is set to. Without such logic the i18n interceptor stops looking for anything other than the request/invocation context level (after the first lookup failure, irrespective of original storage setting). Tracking the configured storage scope (global) and the immediate request's scope (local) separately might be appropriate. *Note: API documentation for I18nInterceptor "storage" parameter appears incorrect as well. The new configuration parameter in 2.5.8 should indicate "localeStorage" for configuring the locale storage parameter (it indicates "storage" currently, but that fails as it doesn't match the setter's name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
