OK, I was wrong, so far, not good. It doesn't seem to matter which ClassLoader the server is using (JBoss' or Tomcat's -- I am modifying jboss-service.xml as you suggest) -- I still encounter this problem.
I deploy Foo.war for the first time -- all is OK. No exceptions during deployment, and the app runs correctly.
I redeploy Foo.war (hot), having made some changes (not sure exactly what changes trigger this and what changes don't yet, sometimes it happens, sometimes not, it seems -- see below).
I get this error message:
Error [ActionServlet] javax.servlet.UnavailableException: Cannot initialize RequestProcessor of class FooRequestProcessor: java.lang.NullPointerException
(In the past I have also seen ClassNotFoundException on FooRequestProcessor.class instead of NullPointerException there).
I'm not sure what would cause this NullPointerException, but all FooRequestProcessor does is override processRoles and processActionPerform (perhaps init and destroy need to be overridden for some reason?).
So, I go into the struts-config.xml file and comment out the "processorClass" attribute of my Controller configuration, changing it to this:
<controller/>
I figure that's where the problem is, so I'll just get rid of it and see. I rebuild and redeploy, but I get the same error message!
Error [ActionServlet] javax.servlet.UnavailableException: Cannot initialize RequestProcessor of class FooRequestProcessor: java.lang.NullPointerException
How is this possible, when struts-config.xml knows nothing anymore about FooRequestProcessor? Somehow something stale is still being considered . . .
So I'll go it one better, I'll even make sure FooRequestProcessor.class is no longer in the war file at all, and redeploy (sorry if I've overlooked something blatantly simple at this point).
Again:
Error [ActionServlet] javax.servlet.UnavailableException: Cannot initialize RequestProcessor of class FooRequestProcessor: java.lang.NullPointerException
I get the feeling I am being ignored here . . .
So I go back and set struts-config.xml, etc., back to their original states. Then I stop my server, clean out the work and tmp directories, and remove Foo.war from the deploy directory. I restart my server with a clean slate.
I run ant and hot deploy, and, this time, everything starts up OK (no matter whether NullPointerException or ClassNotFoundException was the original culprit before the server restart).
But, how many more hot deploys until the same error crops up again? Using the Tomcat ClassLoader, the answer is now 1 (didn't seem to always be that way for me). Using the JBoss ClassLoader, it seems to vary. If I don't change anything and just keep redeploying the same war file over and over, it never seems to happen.
Anyone have any idea what is going on here? I sense that there is a problem with "unloading" of classes here, but this only seems to happen with Struts apps (though I can't say I have tested extensively with JBoss 3.2.x-Tomcat 5) . . . Or am I just overlooking something simple?
Erik
Erik Weber wrote:
Thanks a lot guys.
I am trying the Tomcat classloader. So far so good!
Erik
Brad Balmer wrote:
I used to have lots of issues with the JBoss classloader until I found out
about how to turn it off and use the Tomcat one instead.
Under the \jbossweb-tomcatXX.sar\META-INF is the jboss-service.xml. Look
for the UseJBossWebLoader attribute (towards the top). This, by default is
set to true. Try changing it to false to use the Tomcat one.
--Brad
-----Original Message-----
From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Monday, August 02, 2004 11:23 AM
To: Struts Users Mailing List
Subject: Re: ActionServlet class loading problem
There is nothing an application (or an application framework) can
really do to affect how servlet containers do application reloads. I've had lots of success on pure Tomcat 5 installations, but I have
heard hearsay about problems with the JBoss class loader scheme (which
completely replaces the standard Tomcat mechanisms). That would tend
to suggest the JBoss user list as a place to ask about similar
experiences and possible solutions.
In any container, obvious things to double check, of course, include
having all the JAR files involved inside your /WEB-INF/lib directory
(as opposed to a shared directory in the server), and otherwise making
sure that you don't have more than one copy of the classes visible. That tends to be the root cause of most class loader related issues.
Craig
On Mon, 02 Aug 2004 01:02:41 -0400, Erik Weber <[EMAIL PROTECTED]>
wrote:
During hot deployment in JBoss 3.2.4 and 3.2.5 / Tomcat 5 (both on Red Hat and Windows 2000), ActionServlet is failing to initialize and logging this message to standard out not every time, but quite often:
Error: [ActionServlet] javax.servlet.UnavailableException: Cannot initialize RequestProcessor of class MyRequestProcessor: java.lang.ClassNotFoundException: No ClassLoaders found for: MyRequestProcessor
There seems to be a pattern to this occurrence but I won't go into the details of it here unless someone asks, except to say, if you just keep redeploying the same app without any changes to struts-config.xml and without redeploying other apps in between, it doesn't seem to happen.
Every time this happens, I have to clean out the server tmp directories and restart the server.
Is this a bug in Struts or in Tomcat? I would appreciate any tips. This doesn't seem to happen when I don't plug in my own RequestProcessor.
Thanks, Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
