Jerome, I wanted to let you know that a colleague of mine worked with Musachy and got this problem fixed for the next version (2.1.3) of XWork. I believe it will now only log the exception at a debug level. Chris
________________________________ From: Jerome ROBERT [mailto:jrm.rob...@gmail.com] Sent: Saturday, February 21, 2009 1:08 PM To: Vogel,Chris Cc: Struts Users Mailing List Subject: Re: Problem with Jboss 4.2.3.GA and convention plug-in 2.1.6 Chris, I haven't had much time to investigate on that problem since my last post (2 weeks ago) and unfortunately hadn't come to any resolution of the problem. In fact we tried to deploy on JBoss 5.0.0.GA and it solved the problem since its classloading policy seems to be more orthodox but by doing this we ran into an issue involving spring classpath scanning and the new jboss5 virtual file system "vfs". Now i've no other choice than to make the convention plug-in work with JBoss 4.2.3 whatever it may imply ! (hope it won't cost me a leg ! -sorry for that joke-) As far as I have investigated I can tell that the behaviour you described in your mail with regard to weblogic is precisely what happens in Jboss. I feel sorry not to be more helpful. I am going to resume investigation, i'll tell you if i make an interesting finding that may avoid the necessity to "hide" stack traces. Best regards Jérôme ROBERT 2009/2/20 Vogel,Chris <chris.vo...@edwardjones.com> Jerome, I found your thread about this in one of the various mail archive sites. I was wondering if you had come to any resolution of this. We are experiencing the same exception in WebLogic 10. However, with lots of looking at the Struts and XWorks code and remote debugging, we have determined that the stack trace is not an indication of a real error. Is that what you are finding as well? 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. I really like Struts 2 and the convention plug-in, but we have had to modify the XWorks code two other times before this because of the idiosyncrasies of WebLogic. Chris Vogel If you are not the intended recipient of this message (including attachments), or if you have received this message in error, immediately notify us and delete it and any attachments. If you no longer wish to receive e-mail from Edward Jones, please send this request to messa...@edwardjones.com. You must include the e-mail address that you wish not to receive e-mail communications. For important additional information related to this e-mail, visit www.edwardjones.com/US_email_disclosure <http://www.edwardjones.com/US_email_disclosure>
