RE: HttpServletResponse.setStatus and setContentType (solved)

[Dunlop, Aaron]

For future reference by anyone else facing the same problem (Tomcat changing 
the Content-type from text/xml to text/html on 500 server errors - e.g. SOAP 
Faults)

The solution I've arrived at is to use getWriter() instead of getOutputStream 
and to explicitly close the Writer after writing the response (both are 
required - explicitly closing the OutputStream wasn't sufficient, nor was using 
getWriter without an explicit close).

So my working code ends up looking like:

servletResponse.setContentType("text/xml");
...
soapResponse.save(servletResponse.getWriter());
servletResponse.getWriter().close();


Hope that helps anyone else with a similar issue.

Aaron Dunlop


-Original Message-
From: Dunlop, Aaron 
Sent: Wednesday, December 08, 2004 9:53 AM
To: Tomcat Users List
Subject: RE: HttpServletResponse.setStatus and setContentType


Thanks for the suggestion, Yoav, but thus far in my experiments, sendError 
seems to

--Send "Content-Type: text/html;charset=utf-8"
--Ignore the content I've written (using ServletResponse.getOutputStream()) and 
instead send the generic Tomcat HTML 'Server Error' message. Which of course is 
even worse for a web service client, since it's not well-formed XML ;-)

I'm trying:

servletResponse.setContentType("text/xml");
...
soapResponse.save(servletResponse.getOutputStream());
servletResponse.sendError(500);

(where soapResponse.save writes the XML to the specified OutputStream)

Using sendError(int, String) does effectively the same thing, except with the 
string message included in the HTML response.


When I instead tried:
servletResponse.setContentType("text/xml");
...
servletResponse.setStatus(500);
soapResponse.save(servletResponse.getOutputStream());

I got the appropriate XML contents back, but with Content-Type set to 
"text/html;charset=utf-8" instead of "text/xml"


There must be a way to do this - plenty of people use Tomcat to handle SOAP web 
services...I'll check the Axis source and see how they handle it. But any 
suggestions would be welcome.

Thanks again,
Aaron Dunlop

-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 08, 2004 5:59 AM
To: Tomcat Users List
Subject: RE: HttpServletResponse.setStatus and setContentType



Hi,
You know, the JavaDoc for HttpServletResponse#setStatus is pretty clear
on this ;)  Use sendError for errors, setStatus for normal responses.

Yoav Shapira http://www.yoavshapira.com
 

>-Original Message-
>From: Dunlop, Aaron [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, December 07, 2004 5:44 PM
>To: Tomcat Users List
>Subject: HttpServletResponse.setStatus and setContentType
>
>I have a standard HTTP servlet acting as an XML web service endpoint,
>running on an embedded Tomcat 5.0.30.
>
>I of course use HttpServletResponse.setContentType to specify that the
>response is "text/xml". When the request is successful and I set a 2xx
HTTP
>response code, the Content-Type header looks as expected. But if an
error
>is detected and I return an HTTP error code (using setStatus), the
Content-
>Type header specifies "text/html;charset=utf-8" instead of "text/xml".
>
>It doesn't seem to matter whether I call setContentType before or after
>setStatus, and all the 4xx and 5xx codes I've tried trigger this
behavior.
>
>I'd just ignore it, but unfortunately, the WSI Basic Profile specifies
that
>a SOAP fault must return a 500 along with the XML fault. And some
clients
>(ahem... .NET...) seem to choke trying to parse the fault when the
wrong
>content-type is returned.
>
>I didn't find anything in the specs or documentation that indicated to
me
>that this was required behavior, but perhaps I'm missing something.
>
>Any ideas?
>
>Thanks in advance,
>Aaron Dunlop
>
>
>-
>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]



-
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]

RE: HttpServletResponse.setStatus and setContentType

[Dunlop, Aaron]

Thanks for the suggestion, Yoav, but thus far in my experiments, sendError 
seems to

--Send "Content-Type: text/html;charset=utf-8"
--Ignore the content I've written (using ServletResponse.getOutputStream()) and 
instead send the generic Tomcat HTML 'Server Error' message. Which of course is 
even worse for a web service client, since it's not well-formed XML ;-)

I'm trying:

servletResponse.setContentType("text/xml");
...
soapResponse.save(servletResponse.getOutputStream());
servletResponse.sendError(500);

(where soapResponse.save writes the XML to the specified OutputStream)

Using sendError(int, String) does effectively the same thing, except with the 
string message included in the HTML response.


When I instead tried:
servletResponse.setContentType("text/xml");
...
servletResponse.setStatus(500);
soapResponse.save(servletResponse.getOutputStream());

I got the appropriate XML contents back, but with Content-Type set to 
"text/html;charset=utf-8" instead of "text/xml"


There must be a way to do this - plenty of people use Tomcat to handle SOAP web 
services...I'll check the Axis source and see how they handle it. But any 
suggestions would be welcome.

Thanks again,
Aaron Dunlop

-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 08, 2004 5:59 AM
To: Tomcat Users List
Subject: RE: HttpServletResponse.setStatus and setContentType



Hi,
You know, the JavaDoc for HttpServletResponse#setStatus is pretty clear
on this ;)  Use sendError for errors, setStatus for normal responses.

Yoav Shapira http://www.yoavshapira.com
 

>-Original Message-
>From: Dunlop, Aaron [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, December 07, 2004 5:44 PM
>To: Tomcat Users List
>Subject: HttpServletResponse.setStatus and setContentType
>
>I have a standard HTTP servlet acting as an XML web service endpoint,
>running on an embedded Tomcat 5.0.30.
>
>I of course use HttpServletResponse.setContentType to specify that the
>response is "text/xml". When the request is successful and I set a 2xx
HTTP
>response code, the Content-Type header looks as expected. But if an
error
>is detected and I return an HTTP error code (using setStatus), the
Content-
>Type header specifies "text/html;charset=utf-8" instead of "text/xml".
>
>It doesn't seem to matter whether I call setContentType before or after
>setStatus, and all the 4xx and 5xx codes I've tried trigger this
behavior.
>
>I'd just ignore it, but unfortunately, the WSI Basic Profile specifies
that
>a SOAP fault must return a 500 along with the XML fault. And some
clients
>(ahem... .NET...) seem to choke trying to parse the fault when the
wrong
>content-type is returned.
>
>I didn't find anything in the specs or documentation that indicated to
me
>that this was required behavior, but perhaps I'm missing something.
>
>Any ideas?
>
>Thanks in advance,
>Aaron Dunlop
>
>
>-
>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]



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

HttpServletResponse.setStatus and setContentType

[Dunlop, Aaron]

I have a standard HTTP servlet acting as an XML web service endpoint, running 
on an embedded Tomcat 5.0.30. 

I of course use HttpServletResponse.setContentType to specify that the response 
is "text/xml". When the request is successful and I set a 2xx HTTP response 
code, the Content-Type header looks as expected. But if an error is detected 
and I return an HTTP error code (using setStatus), the Content-Type header 
specifies "text/html;charset=utf-8" instead of "text/xml".

It doesn't seem to matter whether I call setContentType before or after 
setStatus, and all the 4xx and 5xx codes I've tried trigger this behavior.

I'd just ignore it, but unfortunately, the WSI Basic Profile specifies that a 
SOAP fault must return a 500 along with the XML fault. And some clients 
(ahem... .NET...) seem to choke trying to parse the fault when the wrong 
content-type is returned.

I didn't find anything in the specs or documentation that indicated to me that 
this was required behavior, but perhaps I'm missing something.

Any ideas?

Thanks in advance,
Aaron Dunlop


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

Thread handling in Tomcat 4.x

[Dunlop, Aaron]

Is there any scenario in which Tomcat 4.0 or 4.1 will kill off processor
threads?

I know that under apache, it is possible to limit the number of spare
processes, in which case the controller process will kill off extras when
load decreases.

Alternatively, is there any error condition under which a thread will be
considered hung or otherwise corrupted and killed off?

Our application maps certain objects on a per-thread basis, and I'm worried
that we may end up with memory leaks when objects remain referenced in our
map even though the thread they are assigned to is no longer valid. (And yes
- I know this is probably a bad design, and we're looking into some
refactoring there, but not a week before a release if we can avoid it...)

Either there hasn't been any discussion of this topic in the archives or
(more likely) I just didn't hit on the right combination of keywords to
search on. And I can't convince myself one way or that other from the code.
;)

Thanks in advance,
Aaron

---
Aaron Dunlop
Product Development Engineer
TransCore Commercial Services, Inc.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Cache-control on a per-application basis

[Dunlop, Aaron]

Title: Cache-control on a per-application basis





When running Tomcat 3.2 standalone, is there a way to configure cache-control directives on a per-application basis? Or is it necessary to add cache-control, pragma no-cache, etc directives to each JSP page?

I'm migrating an app from WebSphere which defaults to sending cache-control info restricting cacheing with each request.

Thanks,
Aaron Dunlop




Aaron Dunlop
Product Development Engineer
DAT Services, TransCore Commercial Service Group
[EMAIL PROTECTED]