Question

This is a bit of a continuation of deploy struts app on jboss, but it’s different enough that I felt it warranted a new question.

In the other question, I was working with struts, but now I’m working with struts 2.
The tutorials here are broken up into struts tutorials and struts2 tutorials.

What I’m finding is that I need to have JAVA_HOME set to point to a jdk6 or the struts 2 samples won’t work. So in eclipse, I added another JBoss Server to my JBoss Server View (I’m using JBoss tools) and made it use jdk1.6.

My question is, is this normal? Does struts 2 require jdk6?

[EDIT]
The stack trace is huge, I’m pasting the first part of it below:

2009-11-22 05:13:42,625 INFO  [com.opensymphony.xwork2.config.providers.XmlConfigurationProvider] Parsing configuration file [struts.xml]
2009-11-22 05:13:42,890 DEBUG [com.opensymphony.xwork2.util.LocalizedTextUtil] Added default resource bundle 'org/apache/struts2/struts-messages' to default resource bundles = [org/apache/struts2/struts-messages, com/opensymphony/xwork2/xwork-messages]
2009-11-22 05:13:43,093 DEBUG [com.opensymphony.xwork2.config.providers.XmlConfigurationProvider] Loaded [BUILDER] {PackageConfig Name:struts-default namespace: parents:[]}
2009-11-22 05:13:43,203 DEBUG [com.opensymphony.xwork2.validator.DefaultValidatorFactory] Loading validator definitions.
2009-11-22 05:13:43,281 DEBUG [com.opensymphony.xwork2.interceptor.I18nInterceptor] new I18nInterceptor()
2009-11-22 05:13:43,281 DEBUG [com.opensymphony.xwork2.interceptor.I18nInterceptor] new I18nInterceptor()
2009-11-22 05:13:43,296 DEBUG [com.opensymphony.xwork2.interceptor.I18nInterceptor] new I18nInterceptor()
2009-11-22 05:13:43,328 DEBUG [com.opensymphony.xwork2.config.providers.XmlConfigurationProvider] Loaded [BUILDER] {PackageConfig Name:convention-default namespace: parents:[{PackageConfig Name:struts-default namespace: parents:[]}]}
2009-11-22 05:13:43,500 ERROR [STDERR] java.lang.Exception: Could not load invoker/war/WEB-INF/classes/org/jboss/invocation/http/servlet/InvokerServlet$GetCredentialAction.class
2009-11-22 05:13:43,500 ERROR [STDERR]  at com.opensymphony.xwork2.util.finder.ClassFinder.readClassDef(ClassFinder.java:745)
2009-11-22 05:13:43,500 ERROR [STDERR]  at com.opensymphony.xwork2.util.finder.ClassFinder.<init>(ClassFinder.java:148)
2009-11-22 05:13:43,500 ERROR [STDERR]  at org.apache.struts2.convention.PackageBasedActionConfigBuilder.findActions(PackageBasedActionConfigBuilder.java:295)
2009-11-22 05:13:43,500 ERROR [STDERR]  at org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:277)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:52)
2009-11-22 05:13:43,515 ERROR [STDERR]  at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:200)
2009-11-22 05:13:43,515 ERROR [STDERR]  at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:55)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:360)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:403)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:69)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:48)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:108)
2009-11-22 05:13:43,515 ERROR [STDERR]  at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3722)

Answer 1

No, Struts 2 doesn’t require Java 6 but Java 5 only (and can even be backported to Java 1.4 but this is another story).

That said, according to the trace you provided, it seems that the convention plug-in is trying to mess with other elements deployed in the server, invoker/war/WEB-INF/classes/org/jboss/invocation/http/servlet/InvokerServlet$GetCredentialAction.class in your case, it found a class that it thinks is an action. This is actually a well known problems with Jboss 4.2.3.GA and the convention plug-in 2.1.6. Quoting Chris Vogel in this thread that faced the same problem (with Weblogic):

In case you haven’t figured it out, I’ll tell you what I have learned.
Struts/XWorks scans for Action classes and does this by scanning directories
it is given by the class loader, not just by looking at JAR files. The
PackageBasedActionConfigBuilder that you see in your stack trace makes a
call to the getResources() method of the current thread’s context class
loader, which returns back directories in the class path for that class
loader. That call, for WebLogic, actually returns back the base directory
of the WebLogic domain. The ClassFinder class then scans all the
directories returned back from the getResources() method, which for WebLogic
includes every directory of the domain, and looks for Action classes. If it
finds a class that has a super class, it tries to load that super class and
this is where we actually see our exception. I’m wondering if JBoss’s class
loader is doing a similar thing. ClassFinder, if it can’t find the class
creates an exception and then prints the stack trace and does nothing else
with the exception. We are going to modify the ClassFinder class to not
print the stack trace.

AFAIK, there are two solutions:

• deploy on JBoss 5 since its classloading policy seems to be more orthodox or
• use the version 2.1.3 of XWork, the exception should be logged at a debug level with this version.

PS: I’ve successfully reproduced the behavior you describe (with a JDK 6), I find the same trace in my logs, but this doesn’t seem to prevent the application from working (as I wrote, XWork’s developer only changed the logging level in version 2.1.3). Is this what you observe too?