Yoav, thank you for your reply.

The classes are all packaged up neatly into .wars and .jars inside of a
.ear. I have no reason to believe they are not all being loaded by the same
classloader, but JBoss is a heavy beast, and I could be wrong. I did do a
server stop/start to avoid any weird hot-deployment issues. I also made
sure JAVA_HOME was set and pointing to my jdk1.4.2 directory.

Code-wise, I provided a simplified description originally. The actual code
is not ready for any sort of peer-review. Also, I am not satisfied with the
architecture as described below, and will be refactoring it. The problem
will probably, at that point, disappear.

I guess I'm just checking for a known problem of some kind, some specific
bug that I should be looking for that displays these kinds of symptoms.

Thank you, and thanks to the whole Tomcat team! This is one hell of a
piece of work.

Bill

On Thu, 8 Jan 2004, Shapira, Yoav wrote:

> Howdy,
> Can you share the relevant code?  Are the classes all being loaded from
> the same classloader?
>
> Yoav Shapira
> Millennium ChemInformatics
>
>
> >-----Original Message-----
> >From: Bill Wadley [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, January 08, 2004 11:29 AM
> >To: [EMAIL PROTECTED]
> >Subject: odd subclassed-servlet behavior
> >
> >
> >Hello!
> >
> >I have just upgraded from JBoss/Jetty 3.0.4 to JBoss/Tomcat 3.2.3, and
> >have noticed some rather odd behavior.
> >
> >I have 3 servlets: SuperClazz <|--- SubClazz <|--- SubSubClazz
> >
> >SuperClazz subclasses HttpServlet but is not meant to be called
> directly,
> >but SubClazz and SubSubClazz are both standalone servlets and I call
> them
> >directly depending on what I need. SubClazz does general things, and
> >SubSubClazz does more specific things. SubClazz delegates to SuperClazz
> >and SubSubClazz delegates to SubClazz as needed. This was working in
> JBoss
> >3.0.4 and Jetty.
> >
> >However, in Tomcat 4.1.29 just now I observed that calling SubClazz
> >directly resulted in SubSubClazz getting the call, then execution
> tracing
> >straight to SuperClazz, _then_ SubClazz. SubSubClazz was the last thing
> >executing before it failed. (That failure is the thing; SubSubClazz
> doesn't
> >have what it takes to handle my request, and I don't want it called.)
> >
> >Here is an example of my problem. By calling the URL:
> >   http://localhost/myApp/servlet/SubClazz?a=1
> >
> >I get this output from the running server:
> >
> >10:23:24,020 INFO  [STDOUT] [SubSubClazz.doGet] GOT HERE 1
> >10:23:24,020 INFO  [STDOUT] [SubSubClazz.doPost] GOT HERE 1
> >10:23:24,020 INFO  [STDOUT] [SuperClazz.doPost] GOT HERE 1
> >10:23:24,021 INFO  [STDOUT] [SuperClazz.doPost] GOT HERE 2
> >10:23:24,021 INFO  [STDOUT] [SuperClazz.doPost] GOT HERE 3
> >10:23:24,021 INFO  [STDOUT] [SuperClazz.doPost] GOT HERE 4
> >10:23:24,021 INFO  [STDOUT] [SuperClazz.doPost] GOT HERE 5
> >10:23:24,021 INFO  [STDOUT] [SuperClazz.doPost] GOT HERE 6
> >10:23:24,021 INFO  [STDOUT] [SubClazz.doPost] GOT HERE 1
> >10:23:24,021 INFO  [STDOUT] [SubClazz.doPost] GOT HERE 2
> >10:23:24,021 INFO  [STDOUT] [SuperClazz.doAThing] GOT HERE 1
> >10:23:24,023 ERROR [Engine] StandardWrapperValve[SubSubClazz]:
> >Servlet.service() for
> >servlet SubSubClazz threw exception
> >java.lang.IllegalStateException: Cannot forward after response has been
> >committed
> >        at
> >org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDis
> patc
> >her.java:368)
> >        at
> >org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispa
> tche
> >r.java:356)
> >        ...bad stuff happening since correct calling order is not
> >happening...
> >
> >Can anybody explain why:
> >
> >SubClazz is being skipped and SubSubClazz is getting the request in the
> >first place?
> >
> >SubClazz is not getting the super() call, but instead it is going
> straight
> >to SuperClazz?
> >
> >SubClazz is getting the call after SuperClazz, especially after having
> been
> >skipped originally?
> >
> >
> >Thanks very much in advance for any light that can be shed on this
> >behavior.
> >
> >Bill Wadley
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> This e-mail, including any attachments, is a confidential business communication, 
> and may contain information that is confidential, proprietary and/or privileged.  
> This e-mail is intended only for the individual(s) to whom it is addressed, and may 
> not be saved, copied, printed, disclosed or used by anyone else.  If you are not 
> the(an) intended recipient, please immediately delete this e-mail from your computer 
> system and notify the sender.  Thank you.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


Bill

-- 
Bill Wadley
[EMAIL PROTECTED]
972.866.8200 x207

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to