I am facing this same issue and did more investigation to trace the problem. Initially I thought the problem could be that PackageBasedActionConfigBuilder.findActions() is not able to trace the WAR when it is deployed inside an EAR. But I was wrong and the real problem is related to the WAR's protocol recognized as "vfsfile" protocol. I am not part of the Struts developer group but I tried by best to learn internals of Struts and hope my troubeshooting could help resolve the issue.
I am using Struts 18.104.22.168 on JBoss 5.1. I have configured the below constant in struts.xml as I am using JBoss.
<constant name="struts.convention.action.fileProtocols" value="jar,vfsfile,vfszip" />
My troubleshooting involved 3 scenarios based on the way the WAR is deployed. Cases 1 & 2 WAR is deployed inside WAR; exploded and packaged respectively, investigate where the failure happens. Case 3 WAR is deployed directly without EAR, shows why it works correctly without the issues in Cases 1 & 2.
Case 1: EAR containing a WAR deployed as exploded
Step (1): [Detecting the WAR] In URLSet.includeClassesUrl() method (invoked at PackageBasedActionConfigBuilder.buildUrlSet() line: 418), rootUrlEnumeration returns vfsfile:/C:/_server/jboss-eap-5.1/jboss-as/server/MyServer/deploy/MyTest.ear/MyWeb.war/WEB-INF/classes and after truncating "WEB-INF/classes", the WAR's url is vfsfile:/C:/_server/jboss-eap-5.1/jboss-as/server/MyServer/deploy/MyTest.ear/MyWeb.war. Please note that the WAR's protocol is "vfsfile" and not "vfszip", though it is an archive (exploded in my case).
Step (2): [Converting protocol] The url conversion from "vfsfile" to "file" protocol fails because the URLUtil.isJBoss5Url(URL) method considers only "vfszip" and "vfsmemory" protocols. The WAR is included as it is with "vfsfile" protocol.
Step (3): [Built URL set] The URL of the WAR is included to the UrlSet passed as argument to the constructor of ClassFinder (at PackageBasedActionConfigBuilder.findActions() line: 377).
Step (4): [Finding actions] While trying to add all classNames in the WAR file (at ClassFinder.<init>() line: 144) the util method jar(URL) again tries convert "vfsfile" to "file" protocol and returns null. Henceforth the classNames are returned as an empty list.
And so, the plugin can't find the actions, though it tried looking into the WAR.
I also tried altering the value "vfsfile" protocol to "vfszip" in the debugger (to skip the vfsfile problem), but ClassFinder.jar(JarInputStream) fails while recognizing WAR as a JAR.
Case 2: EAR containing a WAR deployed as package
Step (1): rootUrlEnumeration returns vfszip:/C:/_server/jboss-eap-5.1/jboss-as/server/MyServer/deploy/MyTest.ear/MyWeb.war/WEB-INF/classes as opposted to "vfsfile" protocol in Case 1.
Step (2): The WAR's protocol is "vfszip", the url is successfully converted to "file" protocol as opposed to Case 1. (file:/C:/_server/jboss-eap-5.1/jboss-as/server/MyServer/deploy/MyTest.ear/MyWeb.war)
Step (3): Same as Case 1.
Step (4): As the protocol is "file", it checks if the file is a JAR and at JarURLConnection.getJarFile() gets a java.io.FileNotFoundException: C:_server\jboss-eap-5.1\jboss-as\server\MyServer\deploy\MyTest.ear\MyWeb.war (The system cannot find the path specified), as it is directly pointing to a file inside an archive in the file system. It catches the exception and calls the util method file(URL), but returns no classes.
Case 3: WAR deployed directly
Step (1): rootUrlEnumeration returns vfszip:/C:/_server/jboss-eap-5.1/jboss-as/server/MyServer/deploy/MyWeb.war/WEB-INF/classes.
Step (2): Same as Case 2. (file:/C:/_server/jboss-eap-5.1/jboss-as/server/MyServer/deploy/MyWeb.war)
Step (3): Same as Case 1.
Step (4): As the protocol is "file", it checks if the file is a JAR and JarURLConnection.getJarFile() gets the JAR file without any FileNotFoundException. The util jar(URL) returns all the class names in the WAR file!
The issue in Case 1 when compared with Case 3 is the failure of conversion from "vfsfile" protocol of the WAR to "file" protocol (support for exploded WAR).
The issue in Case 2 when compared with Case 3 is the FileNotFoundException while referencing to the WAR inside an EAR archive in the file system.
I think both the issues need to be addressed for the bug to be resolved.
Please correct me if my assumptions about the source code are wrong.