[jira] [Created] (WW-5304) Drop deprecated methods from ActionContext

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5304:
-

 Summary: Drop deprecated methods from ActionContext
 Key: WW-5304
 URL: https://issues.apache.org/jira/browse/WW-5304
 Project: Struts 2
  Issue Type: Improvement
Reporter: Lukasz Lenart
 Fix For: 6.2.0


Remove all the deprecated methods



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (WW-5280) Cleanup NoParameters interfaces

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reassigned WW-5280:
-

Assignee: Lukasz Lenart

> Cleanup NoParameters interfaces
> ---
>
> Key: WW-5280
> URL: https://issues.apache.org/jira/browse/WW-5280
> Project: Struts 2
>  Issue Type: Improvement
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are two {{NoParameters}} interfaces:
> - {{org.apache.struts2.interceptor.NoParameters}}
> - {{com.opensymphony.xwork2.interceptor.NoParameters}}
> the former isn't used by the {{ParametersInterceptor}}, just the second one. 
> Mark the old XWork interface as deprecated and just use the new from struts2 
> package (just move it into {{org.apache.struts2.action}} package)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (WW-5302) Autogenerated html ID bases on unevaluated value of the name sttribute

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reassigned WW-5302:
-

Assignee: Lukasz Lenart

> Autogenerated html ID bases on unevaluated value of the name sttribute
> --
>
> Key: WW-5302
> URL: https://issues.apache.org/jira/browse/WW-5302
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Using tag like this
> {code:html}
> entryEdit
>  action="%{#mainAction}!saveDraft" />
> {code}
> renders:
> {code:html}
>  value="Save as Draft" 
> id="entrymainAction__saveDraft" 
> name="action:entryAdd!saveDraft">
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WW-5303) Use escapedId instead instead of id

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5303:
-

 Summary: Use escapedId instead instead of id
 Key: WW-5303
 URL: https://issues.apache.org/jira/browse/WW-5303
 Project: Struts 2
  Issue Type: Improvement
  Components: Core Tags
Reporter: Lukasz Lenart
 Fix For: 7.0.0


Instead of using {{id="${parameters.id}"}} start using 
{{id="${parameters.escapedId}"}} when rendering tags.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5302) Autogenerated html ID bases on unevaluated value of the name sttribute

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5302:
--
Description: 
Using tag like this

{code:html}
entryEdit


{code}

renders:

{code:html}

{code}

  was:
Using tag like this

{code:html}
entryEdit


{code}

renders:

{code:html}

{code}


> Autogenerated html ID bases on unevaluated value of the name sttribute
> --
>
> Key: WW-5302
> URL: https://issues.apache.org/jira/browse/WW-5302
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>
> Using tag like this
> {code:html}
> entryEdit
>  action="%{#mainAction}!saveDraft" />
> {code}
> renders:
> {code:html}
>  value="Save as Draft" 
> id="entrymainAction__saveDraft" 
> name="action:entryAdd!saveDraft">
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WW-5302) Autogenerated html ID bases on unevaluated value of the name sttribute

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5302:
-

 Summary: Autogenerated html ID bases on unevaluated value of the 
name sttribute
 Key: WW-5302
 URL: https://issues.apache.org/jira/browse/WW-5302
 Project: Struts 2
  Issue Type: Bug
  Components: Core
Reporter: Lukasz Lenart
 Fix For: 6.2.0


Using tag like this

{code:html}
entryEdit


{code}

renders:

{code:html}

{code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5302) Autogenerated html ID bases on unevaluated value of the name sttribute

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5302:
--
Description: 
Using tag like this

{code:html}
entryEdit


{code}

renders:

{code:html}

{code}

  was:
Using tag like this

{code:html}
entryEdit


{code}

renders:

{code:html}

{code}


> Autogenerated html ID bases on unevaluated value of the name sttribute
> --
>
> Key: WW-5302
> URL: https://issues.apache.org/jira/browse/WW-5302
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core
>Reporter: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>
> Using tag like this
> {code:html}
> entryEdit
>  action="%{#mainAction}!saveDraft" />
> {code}
> renders:
> {code:html}
>  id="entrymainAction__saveDraft" name="action:entryAdd!saveDraft" 
> class="btn btn-warning">
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5280) Cleanup NoParameters interfaces

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5280:
--
Description: 
There are two {{NoParameters}} interfaces:
- {{org.apache.struts2.interceptor.NoParameters}}
- {{com.opensymphony.xwork2.interceptor.NoParameters}}

the former isn't used by the {{ParametersInterceptor}}, just the second one. 
Mark the old XWork interface as deprecated and just use the new from struts2 
package (just move it into {{org.apache.struts2.action}} package)

  was:
There are two {{NoParameters}} interfaces:
- {{org.apache.struts2.interceptor.NoParameters}}
- {{com.opensymphony.xwork2.interceptor.NoParameters}}

the former isn't used by the {{ParametersInterceptor}}, just the second one. 
Mark the old XWork interface and just use the new from struts2 package (just 
move it into {{org.apache.struts2.action}} package)


> Cleanup NoParameters interfaces
> ---
>
> Key: WW-5280
> URL: https://issues.apache.org/jira/browse/WW-5280
> Project: Struts 2
>  Issue Type: Improvement
>Reporter: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>
> There are two {{NoParameters}} interfaces:
> - {{org.apache.struts2.interceptor.NoParameters}}
> - {{com.opensymphony.xwork2.interceptor.NoParameters}}
> the former isn't used by the {{ParametersInterceptor}}, just the second one. 
> Mark the old XWork interface as deprecated and just use the new from struts2 
> package (just move it into {{org.apache.struts2.action}} package)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5300) Make Dispatcher methods overridable

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5300.
---
Resolution: Fixed

> Make Dispatcher methods overridable
> ---
>
> Key: WW-5300
> URL: https://issues.apache.org/jira/browse/WW-5300
> Project: Struts 2
>  Issue Type: Task
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> #prepareActionProxy is quite handy to be able to override for Confluence's 
> needs



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5299) Clean up ActionChainResult

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5299.
---
Resolution: Fixed

> Clean up ActionChainResult
> --
>
> Key: WW-5299
> URL: https://issues.apache.org/jira/browse/WW-5299
> Project: Struts 2
>  Issue Type: Task
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5298) Clean up StrutsVelocityContext

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5298.
---
Resolution: Fixed

> Clean up StrutsVelocityContext
> --
>
> Key: WW-5298
> URL: https://issues.apache.org/jira/browse/WW-5298
> Project: Struts 2
>  Issue Type: Task
>  Components: Plugin - Velocity
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Minor code clean up



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5295) s:date ignores LocalTime

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5295.
---
Resolution: Fixed

> s:date ignores LocalTime
> 
>
> Key: WW-5295
> URL: https://issues.apache.org/jira/browse/WW-5295
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Tags
>Affects Versions: 6.1.2
>Reporter: nikos dimitrakas
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> After upgrading from v5 to v6 I got an error with s:date not working with 
> java.sql.Time. Since WW-5272 is not yet released, I thought I will convert 
> java.sql.Time to LocalTime by simply changing the ognl expression in my 
> s:date tags. 
> For example from 
> 
> to
> 
> This way there was no UnsupportedOperationException, but it turns out that 
> nothing happens. In the class org.apache.struts2.components.Date there is no 
> case for LocalTime and we end up with a log message LocalTime isn't 
> supported!.
> There should be support for both java.sql.Time (as per WW-5272) and for 
> LocalTime with similar behaviour.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5289) Execute and Wait Interceptor prevents JVM shutdown

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5289.
---
Resolution: Fixed

> Execute and Wait Interceptor prevents JVM shutdown
> --
>
> Key: WW-5289
> URL: https://issues.apache.org/jira/browse/WW-5289
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Interceptors
>Affects Versions: 6.1.1
>Reporter: KON-SUN-TACK
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Hi Struts 2 team,
> We are using the Execute and Wait Interceptor as following:
> {quote}class="my.sample.longrun.action.LongRunAction"
>   method="longRunLaunch">
>   
>   
> 500
> 500
>   
>   /my/sample/wait.jsp
>   /my/sample/success.jsp
> {quote}
> - with Struts 6.0.3, it works fine
> - with Struts 6.1.1, it works fine... but JVM shutdown is hanging
> We are running: Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> I tried to compare thread dumps and only found this extra one with Struts 
> 6.1.1:
> {quote}"pool-5-thread-1" #129 prio=5 os_prio=0 cpu=0.00ms elapsed=21.47s 
> tid=0x01b39a917800 nid=0x3cb0 waiting on condition  [0x0068c4fff000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
> - parking to wait for  <0xe4ca75b0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(java.base@11.0.10/LinkedBlockingQueue.java:433)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.10/ThreadPoolExecutor.java:1054)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1114)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
>Locked ownable synchronizers:
> - None{quote}
> Regards,
> Jean.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5301) Impossible to select alternate default VelocityManager bean

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706751#comment-17706751
 ] 

Lukasz Lenart commented on WW-5301:
---

So this is a bug then, it supposed to work the same as 
{{StrutsBeanSelectionProvider}} but just to allow _delegate_ such logic into 
plugins.

> Impossible to select alternate default VelocityManager bean
> ---
>
> Key: WW-5301
> URL: https://issues.apache.org/jira/browse/WW-5301
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core, Plugin - Velocity
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Major
> Fix For: 6.2.0
>
>
> I'm possibly missing something here but as far as I can tell 
> struts-plugin.xml is always loaded before struts.xml.
> This means the default VelocityManager bean (#registerBeanSelection) will 
> always be selected before the default bean can be configured via 
> {{struts.velocity.manager.classname}}
> Changing the load order here probably isn't a good solution either.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5301) Impossible to select alternate default VelocityManager bean

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706739#comment-17706739
 ] 

Lukasz Lenart commented on WW-5301:
---

It should work the same because of
{code:xml}

{code}

> Impossible to select alternate default VelocityManager bean
> ---
>
> Key: WW-5301
> URL: https://issues.apache.org/jira/browse/WW-5301
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core, Plugin - Velocity
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Major
> Fix For: 6.2.0
>
>
> I'm possibly missing something here but as far as I can tell 
> struts-plugin.xml is always loaded before struts.xml.
> This means the default VelocityManager bean (#registerBeanSelection) will 
> always be selected before the default bean can be configured via 
> {{struts.velocity.manager.classname}}
> Changing the load order here probably isn't a good solution either.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5301) Impossible to select alternate default VelocityManager bean

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5301:
--
Fix Version/s: 6.2.0

> Impossible to select alternate default VelocityManager bean
> ---
>
> Key: WW-5301
> URL: https://issues.apache.org/jira/browse/WW-5301
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core, Plugin - Velocity
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Major
> Fix For: 6.2.0
>
>
> I'm possibly missing something here but as far as I can tell 
> struts-plugin.xml is always loaded before struts.xml.
> This means the default VelocityManager bean (#registerBeanSelection) will 
> always be selected before the default bean can be configured via 
> {{struts.velocity.manager.classname}}
> Changing the load order here probably isn't a good solution either.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5301) Impossible to select alternate default VelocityManager bean

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706719#comment-17706719
 ] 

Lukasz Lenart commented on WW-5301:
---

Please take a look on this [PR|https://github.com/apache/struts/pull/673/files] 
- I can modify VelocityManager setup to allow override its implementation in a 
similar way.

> Impossible to select alternate default VelocityManager bean
> ---
>
> Key: WW-5301
> URL: https://issues.apache.org/jira/browse/WW-5301
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core, Plugin - Velocity
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Major
>
> I'm possibly missing something here but as far as I can tell 
> struts-plugin.xml is always loaded before struts.xml.
> This means the default VelocityManager bean (#registerBeanSelection) will 
> always be selected before the default bean can be configured via 
> {{struts.velocity.manager.classname}}
> Changing the load order here probably isn't a good solution either.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5301) Impossible to select alternate default VelocityManager bean

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706296#comment-17706296
 ] 

Lukasz Lenart commented on WW-5301:
---

Right, I messed up the files, {{struts.xml}} should be loaded as the last one. 
The current order is like this 
{{struts-default.xml,struts-plugin.xml,struts.xml}}. And probably the 
_extension point_ needs some tuning, see how I implemented using different 
[DateFormatters|https://github.com/apache/struts/pull/529/files] - I defined 
two beans with unique names and defined an alias
{code:java}
alias(DateFormatter.class, StrutsConstants.STRUTS_DATE_FORMATTER, builder, 
props, Scope.SINGLETON);
{code}
and assigned one those beans as a default one
{code}
struts.date.formatter=dateTimeFormatter
{code}

> Impossible to select alternate default VelocityManager bean
> ---
>
> Key: WW-5301
> URL: https://issues.apache.org/jira/browse/WW-5301
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core, Plugin - Velocity
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Major
>
> I'm possibly missing something here but as far as I can tell 
> struts-plugin.xml is always loaded before struts.xml.
> Changing the load order here probably isn't a good solution either.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5301) Impossible to select alternate default VelocityManager bean

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17706273#comment-17706273
 ] 

Lukasz Lenart commented on WW-5301:
---

That's wrong, {{struts.xml}} must be loaded first in other way all the 
dependencies are gone. The case here is that the _extension point_ is right now 
defined in the Velocity plugin, so you must load the struts-plugin.xml to get 
the extension point and then you can define your own {{VelocityManager}}

> Impossible to select alternate default VelocityManager bean
> ---
>
> Key: WW-5301
> URL: https://issues.apache.org/jira/browse/WW-5301
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core, Plugin - Velocity
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Major
>
> I'm possibly missing something here but as far as I can tell 
> struts-plugin.xml is always loaded before struts.xml.
> Changing the load order here probably isn't a good solution either.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5297) Decorator not working after invalidating session

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705915#comment-17705915
 ] 

Lukasz Lenart commented on WW-5297:
---

How do you perform session invalidation? Could you share the code?

> Decorator not working after invalidating session
> 
>
> Key: WW-5297
> URL: https://issues.apache.org/jira/browse/WW-5297
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Tags, Plugin - SiteMesh
>Affects Versions: 6.1.2
>Reporter: nikos dimitrakas
>Priority: Major
>
> When trying to upgrade from 2.5 to 6.1.2 I get a strange behaviour when 
> decorating a jsp.
> I have an action that is used to log out a user. The action is basically only 
> invalidating the session and then goes to the jsp. One of the interceptors is 
> using sitemesh and applies the specified decorator.
> With Struts 2.5 this worked fine. But with Struts 6.1.2 (probably all the 
> 6.x) I get an error "Session already invalidated" when getAttribute is called 
> from org.apache.struts2.dispatcher.SessionMap. Here is the relevant part of 
> the stacktrace:
> Caused by: java.lang.IllegalStateException: getAttribute: Session already 
> invalidated
>     at 
> org.apache.catalina.session.StandardSession.getAttribute(StandardSession.java:1148)
>     at 
> org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:102)
>     at org.apache.struts2.dispatcher.SessionMap.get(SessionMap.java:157)
>     at org.apache.struts2.components.UIBean.evaluateParams(UIBean.java:879)
>     at org.apache.struts2.components.Head.evaluateParams(Head.java:71)
>     at org.apache.struts2.components.UIBean.end(UIBean.java:550)
>     at 
> org.apache.struts2.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:40)
> There is nothing about this changed behaviour in the migration guide from 
> Struts 2.5 to 6. Is this a bug introduced in 6.x? Or is this by design? 
> From what I can see, the error occurs when an s:head inside the decorator is 
> evaluated.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5297) Decorator not working after invalidating session

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705913#comment-17705913
 ] 

Lukasz Lenart commented on WW-5297:
---

It's caused by introducing support for Content Security Policy, basically this 
part:

{code:java}
Object nonceValue = session != null ? session.get("nonce") : null;
{code}

> Decorator not working after invalidating session
> 
>
> Key: WW-5297
> URL: https://issues.apache.org/jira/browse/WW-5297
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Tags, Plugin - SiteMesh
>Affects Versions: 6.1.2
>Reporter: nikos dimitrakas
>Priority: Major
>
> When trying to upgrade from 2.5 to 6.1.2 I get a strange behaviour when 
> decorating a jsp.
> I have an action that is used to log out a user. The action is basically only 
> invalidating the session and then goes to the jsp. One of the interceptors is 
> using sitemesh and applies the specified decorator.
> With Struts 2.5 this worked fine. But with Struts 6.1.2 (probably all the 
> 6.x) I get an error "Session already invalidated" when getAttribute is called 
> from org.apache.struts2.dispatcher.SessionMap. Here is the relevant part of 
> the stacktrace:
> Caused by: java.lang.IllegalStateException: getAttribute: Session already 
> invalidated
>     at 
> org.apache.catalina.session.StandardSession.getAttribute(StandardSession.java:1148)
>     at 
> org.apache.catalina.session.StandardSessionFacade.getAttribute(StandardSessionFacade.java:102)
>     at org.apache.struts2.dispatcher.SessionMap.get(SessionMap.java:157)
>     at org.apache.struts2.components.UIBean.evaluateParams(UIBean.java:879)
>     at org.apache.struts2.components.Head.evaluateParams(Head.java:71)
>     at org.apache.struts2.components.UIBean.end(UIBean.java:550)
>     at 
> org.apache.struts2.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:40)
> There is nothing about this changed behaviour in the migration guide from 
> Struts 2.5 to 6. Is this a bug introduced in 6.x? Or is this by design? 
> From what I can see, the error occurs when an s:head inside the decorator is 
> evaluated.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5289) Execute and Wait Interceptor prevents JVM shutdown

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17705069#comment-17705069
 ] 

Lukasz Lenart commented on WW-5289:
---

[~jeanjean] PR is ready https://github.com/apache/struts/pull/673

> Execute and Wait Interceptor prevents JVM shutdown
> --
>
> Key: WW-5289
> URL: https://issues.apache.org/jira/browse/WW-5289
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Interceptors
>Affects Versions: 6.1.1
>Reporter: KON-SUN-TACK
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi Struts 2 team,
> We are using the Execute and Wait Interceptor as following:
> {quote}class="my.sample.longrun.action.LongRunAction"
>   method="longRunLaunch">
>   
>   
> 500
> 500
>   
>   /my/sample/wait.jsp
>   /my/sample/success.jsp
> {quote}
> - with Struts 6.0.3, it works fine
> - with Struts 6.1.1, it works fine... but JVM shutdown is hanging
> We are running: Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> I tried to compare thread dumps and only found this extra one with Struts 
> 6.1.1:
> {quote}"pool-5-thread-1" #129 prio=5 os_prio=0 cpu=0.00ms elapsed=21.47s 
> tid=0x01b39a917800 nid=0x3cb0 waiting on condition  [0x0068c4fff000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
> - parking to wait for  <0xe4ca75b0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(java.base@11.0.10/LinkedBlockingQueue.java:433)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.10/ThreadPoolExecutor.java:1054)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1114)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
>Locked ownable synchronizers:
> - None{quote}
> Regards,
> Jean.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5293) Allow loading XML configuration from other than filesystem

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5293.
---
Resolution: Fixed

> Allow loading XML configuration from other than filesystem
> --
>
> Key: WW-5293
> URL: https://issues.apache.org/jira/browse/WW-5293
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Split the filesystem functionality from XmlConfigurationProvider so that we 
> can load XML documents directly.
> Also allow greater flexibility in subclassing by splitting the build 
> action/interceptor/result configs into their own methods.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5288) Make excluded package exemption logic more strict

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5288.
---
Resolution: Fixed

> Make excluded package exemption logic more strict
> -
>
> Key: WW-5288
> URL: https://issues.apache.org/jira/browse/WW-5288
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Following on from the discussion in the comments on WW-5268 - exempting 
> classes from excluded packages should only be done if unavoidable.
> Given this, I realised we should make the exemption logic more strict to 
> prevent incorrect use and inadvertent exempting of more OGNL expressions than 
> intended.
> * Currently, the exempted classes also match against superclasses. This is 
> unnecessary and we can match against only the specific class.
> * Currently, an exemption against either the target or member class suffices. 
> This can be made more strict by requiring an exemption for the class which 
> matches the excluded package specifically, which could be either or both.
> * The JavaDoc for the options should be very explicit in what each 
> configuration option achieves to prevent incorrect uses.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5296) Wrong DTD version

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5296:
--
Fix Version/s: 6.2.0

> Wrong DTD version 
> --
>
> Key: WW-5296
> URL: https://issues.apache.org/jira/browse/WW-5296
> Project: Struts 2
>  Issue Type: Bug
>  Components: Plugin - SiteMesh, Plugin - Spring
>Affects Versions: 6.1.2
>Reporter: nikos dimitrakas
>Priority: Major
> Fix For: 6.2.0
>
>
> The DOCTYPE definition in all struts-plugin.xml seems to not have been 
> updated to the new one. The old DTD
>          "-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"
>         "http://struts.apache.org/dtds/struts-2.5.dtd;>
> should be changed to 
>          "-//Apache Software Foundation//DTD Struts Configuration 6.0//EN"
>         "https://struts.apache.org/dtds/struts-6.0.dtd;>
> for any version 6.x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5296) Wrong DTD version

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17703047#comment-17703047
 ] 

Lukasz Lenart commented on WW-5296:
---

That shouldn't be a problem, Struts supports all the DTD versions. You must 
upgrade DTD only if you want to use a new functionality which in this case is 
{{}}

> Wrong DTD version 
> --
>
> Key: WW-5296
> URL: https://issues.apache.org/jira/browse/WW-5296
> Project: Struts 2
>  Issue Type: Bug
>  Components: Plugin - SiteMesh, Plugin - Spring
>Affects Versions: 6.1.2
>Reporter: nikos dimitrakas
>Priority: Major
>
> The DOCTYPE definition in all struts-plugin.xml seems to not have been 
> updated to the new one. The old DTD
>          "-//Apache Software Foundation//DTD Struts Configuration 2.5//EN"
>         "http://struts.apache.org/dtds/struts-2.5.dtd;>
> should be changed to 
>          "-//Apache Software Foundation//DTD Struts Configuration 6.0//EN"
>         "https://struts.apache.org/dtds/struts-6.0.dtd;>
> for any version 6.x



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5294) s:url tag usage in a public page triggers a warning to not expose JSP pages directly

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700804#comment-17700804
 ] 

Lukasz Lenart commented on WW-5294:
---

Hmm... interesting, I will re-open this issue to investigate the case with 
{{s:textfield}}, thanks for pointing this out :)

> s:url tag usage in a public page triggers a warning to not expose JSP pages 
> directly 
> -
>
> Key: WW-5294
> URL: https://issues.apache.org/jira/browse/WW-5294
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.2
> Environment: Ubuntu 20, Java 8, Tomcat 9
>Reporter: Erica Kane
>Priority: Major
> Fix For: 6.2.0
>
>
> I have a number of public pages that use the {{}} tags with no issues. 
> But one page uses an  {{}} tag, and every time it is visited I get a 
> warning on our logs the Action invocation context is null, and that JSP pages 
> should not be exposed directly. This is an informational page only, and I 
> can't think why the URL tag is unsafe to use while the a tag is safe. I am 
> assuming this is a bug, but of course if there is an issue with the URL tag 
> on a public page I would like to know.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Reopened] (WW-5294) s:url tag usage in a public page triggers a warning to not expose JSP pages directly

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reopened WW-5294:
---
  Assignee: Lukasz Lenart

> s:url tag usage in a public page triggers a warning to not expose JSP pages 
> directly 
> -
>
> Key: WW-5294
> URL: https://issues.apache.org/jira/browse/WW-5294
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.2
> Environment: Ubuntu 20, Java 8, Tomcat 9
>Reporter: Erica Kane
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>
> I have a number of public pages that use the {{}} tags with no issues. 
> But one page uses an  {{}} tag, and every time it is visited I get a 
> warning on our logs the Action invocation context is null, and that JSP pages 
> should not be exposed directly. This is an informational page only, and I 
> can't think why the URL tag is unsafe to use while the a tag is safe. I am 
> assuming this is a bug, but of course if there is an issue with the URL tag 
> on a public page I would like to know.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5294) s:url tag usage in a public page triggers a warning to not expose JSP pages directly

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17700537#comment-17700537
 ] 

Lukasz Lenart commented on WW-5294:
---

Great! You can use a very simple setup to define actions:

{code:xml}

/WEB-INF/index.jsp

{code}

> s:url tag usage in a public page triggers a warning to not expose JSP pages 
> directly 
> -
>
> Key: WW-5294
> URL: https://issues.apache.org/jira/browse/WW-5294
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.2
> Environment: Ubuntu 20, Java 8, Tomcat 9
>Reporter: Erica Kane
>Priority: Major
> Fix For: 6.2.0
>
>
> I have a number of public pages that use the {{}} tags with no issues. 
> But one page uses an  {{}} tag, and every time it is visited I get a 
> warning on our logs the Action invocation context is null, and that JSP pages 
> should not be exposed directly. This is an informational page only, and I 
> can't think why the URL tag is unsafe to use while the a tag is safe. I am 
> assuming this is a bug, but of course if there is an issue with the URL tag 
> on a public page I would like to know.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5251) Remove deprecated interfaces used with ServletConfigInterceptor

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5251.
---
Resolution: Fixed

> Remove deprecated interfaces used with ServletConfigInterceptor
> ---
>
> Key: WW-5251
> URL: https://issues.apache.org/jira/browse/WW-5251
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core Interceptors
>Reporter: Lukasz Lenart
>Assignee: Stefaan Dutry
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{ServletConfigInterceptor}} supports a bunch of deprecated interfaces which 
> already have proper replacement and they should be removed
> * {{org.apache.struts2.util.ServletContextAware}}
> * {{org.apache.struts2.interceptor.ServletRequestAware}}
> * {{org.apache.struts2.interceptor.ServletResponseAware}}
> * {{org.apache.struts2.interceptor.ParameterAware}}
> * {{org.apache.struts2.interceptor.SessionAware}}
> * {{org.apache.struts2.interceptor.ApplicationAware}}
> * {{org.apache.struts2.interceptor.PrincipalAware}}
> all these interfaces have proper replacement in {{org.apache.struts2.action}} 
> package



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5253) Remove deprecated methods from DefaultUrlHelper

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5253.
---
Resolution: Fixed

> Remove deprecated methods from DefaultUrlHelper
> ---
>
> Key: WW-5253
> URL: https://issues.apache.org/jira/browse/WW-5253
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Stefaan Dutry
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Related to WW-4692



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5295) s:date ignores LocalTime

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5295:
--
Fix Version/s: 6.2.0

> s:date ignores LocalTime
> 
>
> Key: WW-5295
> URL: https://issues.apache.org/jira/browse/WW-5295
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Tags
>Affects Versions: 6.1.2
>Reporter: nikos dimitrakas
>Priority: Major
> Fix For: 6.2.0
>
>
> After upgrading from v5 to v6 I got an error with s:date not working with 
> java.sql.Time. Since WW-5272 is not yet released, I thought I will convert 
> java.sql.Time to LocalTime by simply changing the ognl expression in my 
> s:date tags. 
> For example from 
> 
> to
> 
> This way there was no UnsupportedOperationException, but it turns out that 
> nothing happens. In the class org.apache.struts2.components.Date there is no 
> case for LocalTime and we end up with a log message LocalTime isn't 
> supported!.
> There should be support for both java.sql.Time (as per WW-5272) and for 
> LocalTime with similar behaviour.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5243) Removes support for "struts.mapper.action.prefix.crossNamespaces"

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5243.
---
Resolution: Fixed

> Removes support for "struts.mapper.action.prefix.crossNamespaces"
> -
>
> Key: WW-5243
> URL: https://issues.apache.org/jira/browse/WW-5243
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Lukasz Lenart
>Assignee: Stefaan Dutry
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Remove support for using {{struts.mapper.action.prefix.crossNamespaces}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5294) s:url tag usage in a public page triggers a warning to not expose JSP pages directly

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699677#comment-17699677
 ] 

Lukasz Lenart commented on WW-5294:
---

And that's the case - you use Struts tags out of the action scope, which means 
you are omitting the whole internal flow like interceptors and security checks.

This can raise security concerns
https://struts.apache.org/security/#never-expose-jsp-files-directly

> s:url tag usage in a public page triggers a warning to not expose JSP pages 
> directly 
> -
>
> Key: WW-5294
> URL: https://issues.apache.org/jira/browse/WW-5294
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.2
> Environment: Ubuntu 20, Java 8, Tomcat 9
>Reporter: Erica Kane
>Priority: Major
> Fix For: 6.2.0
>
>
> I have a number of public pages that use the {{}} tags with no issues. 
> But one page uses an  {{}} tag, and every time it is visited I get a 
> warning on our logs the Action invocation context is null, and that JSP pages 
> should not be exposed directly. This is an informational page only, and I 
> can't think why the URL tag is unsafe to use while the a tag is safe. I am 
> assuming this is a bug, but of course if there is an issue with the URL tag 
> on a public page I would like to know.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5294) s:url tag usage in a public page triggers a warning to not expose JSP pages directly

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699643#comment-17699643
 ] 

Lukasz Lenart commented on WW-5294:
---

Is this page running behind an action? I mean, do you have an action which is 
hit first and then the request is forwarded to a JSP page?

> s:url tag usage in a public page triggers a warning to not expose JSP pages 
> directly 
> -
>
> Key: WW-5294
> URL: https://issues.apache.org/jira/browse/WW-5294
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.2
> Environment: Ubuntu 20, Java 8, Tomcat 9
>Reporter: Erica Kane
>Priority: Major
> Fix For: 6.2.0
>
>
> I have a number of public pages that use the {{}} tags with no issues. 
> But one page uses an  {{}} tag, and every time it is visited I get a 
> warning on our logs the Action invocation context is null, and that JSP pages 
> should not be exposed directly. This is an informational page only, and I 
> can't think why the URL tag is unsafe to use while the a tag is safe. I am 
> assuming this is a bug, but of course if there is an issue with the URL tag 
> on a public page I would like to know.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5294) s:url tag usage in a public page triggers a warning to not expose JSP pages directly

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5294:
--
Fix Version/s: 6.2.0

> s:url tag usage in a public page triggers a warning to not expose JSP pages 
> directly 
> -
>
> Key: WW-5294
> URL: https://issues.apache.org/jira/browse/WW-5294
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.2
> Environment: Ubuntu 20, Java 8, Tomcat 9
>Reporter: Erica Kane
>Priority: Major
> Fix For: 6.2.0
>
>
> I have a number of public pages that use the {{}} tags with no issues. 
> But one page uses an  {{}} tag, and every time it is visited I get a 
> warning on our logs the Action invocation context is null, and that JSP pages 
> should not be exposed directly. This is an informational page only, and I 
> can't think why the URL tag is unsafe to use while the a tag is safe. I am 
> assuming this is a bug, but of course if there is an issue with the URL tag 
> on a public page I would like to know.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5177) Support testing with JUnit 5

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17699618#comment-17699618
 ] 

Lukasz Lenart commented on WW-5177:
---

Does JUnit 5 require JDK17?

> Support testing with JUnit 5
> 
>
> Key: WW-5177
> URL: https://issues.apache.org/jira/browse/WW-5177
> Project: Struts 2
>  Issue Type: New Feature
>  Components: Plugin - JUnit
>Reporter: Ganapati
>Priority: Major
>  Labels: features
> Fix For: 7.0.0
>
>
> Hi Team,
>  
> Currently, struts2-junit-plugin supports testing of Spring based struts 
> actions with on JUnit 4 and 3 using {{StrutsSpringTestCase}} and 
> {{StrutsSpringJUnit4TestCase}}. The request is to add support for JUnit 5 
> with something similar to {{StrutsSpringJUnit5TestCase}}. I understand that 
> we can run JUnit 4 tests using {{junit-vintage-engine}} but in our case we 
> need to combine with other JUnit 5 based extensions - some custom and some 
> already available - Spring, Testcontainers, etc.
>  
> There is no issue in the current issues list to support this. Can I know if 
> there is any plan to support the same? I am happy to make contribution if 
> some one can guide me.
> ---
> For POC purposes, I created parallels to {{XWorkJUnit4TestCase}}, 
> {{StrutsJUnit4TestCase}}, and {{StrutsSpringJUnit4TestCase}} with much of the 
> code remaining same. I was able to run tests using Spring's {{ExtendWith}} 
> with a workaround and the workaround needs to be fixed properly.
>  
> Thanks.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5196) Make RequestMap and ApplicationMap to use generics, also correct SessionMap to always be of type

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5196.
---
Resolution: Fixed

> Make RequestMap and ApplicationMap to use generics, also correct SessionMap 
> to always be of type 
> -
>
> Key: WW-5196
> URL: https://issues.apache.org/jira/browse/WW-5196
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Stefaan Dutry
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Right now these implementations of {{Map}} doesn't use generics or they are 
> created without specifying proper type for key and value



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5266) Add configuration option for a per-file max size for multipart requests

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5266.
---
Resolution: Fixed

> Add configuration option for a per-file max size for multipart requests
> ---
>
> Key: WW-5266
> URL: https://issues.apache.org/jira/browse/WW-5266
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In addition to the existing `struts.multipart.maxSize`, allow the 
> configuration of a per-file max size using `struts.multipart.maxFileSize`



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5292) Allow overriding of Operations classes in two filter setup and assorted clean up

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5292.
---
Resolution: Fixed

> Allow overriding of Operations classes in two filter setup and assorted clean 
> up
> 
>
> Key: WW-5292
> URL: https://issues.apache.org/jira/browse/WW-5292
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This is already implemented for the single filter setup in [this 
> commit|https://github.com/apache/struts/commit/6651089e823d2d2934f0597ab690ea9322f584e3].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5285) Upgrade commons-fileupload to ver 1.5 and add option to limit number of accepted files

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5285.
---
Resolution: Fixed

> Upgrade commons-fileupload to ver 1.5 and add option to limit number of 
> accepted files
> --
>
> Key: WW-5285
> URL: https://issues.apache.org/jira/browse/WW-5285
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0, 6.1.2
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> With a new version of commons-fileupload a new option has been added to limit 
> number of uploaded files (not size, but number). It would be good to support 
> this in Struts as well by adding a new constant "struts.multipart.maxFiles"
> [https://github.com/apache/commons-fileupload/pull/185]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5285) Upgrade commons-fileupload to ver 1.5 and add option to limit number of accepted files

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5285:
--
Fix Version/s: 6.1.2

> Upgrade commons-fileupload to ver 1.5 and add option to limit number of 
> accepted files
> --
>
> Key: WW-5285
> URL: https://issues.apache.org/jira/browse/WW-5285
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0, 6.1.2
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> With a new version of commons-fileupload a new option has been added to limit 
> number of uploaded files (not size, but number). It would be good to support 
> this in Struts as well by adding a new constant "struts.multipart.maxFiles"
> [https://github.com/apache/commons-fileupload/pull/185]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Reopened] (WW-5292) Allow overriding of Operations classes in two filter setup and assorted clean up

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reopened WW-5292:
---

> Allow overriding of Operations classes in two filter setup and assorted clean 
> up
> 
>
> Key: WW-5292
> URL: https://issues.apache.org/jira/browse/WW-5292
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is already implemented for the single filter setup in [this 
> commit|https://github.com/apache/struts/commit/6651089e823d2d2934f0597ab690ea9322f584e3].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5292) Allow overriding of Operations classes in two filter setup and assorted clean up

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5292.
---
Resolution: Fixed

Nice, thanks a lot!

> Allow overriding of Operations classes in two filter setup and assorted clean 
> up
> 
>
> Key: WW-5292
> URL: https://issues.apache.org/jira/browse/WW-5292
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> This is already implemented for the single filter setup in [this 
> commit|https://github.com/apache/struts/commit/6651089e823d2d2934f0597ab690ea9322f584e3].



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5267) Allow SiteMesh to run on requests that are not Struts actions, but SiteMesh requires ActionContext

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697415#comment-17697415
 ] 

Lukasz Lenart commented on WW-5267:
---

Maybe this should be embedded into Sitemesh support or the Sitemesh plugin 
should deliver a dedicate {{StrutsPrepareFilter}} which will initiate the 
context

> Allow SiteMesh to run on requests that are not Struts actions, but SiteMesh 
> requires ActionContext
> --
>
> Key: WW-5267
> URL: https://issues.apache.org/jira/browse/WW-5267
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> There are scenarios where you may want to exclude a request from Struts 
> filtering/processing using `struts.action.excludePattern` as it is not a 
> Struts action and/or having Struts consume/parse the multipart is undesirable.
> However, you may still want that request to undergo filtering such as 
> SiteMesh, which requires the ActionContext to be present.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5287) Make excludedPackageNames check more stringent

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697280#comment-17697280
 ] 

Lukasz Lenart commented on WW-5287:
---

You can change its name to avoid further confusion

> Make excludedPackageNames check more stringent
> --
>
> Key: WW-5287
> URL: https://issues.apache.org/jira/browse/WW-5287
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
>
> {{struts.excludedPackageNames}} and {{struts.excludedPackageNamePatterns}} 
> only do a check against the package of the declaring and target classes of an 
> OGNL expression target.
> For more robust security, we should be checking the package of every 
> superclass and implemented interface. This will also be more consistent with 
> {{struts.excludedClasses}} which does an {{#isAssignableFrom}} check.
> This is rather straightforward by leveraging the following methods, but will 
> come at a slight performance cost:
> {{org.apache.commons.lang3.ClassUtils#getAllInterfaces}}
> {{org.apache.commons.lang3.ClassUtils#getAllSuperclasses}}
> Additionally, we should ensure that for any 
> {{struts.excludedPackageExemptClasses}}, an assignable class exists for every 
> matching excluded package (any matching interface or superclass).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5291) Integrating struts2 into oss-fuzz

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697264#comment-17697264
 ] 

Lukasz Lenart commented on WW-5291:
---

[~schaich] thanks for preparing the initial setup. As far I understand, I 
should prepare a PR with assigning a reviewer to the project, I should add the 
email here [1]

[1] 
https://github.com/google/oss-fuzz/blob/master/projects/struts/project.yaml#L7

correct?

> Integrating struts2 into oss-fuzz
> -
>
> Key: WW-5291
> URL: https://issues.apache.org/jira/browse/WW-5291
> Project: Struts 2
>  Issue Type: Improvement
>Reporter: A. Schaich
>Priority: Minor
>
> Hi all,
> we have prepared the [Initial 
> Integration|https://github.com/google/oss-fuzz/pull/9852] of struts2 into 
> [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will provide more 
> security for your project.
>  
> *Why do you need Fuzzing?*
> The Code Intelligence JVM fuzzer 
> [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found 
> [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] 
> in open source projects including for example 
> [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], 
> [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or 
> [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. 
> Fuzzing proved to be very effective having no false positives. It provides a 
> crashing input which helps you to reproduce and debug any finding easily. The 
> integration of your project into the OSS-Fuzz platform will enable continuous 
> fuzzing of your project by 
> [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer].
>  
> *What do you need to do?*
> The integration requires the maintainer or one established project commiter 
> to deal with the bug reports.
> You need to create or provide one email address that is associated with a 
> google account as per 
> [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/].
>  When a bug is found, you will receive an email that will provide you with 
> access to ClusterFuzz, crash reports, code coverage reports and fuzzer 
> statistics. More than 1 person can be included.
>  
> *How Code Intelligence can support?*
> We will continue to add more fuzz targets to improve code coverage over time. 
> Furthermore, we are permanently enhancing fuzzing technologies by developing 
> new fuzzers and more bug detectors.
>  
> Please let me know if you have any questions regarding fuzzing or the 
> OSS-Fuzz integration.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5290) Refactor ConfigurationManager

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5290.
---
Resolution: Fixed

> Refactor ConfigurationManager
> -
>
> Key: WW-5290
> URL: https://issues.apache.org/jira/browse/WW-5290
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This class needs an overhaul:
> * Readability
> * Performance
> * Thread safety



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5287) Make excludedPackageNames check more stringent

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697240#comment-17697240
 ] 

Lukasz Lenart commented on WW-5287:
---

We have two {{SecurityMemberAccessTest}} in two different packages to test two 
different behaviours. One test is in the package 
{{com.opensymphony.xwork2.ognl}} which is excluded.

> Make excludedPackageNames check more stringent
> --
>
> Key: WW-5287
> URL: https://issues.apache.org/jira/browse/WW-5287
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
>
> {{struts.excludedPackageNames}} and {{struts.excludedPackageNamePatterns}} 
> only do a check against the package of the declaring and target classes of an 
> OGNL expression target.
> For more robust security, we should be checking the package of every 
> superclass and implemented interface. This will also be more consistent with 
> {{struts.excludedClasses}} which does an {{#isAssignableFrom}} check.
> This is rather straightforward by leveraging the following methods, but will 
> come at a slight performance cost:
> {{org.apache.commons.lang3.ClassUtils#getAllInterfaces}}
> {{org.apache.commons.lang3.ClassUtils#getAllSuperclasses}}
> Additionally, we should ensure that for any 
> {{struts.excludedPackageExemptClasses}}, an assignable class exists for every 
> matching excluded package (any matching interface or superclass).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5289) Execute and Wait Interceptor prevents JVM shutdown

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697008#comment-17697008
 ] 

Lukasz Lenart commented on WW-5289:
---

osm! this means we should always use our internal DI mechanism, thanks a lot 
for taking time and finding this issue, really appreciate it :)

> Execute and Wait Interceptor prevents JVM shutdown
> --
>
> Key: WW-5289
> URL: https://issues.apache.org/jira/browse/WW-5289
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Interceptors
>Affects Versions: 6.1.1
>Reporter: KON-SUN-TACK
>Priority: Major
> Fix For: 6.2.0
>
>
> Hi Struts 2 team,
> We are using the Execute and Wait Interceptor as following:
> {quote}class="my.sample.longrun.action.LongRunAction"
>   method="longRunLaunch">
>   
>   
> 500
> 500
>   
>   /my/sample/wait.jsp
>   /my/sample/success.jsp
> {quote}
> - with Struts 6.0.3, it works fine
> - with Struts 6.1.1, it works fine... but JVM shutdown is hanging
> We are running: Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> I tried to compare thread dumps and only found this extra one with Struts 
> 6.1.1:
> {quote}"pool-5-thread-1" #129 prio=5 os_prio=0 cpu=0.00ms elapsed=21.47s 
> tid=0x01b39a917800 nid=0x3cb0 waiting on condition  [0x0068c4fff000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
> - parking to wait for  <0xe4ca75b0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(java.base@11.0.10/LinkedBlockingQueue.java:433)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.10/ThreadPoolExecutor.java:1054)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1114)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
>Locked ownable synchronizers:
> - None{quote}
> Regards,
> Jean.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5289) Execute and Wait Interceptor prevents JVM shutdown

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695812#comment-17695812
 ] 

Lukasz Lenart commented on WW-5289:
---

Also added missing documentation about that
https://github.com/apache/struts-site/pull/187

> Execute and Wait Interceptor prevents JVM shutdown
> --
>
> Key: WW-5289
> URL: https://issues.apache.org/jira/browse/WW-5289
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Interceptors
>Affects Versions: 6.1.1
>Reporter: KON-SUN-TACK
>Priority: Major
> Fix For: 6.2.0
>
>
> Hi Struts 2 team,
> We are using the Execute and Wait Interceptor as following:
> {quote}class="my.sample.longrun.action.LongRunAction"
>   method="longRunLaunch">
>   
>   
> 500
> 500
>   
>   /my/sample/wait.jsp
>   /my/sample/success.jsp
> {quote}
> - with Struts 6.0.3, it works fine
> - with Struts 6.1.1, it works fine... but JVM shutdown is hanging
> We are running: Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> I tried to compare thread dumps and only found this extra one with Struts 
> 6.1.1:
> {quote}"pool-5-thread-1" #129 prio=5 os_prio=0 cpu=0.00ms elapsed=21.47s 
> tid=0x01b39a917800 nid=0x3cb0 waiting on condition  [0x0068c4fff000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
> - parking to wait for  <0xe4ca75b0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(java.base@11.0.10/LinkedBlockingQueue.java:433)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.10/ThreadPoolExecutor.java:1054)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1114)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
>Locked ownable synchronizers:
> - None{quote}
> Regards,
> Jean.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5289) Execute and Wait Interceptor prevents JVM shutdown

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695809#comment-17695809
 ] 

Lukasz Lenart commented on WW-5289:
---

Nice, it means we have to change the default implementation to use something 
similar, thanks a lot for reporting this!

> Execute and Wait Interceptor prevents JVM shutdown
> --
>
> Key: WW-5289
> URL: https://issues.apache.org/jira/browse/WW-5289
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Interceptors
>Affects Versions: 6.1.1
>Reporter: KON-SUN-TACK
>Priority: Major
> Fix For: 6.2.0
>
>
> Hi Struts 2 team,
> We are using the Execute and Wait Interceptor as following:
> {quote}class="my.sample.longrun.action.LongRunAction"
>   method="longRunLaunch">
>   
>   
> 500
> 500
>   
>   /my/sample/wait.jsp
>   /my/sample/success.jsp
> {quote}
> - with Struts 6.0.3, it works fine
> - with Struts 6.1.1, it works fine... but JVM shutdown is hanging
> We are running: Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> I tried to compare thread dumps and only found this extra one with Struts 
> 6.1.1:
> {quote}"pool-5-thread-1" #129 prio=5 os_prio=0 cpu=0.00ms elapsed=21.47s 
> tid=0x01b39a917800 nid=0x3cb0 waiting on condition  [0x0068c4fff000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
> - parking to wait for  <0xe4ca75b0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(java.base@11.0.10/LinkedBlockingQueue.java:433)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.10/ThreadPoolExecutor.java:1054)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1114)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
>Locked ownable synchronizers:
> - None{quote}
> Regards,
> Jean.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5289) Execute and Wait Interceptor prevents JVM shutdown

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17695776#comment-17695776
 ] 

Lukasz Lenart commented on WW-5289:
---

This can be related to WW-3691 - maybe you can define your own executor and see 
if this changes anything?

{code}

{code}

> Execute and Wait Interceptor prevents JVM shutdown
> --
>
> Key: WW-5289
> URL: https://issues.apache.org/jira/browse/WW-5289
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Interceptors
>Affects Versions: 6.1.1
>Reporter: KON-SUN-TACK
>Priority: Major
> Fix For: 6.2.0
>
>
> Hi Struts 2 team,
> We are using the Execute and Wait Interceptor as following:
> {quote}class="my.sample.longrun.action.LongRunAction"
>   method="longRunLaunch">
>   
>   
> 500
> 500
>   
>   /my/sample/wait.jsp
>   /my/sample/success.jsp
> {quote}
> - with Struts 6.0.3, it works fine
> - with Struts 6.1.1, it works fine... but JVM shutdown is hanging
> We are running: Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> I tried to compare thread dumps and only found this extra one with Struts 
> 6.1.1:
> {quote}"pool-5-thread-1" #129 prio=5 os_prio=0 cpu=0.00ms elapsed=21.47s 
> tid=0x01b39a917800 nid=0x3cb0 waiting on condition  [0x0068c4fff000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
> - parking to wait for  <0xe4ca75b0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(java.base@11.0.10/LinkedBlockingQueue.java:433)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.10/ThreadPoolExecutor.java:1054)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1114)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
>Locked ownable synchronizers:
> - None{quote}
> Regards,
> Jean.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5289) Execute and Wait Interceptor prevents JVM shutdown

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5289:
--
Fix Version/s: 6.2.0

> Execute and Wait Interceptor prevents JVM shutdown
> --
>
> Key: WW-5289
> URL: https://issues.apache.org/jira/browse/WW-5289
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core Interceptors
>Affects Versions: 6.1.1
>Reporter: KON-SUN-TACK
>Priority: Major
> Fix For: 6.2.0
>
>
> Hi Struts 2 team,
> We are using the Execute and Wait Interceptor as following:
> {quote}class="my.sample.longrun.action.LongRunAction"
>   method="longRunLaunch">
>   
>   
> 500
> 500
>   
>   /my/sample/wait.jsp
>   /my/sample/success.jsp
> {quote}
> - with Struts 6.0.3, it works fine
> - with Struts 6.1.1, it works fine... but JVM shutdown is hanging
> We are running: Apache Tomcat (TomEE)/9.0.41 (8.0.6)
> I tried to compare thread dumps and only found this extra one with Struts 
> 6.1.1:
> {quote}"pool-5-thread-1" #129 prio=5 os_prio=0 cpu=0.00ms elapsed=21.47s 
> tid=0x01b39a917800 nid=0x3cb0 waiting on condition  [0x0068c4fff000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.10/Native Method)
> - parking to wait for  <0xe4ca75b0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.10/LockSupport.java:194)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base@11.0.10/AbstractQueuedSynchronizer.java:2081)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(java.base@11.0.10/LinkedBlockingQueue.java:433)
> at 
> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.10/ThreadPoolExecutor.java:1054)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.10/ThreadPoolExecutor.java:1114)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.10/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.10/Thread.java:834)
>Locked ownable synchronizers:
> - None{quote}
> Regards,
> Jean.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5286) Allow XWork configuration reloading at any time

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694889#comment-17694889
 ] 

Lukasz Lenart commented on WW-5286:
---

The reload() functionality is a brutal _destroy & create_ operation, that's why 
using it out of devMode can be hard.

> Allow XWork configuration reloading at any time
> ---
>
> Key: WW-5286
> URL: https://issues.apache.org/jira/browse/WW-5286
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> Currently, if a
> {{com.opensymphony.xwork2.config.ConfigurationManager#reload}}
> or
> {{com.opensymphony.xwork2.config.ConfigurationManager#reloadProviders}}
> are triggered, any Struts requests that are in the process of being served, 
> or commence serving during the reload, will malfunction.
> To make reloading the container configuration safe at any time, the reload 
> should wait until any commenced requests are finished serving, and should not 
> commence serving any new requests until the container reload is complete.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5286) Allow XWork configuration reloading at any time

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694541#comment-17694541
 ] 

Lukasz Lenart commented on WW-5286:
---

Just marked this issue to be fixed in 6.2.0, yet it can be postponed

> Allow XWork configuration reloading at any time
> ---
>
> Key: WW-5286
> URL: https://issues.apache.org/jira/browse/WW-5286
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> Currently, if a
> {{com.opensymphony.xwork2.config.ConfigurationManager#reload}}
> or
> {{com.opensymphony.xwork2.config.ConfigurationManager#reloadProviders}}
> are triggered, any Struts requests that are in the process of being served, 
> or commence serving during the reload, will malfunction.
> To make reloading the container configuration safe at any time, the reload 
> should wait until any commenced requests are finished serving, and should not 
> commence serving any new requests until the container reload is complete.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5286) Allow XWork configuration reloading at any time

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694540#comment-17694540
 ] 

Lukasz Lenart commented on WW-5286:
---

I would say the reload functionality is intended to be used in {{devMode}} only.

> Allow XWork configuration reloading at any time
> ---
>
> Key: WW-5286
> URL: https://issues.apache.org/jira/browse/WW-5286
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
>
> Currently, if a
> {{com.opensymphony.xwork2.config.ConfigurationManager#reload}}
> or
> {{com.opensymphony.xwork2.config.ConfigurationManager#reloadProviders}}
> are triggered, any Struts requests that are in the process of being served, 
> or commence serving during the reload, will malfunction.
> To make reloading the container configuration safe at any time, the reload 
> should wait until any commenced requests are finished serving, and should not 
> commence serving any new requests until the container reload is complete.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5287) Make excludedPackageNames check more stringent

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5287:
--
Fix Version/s: 7.0.0

> Make excludedPackageNames check more stringent
> --
>
> Key: WW-5287
> URL: https://issues.apache.org/jira/browse/WW-5287
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 7.0.0
>
>
> {{struts.excludedPackageNames}} and {{struts.excludedPackageNamePatterns}} 
> only do a check against the package of the declaring and target classes of an 
> OGNL expression target.
> For more robust security, we should be checking the package of every 
> superclass and implemented interface. This will also be more consistent with 
> {{struts.excludedClasses}} which does an {{#isAssignableFrom}} check.
> This is rather straightforward by leveraging the following methods, but will 
> come at a slight performance cost:
> {{org.apache.commons.lang3.ClassUtils#getAllInterfaces}}
> {{org.apache.commons.lang3.ClassUtils#getAllSuperclasses}}
> Additionally, we should ensure that for any 
> {{struts.excludedPackageExemptClasses}}, an assignable class exists for every 
> matching excluded package (any matching interface or superclass).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5286) Allow XWork configuration reloading at any time

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5286:
--
Fix Version/s: 6.2.0

> Allow XWork configuration reloading at any time
> ---
>
> Key: WW-5286
> URL: https://issues.apache.org/jira/browse/WW-5286
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> Currently, if a
> {{com.opensymphony.xwork2.config.ConfigurationManager#reload}}
> or
> {{com.opensymphony.xwork2.config.ConfigurationManager#reloadProviders}}
> are triggered, any Struts requests that are in the process of being served, 
> or commence serving during the reload, will malfunction.
> To make reloading the container configuration safe at any time, the reload 
> should wait until any commenced requests are finished serving, and should not 
> commence serving any new requests until the container reload is complete.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5268) Add configuration option to exempt classes from OGNL package exclusions

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694389#comment-17694389
 ] 

Lukasz Lenart commented on WW-5268:
---

Here is a section

[https://struts.apache.org/security/#internal-security-mechanism]

And source is in GH, just another PR ;)

[https://github.com/apache/struts-site/blob/master/source/security/index.md]

 

> Add configuration option to exempt classes from OGNL package exclusions
> ---
>
> Key: WW-5268
> URL: https://issues.apache.org/jira/browse/WW-5268
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> It is currently possible to exclude packages from OGNL evaluation using 
> `struts.excludedPackageNamePatterns` and `struts.excludedPackageNames`.
> There may exist a scenario where you wish to have certain packages 
> excluded/blocklisted by default, but exempt specific classes from these 
> packages that have been assessed to be safe.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (WW-5273) Support fileupload using native Servlet API 3.1 logic

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart closed WW-5273.
-
Resolution: Won't Fix

Instead this broken implementation we are going to wait on full Jakarta API 
support as stated in WW-5141

> Support fileupload using native Servlet API 3.1 logic
> -
>
> Key: WW-5273
> URL: https://issues.apache.org/jira/browse/WW-5273
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Since Servlet API 3.1 there is no need in using Commons Fileupload as the 
> servlets support it.
> https://stackoverflow.com/questions/68820707/jetty-11-and-commons-fileupload



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5268) Add configuration option to exempt classes from OGNL package exclusions

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694376#comment-17694376
 ] 

Lukasz Lenart commented on WW-5268:
---

[~kusal] could you update the docs as well?

> Add configuration option to exempt classes from OGNL package exclusions
> ---
>
> Key: WW-5268
> URL: https://issues.apache.org/jira/browse/WW-5268
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> It is currently possible to exclude packages from OGNL evaluation using 
> `struts.excludedPackageNamePatterns` and `struts.excludedPackageNames`.
> There may exist a scenario where you wish to have certain packages 
> excluded/blocklisted by default, but exempt specific classes from these 
> packages that have been assessed to be safe.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5268) Add configuration option to exempt classes from OGNL package exclusions

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694373#comment-17694373
 ] 

Lukasz Lenart commented on WW-5268:
---

I wonder if such mechanism shouldn't be moved into OGNL directly with option to 
configure/extend it by Struts when needed. Right now we are ending up with a 
bunch of similar options which are applied in normal mode or in devMode. I need 
to finish refactoring OGNL and make this option available there.

> Add configuration option to exempt classes from OGNL package exclusions
> ---
>
> Key: WW-5268
> URL: https://issues.apache.org/jira/browse/WW-5268
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It is currently possible to exclude packages from OGNL evaluation using 
> `struts.excludedPackageNamePatterns` and `struts.excludedPackageNames`.
> There may exist a scenario where you wish to have certain packages 
> excluded/blocklisted by default, but exempt specific classes from these 
> packages that have been assessed to be safe.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5285) Upgrade commons-fileupload to ver 1.5 and add option to limit number of accepted files

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694363#comment-17694363
 ] 

Lukasz Lenart commented on WW-5285:
---

Cool, sorry that I missed that in the beginning :)

> Upgrade commons-fileupload to ver 1.5 and add option to limit number of 
> accepted files
> --
>
> Key: WW-5285
> URL: https://issues.apache.org/jira/browse/WW-5285
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> With a new version of commons-fileupload a new option has been added to limit 
> number of uploaded files (not size, but number). It would be good to support 
> this in Struts as well by adding a new constant "struts.multipart.maxFiles"
> [https://github.com/apache/commons-fileupload/pull/185]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Reopened] (WW-5266) Add configuration option for a per-file max size for multipart requests

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reopened WW-5266:
---

> Add configuration option for a per-file max size for multipart requests
> ---
>
> Key: WW-5266
> URL: https://issues.apache.org/jira/browse/WW-5266
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> In addition to the existing `struts.multipart.maxSize`, allow the 
> configuration of a per-file max size using `struts.multipart.maxFileSize`



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5285) Upgrade commons-fileupload to ver 1.5 and add option to limit number of accepted files

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694357#comment-17694357
 ] 

Lukasz Lenart commented on WW-5285:
---

Yes, it's a security option. And now I see WW-5266 can be implemented as there 
is a direct support in commons-fileupload, yet having this in interceptor is a 
bit too late, it must be also a global option to be applied once the 
MultipartParser is created.

> Upgrade commons-fileupload to ver 1.5 and add option to limit number of 
> accepted files
> --
>
> Key: WW-5285
> URL: https://issues.apache.org/jira/browse/WW-5285
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> With a new version of commons-fileupload a new option has been added to limit 
> number of uploaded files (not size, but number). It would be good to support 
> this in Struts as well by adding a new constant "struts.multipart.maxFiles"
> [https://github.com/apache/commons-fileupload/pull/185]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5285) Upgrade commons-fileupload to ver 1.5 and add option to limit number of accepted files

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17694333#comment-17694333
 ] 

Lukasz Lenart commented on WW-5285:
---

The current implementation is a global option, the same as 
{{struts.multipart.maxSize}} which applies to whole request (and not to a 
single file). The {{maximumSize}} option in interceptor applies to a single 
file, and checking the number of files here is way too late as the request was 
already parsed.

https://struts.apache.org/core-developers/file-upload.html#file-size-limits

> Upgrade commons-fileupload to ver 1.5 and add option to limit number of 
> accepted files
> --
>
> Key: WW-5285
> URL: https://issues.apache.org/jira/browse/WW-5285
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With a new version of commons-fileupload a new option has been added to limit 
> number of uploaded files (not size, but number). It would be good to support 
> this in Struts as well by adding a new constant "struts.multipart.maxFiles"
> [https://github.com/apache/commons-fileupload/pull/185]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5141) Support for JEE 9+

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693687#comment-17693687
 ] 

Lukasz Lenart commented on WW-5141:
---

And my idea is to release Struts 7.x based on Jakarta Servlet API and JDK11, 
Struts 6.x will stay on JDK8 and the old Servlet API

> 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: 7.0.0
>
> 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.20.10#820010)

[jira] [Commented] (WW-5141) Support for JEE 9+

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693686#comment-17693686
 ] 

Lukasz Lenart commented on WW-5141:
---

Basically we are blocked by this issue FILEUPLOAD-309

> 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: 7.0.0
>
> 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.20.10#820010)

[jira] [Assigned] (WW-5285) Upgrade commons-fileupload to ver 1.5 and add option to limit number of accepted files

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reassigned WW-5285:
-

Assignee: Lukasz Lenart

> Upgrade commons-fileupload to ver 1.5 and add option to limit number of 
> accepted files
> --
>
> Key: WW-5285
> URL: https://issues.apache.org/jira/browse/WW-5285
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>
> With a new version of commons-fileupload a new option has been added to limit 
> number of uploaded files (not size, but number). It would be good to support 
> this in Struts as well by adding a new constant "struts.multipart.maxFiles"
> [https://github.com/apache/commons-fileupload/pull/185]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-4291) Can't use Spring bean name for type convertor

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-4291:
--
Affects Version/s: 6.1.1

> Can't use Spring bean name for type convertor
> -
>
> Key: WW-4291
> URL: https://issues.apache.org/jira/browse/WW-4291
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Plugin - Spring
>Affects Versions: 6.1.1
>Reporter: Jasper Rosenberg
>Priority: Minor
> Fix For: 6.2.0
>
>
> If in your xwork.conversion.properties file you try to use a Spring bean name 
> instead of a class name, it blows up.
> This is because DefaultConfiguration.createBootstrapContainer() ends up using 
> DefaultTypeConverterCreator which has the generic ObjectFactory at that point 
> because it happens before the struts.properties file is ever loaded (where in 
> my case the SpringObjectFactory is defined.)
> {noformat}
> 10:20:06,910 ERROR [DefaultConversionPropertiesProcessor] Conversion 
> registration error
> java.lang.ClassNotFoundException: entityObjectTypeConvertor
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
> at 
> com.opensymphony.xwork2.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:152)
> at 
> com.opensymphony.xwork2.ObjectFactory.getClassInstance(ObjectFactory.java:108)
> at 
> com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:161)
> at 
> com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:151)
> at 
> com.opensymphony.xwork2.conversion.impl.DefaultTypeConverterCreator.createTypeConverter(DefaultTypeConverterCreator.java:23)
> at 
> com.opensymphony.xwork2.conversion.impl.DefaultConversionPropertiesProcessor.loadConversionProperties(DefaultConversionPropertiesProcessor.java:64)
> at 
> com.opensymphony.xwork2.conversion.impl.DefaultConversionPropertiesProcessor.process(DefaultConversionPropertiesProcessor.java:40)
> at 
> com.opensymphony.xwork2.conversion.impl.XWorkConverter.setConversionPropertiesProcessor(XWorkConverter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.inject(ContainerImpl.java:299)
> at 
> com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.construct(ContainerImpl.java:438)
> at 
> com.opensymphony.xwork2.inject.ContainerBuilder$5.create(ContainerBuilder.java:207)
> ...
> at 
> com.opensymphony.xwork2.inject.ContainerBuilder$7.call(ContainerBuilder.java:484)
> at 
> com.opensymphony.xwork2.inject.ContainerImpl.callInContext(ContainerImpl.java:584)
> at 
> com.opensymphony.xwork2.inject.ContainerBuilder.create(ContainerBuilder.java:484)
> at 
> com.opensymphony.xwork2.config.impl.DefaultConfiguration.createBootstrapContainer(DefaultConfiguration.java:324)
> at 
> com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:221)
> at 
> com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
> at 
> org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:446)
> at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:490)
> at 
> org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:74)
> at 
> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:57)
> at 
> org.springframework.web.filter.DelegatingFilterProxy.initDelegate(DelegatingFilterProxy.java:325)
> at 
> org.springframework.web.filter.DelegatingFilterProxy.initFilterBean(DelegatingFilterProxy.java:235)
> at 
> org.springframework.web.filter.GenericFilterBean.init(GenericFilterBean.java:194)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:295)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:422)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:115)
> at 
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4072)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4726)
> at 
> 

[jira] [Updated] (WW-4291) Can't use Spring bean name for type convertor

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-4291:
--
Fix Version/s: 6.2.0
   (was: 7.0.0)

> Can't use Spring bean name for type convertor
> -
>
> Key: WW-4291
> URL: https://issues.apache.org/jira/browse/WW-4291
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Plugin - Spring
>Reporter: Jasper Rosenberg
>Priority: Minor
> Fix For: 6.2.0
>
>
> If in your xwork.conversion.properties file you try to use a Spring bean name 
> instead of a class name, it blows up.
> This is because DefaultConfiguration.createBootstrapContainer() ends up using 
> DefaultTypeConverterCreator which has the generic ObjectFactory at that point 
> because it happens before the struts.properties file is ever loaded (where in 
> my case the SpringObjectFactory is defined.)
> {noformat}
> 10:20:06,910 ERROR [DefaultConversionPropertiesProcessor] Conversion 
> registration error
> java.lang.ClassNotFoundException: entityObjectTypeConvertor
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1680)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1526)
> at 
> com.opensymphony.xwork2.util.ClassLoaderUtil.loadClass(ClassLoaderUtil.java:152)
> at 
> com.opensymphony.xwork2.ObjectFactory.getClassInstance(ObjectFactory.java:108)
> at 
> com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:161)
> at 
> com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:151)
> at 
> com.opensymphony.xwork2.conversion.impl.DefaultTypeConverterCreator.createTypeConverter(DefaultTypeConverterCreator.java:23)
> at 
> com.opensymphony.xwork2.conversion.impl.DefaultConversionPropertiesProcessor.loadConversionProperties(DefaultConversionPropertiesProcessor.java:64)
> at 
> com.opensymphony.xwork2.conversion.impl.DefaultConversionPropertiesProcessor.process(DefaultConversionPropertiesProcessor.java:40)
> at 
> com.opensymphony.xwork2.conversion.impl.XWorkConverter.setConversionPropertiesProcessor(XWorkConverter.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.inject(ContainerImpl.java:299)
> at 
> com.opensymphony.xwork2.inject.ContainerImpl$ConstructorInjector.construct(ContainerImpl.java:438)
> at 
> com.opensymphony.xwork2.inject.ContainerBuilder$5.create(ContainerBuilder.java:207)
> ...
> at 
> com.opensymphony.xwork2.inject.ContainerBuilder$7.call(ContainerBuilder.java:484)
> at 
> com.opensymphony.xwork2.inject.ContainerImpl.callInContext(ContainerImpl.java:584)
> at 
> com.opensymphony.xwork2.inject.ContainerBuilder.create(ContainerBuilder.java:484)
> at 
> com.opensymphony.xwork2.config.impl.DefaultConfiguration.createBootstrapContainer(DefaultConfiguration.java:324)
> at 
> com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:221)
> at 
> com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
> at 
> org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:446)
> at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:490)
> at 
> org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:74)
> at 
> org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:57)
> at 
> org.springframework.web.filter.DelegatingFilterProxy.initDelegate(DelegatingFilterProxy.java:325)
> at 
> org.springframework.web.filter.DelegatingFilterProxy.initFilterBean(DelegatingFilterProxy.java:235)
> at 
> org.springframework.web.filter.GenericFilterBean.init(GenericFilterBean.java:194)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:295)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:422)
> at 
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:115)
> at 
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4072)
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4726)
> at 
> 

[jira] [Created] (WW-5285) Upgrade commons-fileupload to ver 1.5 and add option to limit number of accepted files

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5285:
-

 Summary: Upgrade commons-fileupload to ver 1.5 and add option to 
limit number of accepted files
 Key: WW-5285
 URL: https://issues.apache.org/jira/browse/WW-5285
 Project: Struts 2
  Issue Type: Improvement
  Components: Core
Reporter: Lukasz Lenart
 Fix For: 6.2.0


With a new version of commons-fileupload a new option has been added to limit 
number of uploaded files (not size, but number). It would be good to support 
this in Struts as well by adding a new constant "struts.multipart.maxFiles"

[https://github.com/apache/commons-fileupload/pull/185]

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5284) Further clean up ActionValidatorManager implementations

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5284.
---
Resolution: Fixed

> Further clean up ActionValidatorManager implementations
> ---
>
> Key: WW-5284
> URL: https://issues.apache.org/jira/browse/WW-5284
> Project: Struts 2
>  Issue Type: Task
>  Components: Core Interceptors
>Reporter: Kusal Kithul-Godage
>Priority: Trivial
> Fix For: 6.2.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5283) Update Struts Archetypes

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5283.
---
Resolution: Fixed

> Update Struts Archetypes
> 
>
> Key: WW-5283
> URL: https://issues.apache.org/jira/browse/WW-5283
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Maven Archetypes
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>
> Upgrade Struts version used by all the archetypes



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5275) Allow to configure more flexible Content-Security-Policy

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5275.
---
Resolution: Fixed

> Allow to configure more flexible Content-Security-Policy
> 
>
> Key: WW-5275
> URL: https://issues.apache.org/jira/browse/WW-5275
> Project: Struts 2
>  Issue Type: New Feature
>  Components: Core Interceptors
>Reporter: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently CSP interceptor doesn't allow to change {{script-src}} or 
> {{object-src}} or any other values - it should be possible to customise these 
> to allow users adopt the policy to their specific needs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (WW-5283) Update Struts Archetypes

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reassigned WW-5283:
-

Assignee: Lukasz Lenart

> Update Struts Archetypes
> 
>
> Key: WW-5283
> URL: https://issues.apache.org/jira/browse/WW-5283
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Maven Archetypes
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>
> Upgrade Struts version used by all the archetypes



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WW-5283) Update Struts Archetypes

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5283:
-

 Summary: Update Struts Archetypes
 Key: WW-5283
 URL: https://issues.apache.org/jira/browse/WW-5283
 Project: Struts 2
  Issue Type: Improvement
  Components: Maven Archetypes
Reporter: Lukasz Lenart
 Fix For: 6.2.0


Upgrade Struts version used by all the archetypes



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (WW-5281) Getting InstantiatingNullHandler exception while using Struts2.5.30

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart closed WW-5281.
-
Resolution: Not A Problem

Please ask such questions on the user mailing list first as hard to guess where 
is the problem. On the first spot it looks like serialisation issue so I would 
clean up Temp/Sessions folder first.

[https://struts.apache.org/mail.html]

> Getting InstantiatingNullHandler exception while using Struts2.5.30
> ---
>
> Key: WW-5281
> URL: https://issues.apache.org/jira/browse/WW-5281
> Project: Struts 2
>  Issue Type: Bug
>Reporter: swapnaponnam
>Priority: Major
>
> Getting InstantiatingNullHandler exception while using Struts2.5.30
> {code:java}
> INFO  [STDOUT] 10:21:48.145 [http-0.0.0.0-8443-3] ERROR 
> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler - Could not 
> create and/or set value back on to object
> java.lang.InstantiationException: java.io.Serializable
>         at java.lang.Class.newInstance(Class.java:427) ~[?:1.8.0_332]
>         at 
> com.opensymphony.xwork2.ObjectFactory.buildBean(ObjectFactory.java:154) 
> ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.createObject(InstantiatingNullHandler.java:152)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.conversion.impl.InstantiatingNullHandler.nullPropertyValue(InstantiatingNullHandler.java:128)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.ognl.OgnlNullHandlerWrapper.nullPropertyValue(OgnlNullHandlerWrapper.java:39)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at ognl.ASTProperty.getValueBody(ASTProperty.java:125) 
> ~[ognl-3.1.29.jar:?]
>         at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:212) 
> ~[ognl-3.1.29.jar:?]
>         at ognl.SimpleNode.getValue(SimpleNode.java:258) ~[ognl-3.1.29.jar:?]
>         at ognl.ASTChain.setValueBody(ASTChain.java:222) ~[ognl-3.1.29.jar:?]
>         at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:220) 
> ~[ognl-3.1.29.jar:?]
>         at ognl.SimpleNode.setValue(SimpleNode.java:308) ~[ognl-3.1.29.jar:?]
>         at ognl.Ognl.setValue(Ognl.java:780) ~[ognl-3.1.29.jar:?]
>         at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:436) 
> ~[struts2-core-2.5.30.jar:2.5.30]
>         at com.opensymphony.xwork2.ognl.OgnlUtil$1.execute(OgnlUtil.java:428) 
> ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.ognl.OgnlUtil.compileAndExecute(OgnlUtil.java:523) 
> ~[struts2-core-2.5.30.jar:2.5.30]
>         at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:428) 
> ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.ognl.OgnlValueStack.trySetValue(OgnlValueStack.java:186)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.ognl.OgnlValueStack.setValue(OgnlValueStack.java:173) 
> ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.ognl.OgnlValueStack.setParameter(OgnlValueStack.java:157)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:214)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:132)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:99)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:140)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:99)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:201)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:67)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:249)
>  ~[struts2-core-2.5.30.jar:2.5.30]
>         at 
> 

[jira] [Closed] (WW-5282) Is Struts6 compatible with Jboss 5.1 w.r.t Servlet-APi jar ?

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart closed WW-5282.
-
Resolution: Not A Problem

Struts 6.x and above requires Servlet API 3.1 which means it isn't compatible 
with JBoss 5.1 - first you must upgrade your JBoss instance and then migrate to 
the new version of Struts.

Next time please ask such questions on the User Mailing List (you must 
subscribe first):

https://struts.apache.org/mail.html

> Is Struts6 compatible with Jboss 5.1 w.r.t Servlet-APi jar ?
> 
>
> Key: WW-5282
> URL: https://issues.apache.org/jira/browse/WW-5282
> Project: Struts 2
>  Issue Type: Bug
>Reporter: swapnaponnam
>Priority: Major
>
> Currently our application is running on Jboss5.1  and  noticed that Jboss5.1 
> had Servlet-APi V2.5. Planning to upgrade to Struts6 which has Servlet-Api 
> V3.1 so that Could someone please confirm, Is Struts6 compatible with Jboss 
> 5.1 w.r.t Servlet-APi jar ?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WW-5280) Cleanup NoParameters interfaces

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5280:
-

 Summary: Cleanup NoParameters interfaces
 Key: WW-5280
 URL: https://issues.apache.org/jira/browse/WW-5280
 Project: Struts 2
  Issue Type: Improvement
Reporter: Lukasz Lenart
 Fix For: 6.2.0


There are two {{NoParameters}} interfaces:
- {{org.apache.struts2.interceptor.NoParameters}}
- {{com.opensymphony.xwork2.interceptor.NoParameters}}

the former isn't used by the {{ParametersInterceptor}}, just the second one. 
Mark the old XWork interface and just use the new from struts2 package (just 
move it into {{org.apache.struts2.action}} package)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5279) Improve readability of XmlConfigurationProvider class

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5279.
---
Resolution: Fixed

> Improve readability of XmlConfigurationProvider class
> -
>
> Key: WW-5279
> URL: https://issues.apache.org/jira/browse/WW-5279
> Project: Struts 2
>  Issue Type: Task
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Trivial
> Fix For: 6.2.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5279) Improve readability of XmlConfigurationProvider class

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5279:
--
Fix Version/s: 6.2.0

> Improve readability of XmlConfigurationProvider class
> -
>
> Key: WW-5279
> URL: https://issues.apache.org/jira/browse/WW-5279
> Project: Struts 2
>  Issue Type: Task
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Trivial
> Fix For: 6.2.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5278) Clean up duplicated code across ActionValidationManagers

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5278.
---
Resolution: Fixed

> Clean up duplicated code across ActionValidationManagers
> 
>
> Key: WW-5278
> URL: https://issues.apache.org/jira/browse/WW-5278
> Project: Struts 2
>  Issue Type: Task
>  Components: Core Interceptors
>Reporter: Kusal Kithul-Godage
>Priority: Trivial
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5278) Clean up duplicated code across ActionValidationManagers

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5278:
--
Fix Version/s: 6.2.0

> Clean up duplicated code across ActionValidationManagers
> 
>
> Key: WW-5278
> URL: https://issues.apache.org/jira/browse/WW-5278
> Project: Struts 2
>  Issue Type: Task
>  Components: Core Interceptors
>Reporter: Kusal Kithul-Godage
>Priority: Trivial
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5270) Forwarding from a Struts excluded URL to an Action not working

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5270.
---
Resolution: Fixed

> Forwarding from a Struts excluded URL to an Action not working
> --
>
> Key: WW-5270
> URL: https://issues.apache.org/jira/browse/WW-5270
> Project: Struts 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Since the fix implemented in WW-5199 - I noticed forwards still did not 
> function when it originated from a Struts excluded URL. This is because the 
> exclusion flag is being maintained when forwarded. There is also an 
> additional issue of the ActionContext being cleaned up too soon - prior to 
> the SiteMesh filter being able to access it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-4404) Implement HttpInterceptor

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-4404.
---
Resolution: Fixed

> Implement HttpInterceptor
> -
>
> Key: WW-4404
> URL: https://issues.apache.org/jira/browse/WW-4404
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core Interceptors
>Affects Versions: 2.3.20
>Reporter: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Allows limit access to actions based on used Http method type
> https://github.com/apache/struts/pull/25



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5276) Cleanup method of request is not called

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5276.
---
Resolution: Fixed

> Cleanup method of request is not called
> ---
>
> Key: WW-5276
> URL: https://issues.apache.org/jira/browse/WW-5276
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: Mirek Hankus
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> After upgrading to 6.1.1  we have noticed that cleanup method of custom 
> MultiPartRequest is not called by struts. 
>  
>  
> It may be related to 
> [https://github.com/apache/struts/commit/69102e907551a87335231656320c8484072bdecb]
>  
> as before variable "request" was overwritten with wrapped request and cleanup 
> was called in finally section
>  
> After this commit new variable is created called "wrappedRequest", but 
> cleanup is called only on original request, and new wrappedRequest is not 
> cleaned up at all.
>  
> Below is respective code fragment
> {code:java}
> HttpServletRequest wrappedRequest = prepare.wrapRequest(request);
>                     ActionMapping mapping = 
> prepare.findActionMapping(wrappedRequest, response, true);
>                     if (mapping == null) {
>                         LOG.trace("Cannot find mapping for {}, passing to 
> other filters", uri);
>                         chain.doFilter(request, response);
>                     } else {
>                         LOG.trace("Found mapping {} for {}", mapping, uri);
>                         execute.executeAction(wrappedRequest, response, 
> mapping);
>                     }
>                 }
>             }
>         } finally {
>             prepare.cleanupRequest(request);
>         }{code}
>  
> This bug causes a lot of resource problems, and can result in denial of 
> service condition for application  (or making application not compliant - as 
> sensitive information is not properly discarded).
>  
>  
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5274) Mark Pell Multipart plugin as deprecated

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5274.
---
Resolution: Fixed

> Mark Pell Multipart plugin as deprecated
> 
>
> Key: WW-5274
> URL: https://issues.apache.org/jira/browse/WW-5274
> Project: Struts 2
>  Issue Type: Dependency
>  Components: Plugin - Pell
>Reporter: Lukasz Lenart
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This plugin is using library which isn't support nor actively developed



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (WW-5276) Cleanup method of request is not called

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679537#comment-17679537
 ] 

Lukasz Lenart commented on WW-5276:
---

[~mhankus] could you review the proposed change in the linked PR?

> Cleanup method of request is not called
> ---
>
> Key: WW-5276
> URL: https://issues.apache.org/jira/browse/WW-5276
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: Mirek Hankus
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> After upgrading to 6.1.1  we have noticed that cleanup method of custom 
> MultiPartRequest is not called by struts. 
>  
>  
> It may be related to 
> [https://github.com/apache/struts/commit/69102e907551a87335231656320c8484072bdecb]
>  
> as before variable "request" was overwritten with wrapped request and cleanup 
> was called in finally section
>  
> After this commit new variable is created called "wrappedRequest", but 
> cleanup is called only on original request, and new wrappedRequest is not 
> cleaned up at all.
>  
> Below is respective code fragment
> {code:java}
> HttpServletRequest wrappedRequest = prepare.wrapRequest(request);
>                     ActionMapping mapping = 
> prepare.findActionMapping(wrappedRequest, response, true);
>                     if (mapping == null) {
>                         LOG.trace("Cannot find mapping for {}, passing to 
> other filters", uri);
>                         chain.doFilter(request, response);
>                     } else {
>                         LOG.trace("Found mapping {} for {}", mapping, uri);
>                         execute.executeAction(wrappedRequest, response, 
> mapping);
>                     }
>                 }
>             }
>         } finally {
>             prepare.cleanupRequest(request);
>         }{code}
>  
> This bug causes a lot of resource problems, and can result in denial of 
> service condition for application  (or making application not compliant - as 
> sensitive information is not properly discarded).
>  
>  
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5277) Upgrade Freemarker to version 3.2.32

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5277.
---
Resolution: Fixed

> Upgrade Freemarker to version 3.2.32
> 
>
> Key: WW-5277
> URL: https://issues.apache.org/jira/browse/WW-5277
> Project: Struts 2
>  Issue Type: Dependency
>  Components: Core
>Reporter: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The Apache FreeMarker community is pleased to announce the release of
> Apache FreeMarker 2.3.32.
> https://freemarker.apache.org/docs/versions_2_3_32.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5277) Upgrade Freemarker to version 3.2.32

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5277:
--
Fix Version/s: 6.2.0

> Upgrade Freemarker to version 3.2.32
> 
>
> Key: WW-5277
> URL: https://issues.apache.org/jira/browse/WW-5277
> Project: Struts 2
>  Issue Type: Dependency
>  Components: Core
>Reporter: Lukasz Lenart
>Priority: Minor
> Fix For: 6.2.0
>
>
> The Apache FreeMarker community is pleased to announce the release of
> Apache FreeMarker 2.3.32.
> https://freemarker.apache.org/docs/versions_2_3_32.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WW-5277) Upgrade Freemarker to version 3.2.32

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5277:
-

 Summary: Upgrade Freemarker to version 3.2.32
 Key: WW-5277
 URL: https://issues.apache.org/jira/browse/WW-5277
 Project: Struts 2
  Issue Type: Dependency
  Components: Core
Reporter: Lukasz Lenart


The Apache FreeMarker community is pleased to announce the release of
Apache FreeMarker 2.3.32.

https://freemarker.apache.org/docs/versions_2_3_32.html



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (WW-5276) Cleanup method of request is not called

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart updated WW-5276:
--
Fix Version/s: 6.2.0

> Cleanup method of request is not called
> ---
>
> Key: WW-5276
> URL: https://issues.apache.org/jira/browse/WW-5276
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.1.1
>Reporter: Mirek Hankus
>Priority: Major
> Fix For: 6.2.0
>
>
> After upgrading to 6.1.1  we have noticed that cleanup method of custom 
> MultiPartRequest is not called by struts. 
>  
>  
> It may be related to 
> [https://github.com/apache/struts/commit/69102e907551a87335231656320c8484072bdecb]
>  
> as before variable "request" was overwritten with wrapped request and cleanup 
> was called in finally section
>  
> After this commit new variable is created called "wrappedRequest", but 
> cleanup is called only on original request, and new wrappedRequest is not 
> cleaned up at all.
>  
> Below is respective code fragment
> {code:java}
> HttpServletRequest wrappedRequest = prepare.wrapRequest(request);
>                     ActionMapping mapping = 
> prepare.findActionMapping(wrappedRequest, response, true);
>                     if (mapping == null) {
>                         LOG.trace("Cannot find mapping for {}, passing to 
> other filters", uri);
>                         chain.doFilter(request, response);
>                     } else {
>                         LOG.trace("Found mapping {} for {}", mapping, uri);
>                         execute.executeAction(wrappedRequest, response, 
> mapping);
>                     }
>                 }
>             }
>         } finally {
>             prepare.cleanupRequest(request);
>         }{code}
>  
> This bug causes a lot of resource problems, and can result in denial of 
> service condition for application  (or making application not compliant - as 
> sensitive information is not properly discarded).
>  
>  
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WW-5275) Allow to configure more flexible Content-Security-Policy

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5275:
-

 Summary: Allow to configure more flexible Content-Security-Policy
 Key: WW-5275
 URL: https://issues.apache.org/jira/browse/WW-5275
 Project: Struts 2
  Issue Type: New Feature
  Components: Core Interceptors
Reporter: Lukasz Lenart
 Fix For: 6.2.0


Currently CSP interceptor doesn't allow to change {{script-src}} or 
{{object-src}} or any other values - it should be possible to customise these 
to allow users adopt the policy to their specific needs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5272) java.lang.UnsupportedOperationException in the Time component

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5272.
---
Resolution: Fixed

> java.lang.UnsupportedOperationException in the Time component
> -
>
> Key: WW-5272
> URL: https://issues.apache.org/jira/browse/WW-5272
> Project: Struts 2
>  Issue Type: Bug
>Affects Versions: 6.0.3
>Reporter: Massimiliano Del Matto
>Priority: Major
> Fix For: 6.2.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We are facing a java.lang.UnsupportedOperationException on some java.sql.Time 
> fields in our frontend after migrating from 2.5.26 to 6.0.3.
> Error 12/22/2022 09:52:20:122 Caused by: 
> java.lang.UnsupportedOperationException
> Error 12/22/2022 09:52:20:122 at java.sql.Time.toInstant(Time.java:291)
> Error 12/22/2022 09:52:20:122 at 
> org.apache.struts2.components.Date.end(Date.java:299)
> Error 12/22/2022 09:52:20:122 at 
> org.apache.struts2.views.jsp.ComponentTagSupport.doEndTag(ComponentTagSupport.java:40)
> Error 12/22/2022 09:52:20:122 at 
> JEE_jsp_pages_ReadTicketGoing_1671640129851._jspx_method_s_date_2(JEE_jsp_pages_ReadTicketGoing_1671640129851.java:408)
> Error 12/22/2022 09:52:20:122 at 
> JEE_jsp_pages_ReadTicketGoing_1671640129851._jspx_method_s_form_0(JEE_jsp_pages_ReadTicketGoing_1671640129851.java:1950)
> Error 12/22/2022 09:52:20:122 at 
> JEE_jsp_pages_ReadTicketGoing_1671640129851._jspService(JEE_jsp_pages_ReadTicketGoing_1671640129851.java:60)
> ...
>  
> At line 299 in Date.java there is no code related to java.sql.Time
> [https://github.com/apache/struts/blob/STRUTS_6_0_3/core/src/main/java/org/apache/struts2/components/Date.java#L299]
>  
> java.sql.Time extends java.util.Date so when dateObject is java.sql.Time is 
> treated like an instanceof java.util.Date and toInstant() throws the 
> UnsupportedOperationException.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (WW-5274) Mark Pell Multipart plugin as deprecated

[Lukasz Lenart (Jira)]

Lukasz Lenart created WW-5274:
-

 Summary: Mark Pell Multipart plugin as deprecated
 Key: WW-5274
 URL: https://issues.apache.org/jira/browse/WW-5274
 Project: Struts 2
  Issue Type: Dependency
  Components: Plugin - Pell
Reporter: Lukasz Lenart
 Fix For: 6.2.0


This plugin is using library which isn't support nor actively developed



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (WW-5266) Add configuration option for a per-file max size for multipart requests

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart resolved WW-5266.
---
Resolution: Won't Fix

> Add configuration option for a per-file max size for multipart requests
> ---
>
> Key: WW-5266
> URL: https://issues.apache.org/jira/browse/WW-5266
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> In addition to the existing `struts.multipart.maxSize`, allow the 
> configuration of a per-file max size using `struts.multipart.maxFileSize`



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (WW-5266) Add configuration option for a per-file max size for multipart requests

[Lukasz Lenart (Jira)]

[ 
https://issues.apache.org/jira/browse/WW-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652786#comment-17652786
 ] 

Lukasz Lenart edited comment on WW-5266 at 12/29/22 9:46 AM:
-

There is already {{maximumSize}} parameter in the file upload interceptor for 
such needs

https://struts.apache.org/core-developers/file-upload.html#file-size-limits


was (Author: lukaszlenart):
There is already {{

> Add configuration option for a per-file max size for multipart requests
> ---
>
> Key: WW-5266
> URL: https://issues.apache.org/jira/browse/WW-5266
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> In addition to the existing `struts.multipart.maxSize`, allow the 
> configuration of a per-file max size using `struts.multipart.maxFileSize`



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Reopened] (WW-5266) Add configuration option for a per-file max size for multipart requests

[Lukasz Lenart (Jira)]

 [ 
https://issues.apache.org/jira/browse/WW-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukasz Lenart reopened WW-5266:
---

> Add configuration option for a per-file max size for multipart requests
> ---
>
> Key: WW-5266
> URL: https://issues.apache.org/jira/browse/WW-5266
> Project: Struts 2
>  Issue Type: Improvement
>  Components: Core
>Reporter: Kusal Kithul-Godage
>Priority: Minor
> Fix For: 6.2.0
>
>
> In addition to the existing `struts.multipart.maxSize`, allow the 
> configuration of a per-file max size using `struts.multipart.maxFileSize`



--
This message was sent by Atlassian Jira
(v8.20.10#820010)