[ https://issues.apache.org/jira/browse/WW-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420745#comment-15420745 ]
Lukasz Lenart commented on WW-4646: ----------------------------------- But did you use the plugin as well? And you must exclude ASM3 dependency in {{struts2-core}} (the docs are outdated :() {code:xml} <dependency> <groupId>org.apache.struts</groupId> <artifactId>struts2-core</artifactId> <exclusions> <exclusion> <groupId>asm</groupId> <artifactId>asm</artifactId> </exclusion> <exclusion> <groupId>asm</groupId> <artifactId>asm-commons</artifactId> </exclusion> </exclusions> </dependency> {code} > 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)