I am using WAS 6.1.0.0 and have run into specified problems. By debuggint I have discovered the source of this problem and it has simple workaround - in ResolverUtil class the code for finding the JAR is as follows:
packageName = packageName.replace('.', '/');
ClassLoader loader = getClassLoader();
urls = loader.getResources(packageName);
while (urls.hasMoreElements()) {
...
}
This means that if I put into web.xml following init-param:
<init-param>
<param-name>ActionResolver.Packages</param-name>
<param-value>com.fg</param-value>
</init-param>
Line executes as: urls = loader.getResources("com/fg");
But on this version of WAS returned Enumeration has no items!
Playing with it a bit I found out that if I use it like that (notice the backslash at the end): urls = loader.getResources("com/fg/");
Enumeration founds items in it and thus JAR container could be found and ActionBeans are then resolved as expected.
So the workaround for me was quite simple - just specify this (notice the dot at the end of package specification):
<init-param>
<param-name>ActionResolver.Packages</param-name>
<param-value>com.fg.</param-value>
</init-param>
This works.
Fortunately this setting works even on Apache Tomcat (5.5.23) that is my secont target deployment environment.
I wonder if it's not a standard that when trying to access "directory" resource via classloader, backslash should be at the end?! If so, I think Stripes should adapt to this.
Bug
Closed
Blocker
I battled this issue around 1,5 years ago, so I'm not 100% sure about the details, but AFAIR it was due to the fact that classloader which WebSphere offers you isn't a UrlClassLoader, so Stripes scanning approach will not work for Jars.
We didn't use Stripes on the project, but we used to use the same scanning approach as Stripes uses.
To make it work, we changed the internals of our scanner to use Spring's PathMatchingResourcePatternResolver. It has some of the same features as Stripes's, but it doesn't support overlapping packages between Jars. If you have the same package name split over more than one jar, it will only look in the first Jar found which contains the a package with matching name.
/Jeppe