Stripes

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

Having thought a little more about it, I believe that WebSphere gives a UrlClassloader so that you can find classes in WEB-INF/classes, but when you try to look in dependent Jars you run into a problems (I don't have a WebSphere here so I can't confirm what the exact problem was).
If the Stripes maintainers are interested I can share a version of our ClasspathScanner which uses the Spring PathMatchingResourcePatternResolver (for inspiration).

/Jeppe

Found a way to scan the WEB-INF/lib for jars in WebSphere. I have made a WebSphere specifik ResolverUtil used if the ClassLoader is an implementation from IBM. It was not possible to plug in the new functionality easily so I had to make a few adjustments in the ResolverUtil and the classes using it. I also made a factory class to create an instance of the correct type of ResolverUtil depending on the ClassLoader.

Would be nice to be able to override the ResolverUtilFactory by configuration to make it easier to extend it in the future if necessarily (not implemented).

This functionality is very important for us since we have quiet a few jars with actions, converters etc. used a cross several projects.

Attaching a patch for the 1.5.x branch.

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.

Assuming the fix is this simple, we'll get it fixed in 1.5.2.

I'm currently trying to get our application (which uses Stripes 1.5) deployed into WebSphere 7.0 and am also running into the same problem.

I have a .war which I'm deploying where in the WEB-INF/lib I have our .jar packaged up with our ActionBean classes.

As per Jan Novotný's workaround (with the full stop at the end of the ActionResolver.Packages parameter) I can also confirm this workaround finds the ActionBeans in the .jar located in the WEB-INF/lib for WebSphere 7.0

I managed to get it to work as well (WAS 6.1.x). What encounter though was that the end dot only works for ActionBeans located in jar files in WEB-INF/lib/. ActionBeans located in WEB-inf/classes/ are not found.

Here is my setup. com.example.commons.web.stripes is the name of the package from where to scan for ActionBeans in my jar (WEB-INF/lib/common-stripes.jar). and com.example.myproject.web is where I want Stripes to scan for ActionBeans in my current project (WEB-INF/classes/). To get it to work I have to put a trailing dot at the end av my jar package name but not my project package name.

<init-param>
<param-name>ActionResolver.Packages</param-name>
<param-value>
com.example.commons.web.stripes.,
com.example.myproject.web
</param-value>
</init-param>

Anyone else who can confirm this behavior?

My suggestion is to make the ResolverUtil append a dot (or slash, regarding to Jan Novotnýs comment) if looking for ActionBeans in a jar and remove it (if there is one) when looking for ActionBeans in WEB-INF/classes/.

I can only confirm that I have all my ActionBeans in JAR. So it might be as well as Tony Dalbrekt wrote.

Thank you for the patch. I went with a different implementation that works for all the app servers we've tested, including WAS 7. Please try it out and let us know if this does not work for you.

we are facing same problem with stripes 1.5.3 on websphere 6.1

I'm using tomcat6 and stripes 1.5.6.

No matter how I configure ActionResolver.Packages with full stop or not, the actions in jar still couldn't be found. Anyone can point me to right direction please?

Damien, if you turn on debug logging you'll get a wealth of information about where Stripes is looking for ActionBeans and why it might not find them.

Thanks Ben. I've done some tests and it seems like these is no problem with scanning the beans, the problem is the annotations in the beans are not processed.

The annotations like
@UrlBinding("/user/manager/groups.html")
@Table(name="group_info")

do not work.

If I add all these java files to the source tree directly, then the annotations work all well.

Does the jar do something special to the annotation? Is this a common issue?

Hi,
I have recently started learning Stripes as a replacement for Struts1. Stripes I find is an excellent product. Onr thing I cannot resolve is using the jar files for all the classes in the Stripes-example application. Here is what I have done. Created a jar file in WEB-INF/lib. Inserted all the class files of all the java files. In order to ensure that Stripes-action resolver does not see the package files I have renamed the net folder in classes to savenet. I bring up Tomcat 7. I connect to Stripes-example. index.html renders. I click on bugzooky. Login.jsp is rendered. I enter user name password and the app throws exception saying it cann find the LoginActionBean. Prestty straight forward to recreate. Wonder if someone can help. I am grateful for the support.

Andy

Hi,

Turns out I had a problem with the jar file itself which I found at the link below. I have reproduced part of it where I found the issue and the solution.

http://www.mail-archive.com/stripes-users@lists.sourceforge.net/msg03220.html

Re: [Stripes-users] ActionBean binding problem SOLVED

feh
Wed, 02 Sep 2009 08:05:53 -0700

It turns out my obfuscation tool was removing the directory entries from my
jar file. Once I configured things to keep the directories entries, stripes
now finds the action beans.

Aaron - thanks for pointing me in the right direction!

feh wrote:
>
>
> My jar file doesn't have any entries that end in '/'. I don't know if I've
> ever seen a jar file with entries like that.
>
> I don't see an option on the jar command that seems to address this -
> could you explain how such entries could be included in the jar file?
>
> Thanks!
>
>
>
> Aaron Porter-3 wrote:
>>
>> If you run "jar -tf myjar.jar" do you have entries that end in "/" like
>> "com/myproject/stripes/" ? If you don't Stripes won't be able to scan
>> the classpath because it uses directory entries IIRC.
>>
>> Aaron
>>
--Andy

Please note: you need to set com.ibm.ws.webcontainer.invokeFiltersCompatibility=true in the webcontainer custom properties of WAS (ie. not the JVM props!!), to make filters work when there's no real resource in the url.