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

Sebastian Götz commented on WW-4646:
------------------------------------

Good job! I am currently stumbling over this since we have already several 
action classes in the next release version that do not work since they use Java 
8 lambda expressions. Before reverting to loop constructs I have tried to find 
out a release date for the 2.5.3 release with no success. Maybe Lukas can give 
me a hint. I need not to know an exact date. But I would be glad to hear if it 
will come this month.

> remove ASM 3 from struts2
> -------------------------
>
>                 Key: WW-4646
>                 URL: https://issues.apache.org/jira/browse/WW-4646
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Core Actions, Plugin - Convention
>    Affects Versions: 2.5
>            Reporter: adam brin
>            Assignee: Lukasz Lenart
>             Fix For: 2.5.3
>
>
> Pulling from the discussion on the struts2-users list:
> Struts2 maintains two different versions of ASM 5x for the Convention plugin 
> and 3x for the rest of struts.  A basic search of the codebase suggests that 
> the only direct uses of ASM are via the ClassFinder class in Xwork and used 
> by the Convention plugin.  Based on this 
> [https://issues.apache.org/jira/browse/WW-4435] and 
> [http://www.philvarner.com/2015/02/05/using-apache-cxf-2-7-struts2-2-3-and-asm-5-with-maven/],
>  I wonder if it might make sense to:
> 1. remove the direct dependency on ASM entirely for XWork and Struts2 in 
> general
> 2. move the ClassFinder class and direct dependencies the convention plugin 
> and make them explicitly dependent on ASM 5x.
> 3. Like other apps like Spring, repackage/embed ASM into it's own package 
> tree so it can live with other versions of ASM.
> -----
> the core issue for us is that there are overlaps between ASM 5 and ASM 3, and 
> become explicit when launching our app with the maven-jetty-plugin. Classes 
> with the same name in both packages though they have different groupIds and 
> thus cause exceptions in startup either due to (a) Missing Classes like 
> EmptyVisitor or (b) incompatible classes. It's our hope that by removing this 
> dual dependency, we can take advantage of Java8 features and also simplify 
> dependency management in our pom.
> thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to