Re: two questions about websocket in tomcat7.0.30
On 23 Nov 2012, at 03:06, zane_zh...@wistronits.com
zane_zh...@wistronits.com wrote:
Dears,
My PC environment are windows XP professional Version 2002 Service Pack 3,
JDK1.6, Tomcat7.0.30.
my Java web project is an internet online chat-room based on websocket. I run
the local-host service in Tomcat and then connect my chat-room in chrome,
if the connection between server and browser is OK, the websocket client side
function onopen() will pop up a message open.
But, the point is if I open several pages at same time, I can see all of
pages pop up the message open, it means every connection of page to server
is OK.
but when I try to send some words to server, The server has no response ( in
the other word, the server side function onTextMessage() is not called),
it happen in part of the pages not all of them. I would like to know if you
encounter the same problem.
Excuse me, the second question: how to set the maximum idle time of
connection of websocket.
The set up in server.xml does not work:
Connector port=8080 protocol=HTTP/1.1
connectionTimeout=5000
redirectPort=8443 /
!-- A Connector using the shared thread pool--
!--
Connector executor=tomcatThreadPool
port=8080 protocol=HTTP/1.1
connectionTimeout=5000
redirectPort=8443 /
--
These is part of the client side code:
function startWebSocket() {
if ('WebSocket' in window)
{ws = new WebSocket(ws://localhost:8080/MyWebSocket/mywebsocket.do);
}
else if ('MozWebSocket' in window)
{ws = new
MozWebSocket(ws://localhost:8080/MyWebSocket/mywebsocket.do);
}
else
alert(not support);
ws.onmessage = function(evt) {
alert(evt.data);
};
ws.onopen = function(evt) {
alert(open);
};
ws.onclose = function(evt) {
alert(close);
};
}
How have you configured the WebSocket Servlet?
p
And part of the server side code:
public class MyMessageInbound extends MessageInbound {
@Override
protected void onBinaryMessage(ByteBuffer arg0) throws IOException {
// TODO Auto-generated method stub
}
@Override
protected void onTextMessage(CharBuffer msg) throws IOException {
System.out.println(msg.toString());
for (MessageInbound messageInbound : InitServlet.getSocketList()) {
WsOutbound outbound = messageInbound.getWsOutbound();
CharBuffer buffer = CharBuffer.wrap(msg);
outbound.writeTextMessage(buffer);
outbound.flush();
}
}
@Override
protected void onClose(int status) {
InitServlet.getSocketList().remove(this);
super.onClose(status);
System.out.println(getTime()+ connection is closed);
}
@Override
protected void onOpen(WsOutbound outbound) {
super.onOpen(outbound);
InitServlet.getSocketList().add(this);
System.out.println(getTime()+ connection is open);
}
public String getTime(){
Date now = new Date();
SimpleDateFormat dateFormat = new SimpleDateFormat(/MM/dd
HH:mm:ss);
String NowTime = dateFormat.format( now );
return NowTime;
}
}
I would eagerly look forward to your reply.
**
This e-mail is confidential for WistronITS corp. It may be legally
privileged. If you are not the Addressee you may not copy,
forward, disclose or use any part of it. If you have received this message in
error, please delete it and all copies from your
system and notify the sender immediately by return e-mail.Internet
communications cannot be guaranteed to be timely,
secure, error or virus-free. The sender does not accept liability for any
errors or omissions.
***
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Upgrading from Apache Tomcat 7.0.22 to 7.0.32
Hi, What is the best way to upgrade from Tomcat version 7.0.22 to 7.0.32? I have gone through the link http://tomcat.apache.org/migration.html but not sure what steps should be followed for upgrade. We are installing Tomcat using the zip way. Thanks Regards, Aditi
Re: How to stop mod_jk.log in apache 2.2
Hi Felix, Thanks for the link however I could not find how to stop mod_jk logs on Windows. There is a command line parameter given for Linux --disable-trace but could not find anything for windows. Can I set JKLoglevel in some file? If yes, where to set it? I am afraid of doing some testing as its our production server. If you provide some steps, that would really help me. Regards, Lokesh On Fri, Nov 23, 2012 at 12:13 PM, Felix Schumacher felix.schumac...@internetallee.de wrote: lokesh borse lokesh@gmail.com schrieb: Hi, We are using Apache 2.2 installed on windows server 2008 Enterprise edition, 64 bit. I am extremely surprised that the log file mod_jk.log (Apache2.2/logs) is increasing so rapidly to 21 GB and I am having space issue due to the same. I did search on internet but could not find any useful. Please help me with How to stop mod_jk.log in apache 2.2. Have you looked at http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html? You might find JkLogLevel interesting. Regards Felix Regards, Lokesh - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrading from Apache Tomcat 7.0.22 to 7.0.32
Sorry for not mentioning the platform details. The platform is windows on which upgrade has to be done.
Re: Page not redirected after waitFor() call on Process object.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andrei,
On 11/21/12 4:42 AM, Andrei Petru Mura wrote:
TheProcessing.logoutSubscriberByMac(mac) has that code on it:
public static void logoutSubscriberByMac(String mac) { try {
Process proc = Runtime.getRuntime().exec(logout subscriber
command); proc.waitFor(); //here is the problem
You almost certainly have a problem with stream management: if you
don't drain both the output stream and error stream of the process,
then your code can hang. Likewise, if you don't close the standard
input stream to the process, the child process may block waiting for
input.
It sounds silly, even if you use little or no standard input or output
from your child process, but failure to manage these streams can and
will hang up your Java code.
You can either write multi-threaded code to handle all these streams,
or you can use one of the several high-quality utility libraries out
there that can wrap Runtime.exec for you and take care of this kind of
stuff.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlCvwUoACgkQ9CaO5/Lv0PCbcACfXgar8R/7jGDrV6Bjgd0FbXEM
OBcAn2aPFGndEjUmdOynJsjHbJF2RaqD
=QFpl
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tagging log messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johan, On 11/21/12 11:48 AM, Johan Gunnarsson wrote: Is there some way to tag log messages in log4j.properties depending on different criteria? If you are definitely going to be using log4j, try reading about Nested Diagnostic Contexts. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCvweEACgkQ9CaO5/Lv0PDpZQCeKHbVRkUg+gegqrI4Hc36IJ/9 q44An3lkxj3xWZ3tAvI97j+R4A5QXxjf =gRet -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat upgrade from 6.0.20 to 6.0.36
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 11/22/12 3:19 AM, Pid * wrote: Compare the configuration, adjust the new one as required and as per the docs. NB don't blindly copy old config files. Stop the old one. Start the new one. Deploy your app to it. 3. Profit. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCvwisACgkQ9CaO5/Lv0PBBqACgh9vbmUutCfWHal8TSyCoJVd+ UxEAn2fSKCgxxUlLpJqetblwtEFxFycH =ZkK7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the Tomcat Native Library can only connect over ipv6 But not over ipv4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zorro, On 11/22/12 5:07 PM, Zorro wrote: Hi, I tried to use the Apache Tomcat Native Library 1.1.24 using APR version 1.4.6 with my Tomcat 7.0.32 server but after installing it I cannot connect over ipv4. Using Tomcat with the Native Library on Fedora 14 everything starts up fine. However a telnet 127.0.0.1 80 gives a 'Connection refused'. But with a telnet ::1 80 I can connect to Tomcat! Using the http-bio-80 connector I can connect to Tomcat over ipv4 as well over ipv6. Both telnet 127.0.0.1 80 and telnet ::1 80 do connect to Tomcat. Is there a way to use the Apache Tomcat Native Library also for ipv4 connections? Try setting address=127.0.0.1 in your Connector. Or 0.0.0.0 if you want to listen on all IPv4 interfaces. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCvyRsACgkQ9CaO5/Lv0PDN0QCghJbWT49Kd9GoYRMvCMmv/vnH Y2wAoIQDs4o/vDutxV/9MMJJeA8aqHPP =tsi7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the Tomcat Native Library can only connect over ipv6 But not over ipv4
Op 23-11-2012 20:06, Christopher Schultz schreef: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zorro, On 11/22/12 5:07 PM, Zorro wrote: Hi, I tried to use the Apache Tomcat Native Library 1.1.24 using APR version 1.4.6 with my Tomcat 7.0.32 server but after installing it I cannot connect over ipv4. Using Tomcat with the Native Library on Fedora 14 everything starts up fine. However a telnet 127.0.0.1 80 gives a 'Connection refused'. But with a telnet ::1 80 I can connect to Tomcat! Using the http-bio-80 connector I can connect to Tomcat over ipv4 as well over ipv6. Both telnet 127.0.0.1 80 and telnet ::1 80 do connect to Tomcat. Is there a way to use the Apache Tomcat Native Library also for ipv4 connections? Try setting address=127.0.0.1 in your Connector. Or 0.0.0.0 if you want to listen on all IPv4 interfaces. - -chris Hi Chris, Thank you for your response. Indeed setting the address attribute to 0.0.0.0 in the Connector element solves the issue. Tomcat is then indeed listening to all IPv4 interfaces. Though connecting over IPv6 is not possible then. Regards, Harm-Jan Zwinderman - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the Tomcat Native Library can only connect over ipv6 But not over ipv4
Zorro wrote: Op 23-11-2012 20:06, Christopher Schultz schreef: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zorro, On 11/22/12 5:07 PM, Zorro wrote: Hi, I tried to use the Apache Tomcat Native Library 1.1.24 using APR version 1.4.6 with my Tomcat 7.0.32 server but after installing it I cannot connect over ipv4. Using Tomcat with the Native Library on Fedora 14 everything starts up fine. However a telnet 127.0.0.1 80 gives a 'Connection refused'. But with a telnet ::1 80 I can connect to Tomcat! Using the http-bio-80 connector I can connect to Tomcat over ipv4 as well over ipv6. Both telnet 127.0.0.1 80 and telnet ::1 80 do connect to Tomcat. Is there a way to use the Apache Tomcat Native Library also for ipv4 connections? Try setting address=127.0.0.1 in your Connector. Or 0.0.0.0 if you want to listen on all IPv4 interfaces. - -chris Hi Chris, Thank you for your response. Indeed setting the address attribute to 0.0.0.0 in the Connector element solves the issue. Tomcat is then indeed listening to all IPv4 interfaces. Though connecting over IPv6 is not possible then. Can't you them set up a second Connector, with an equivalent IPv6 address ? Since it is bound to different addresses, it shouldn't conflict with the first, or would it ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
HttpServletReponse#sendError(int) behavior in ErrorReportValve
Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Thanks, Michael [1] http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletResponse.html#sendError%28int%29 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Am 2012-11-23 22:16, schrieb Mark Thomas: On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Well, I am still on Tomcat 6 but I would do the following: 1. Define a @Controller 2. Define @RequestMapping on a method 3. Map that controller in the web.xml Now here's the problem, that method would return ModelAndView or simply a view's string name. But I would like to use ResponseEntity as it would be necessary for REST. Did you had this in mind? Otherwise would produces with distinct methods work for such an error page? Thank you Mark, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
On 23/11/2012 21:23, Michael-O wrote: Am 2012-11-23 22:16, schrieb Mark Thomas: On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Well, I am still on Tomcat 6 but I would do the following: 1. Define a @Controller 2. Define @RequestMapping on a method 3. Map that controller in the web.xml Now here's the problem, that method would return ModelAndView or simply a view's string name. But I would like to use ResponseEntity as it would be necessary for REST. Did you had this in mind? Otherwise would produces with distinct methods work for such an error page? Sorry, I know next to nothing about Spring (and yes, I do work for SpringSource). For Tomcat 6 I'd define my own error valve but that is not portable. You could also define error pages for each error code you use and for java.lang.Exception My reading of the specification text quoted above is that the server is expected to create HTML error pages unless the user defines a custom error page in web.xml. I don't see any room for an alternative interpretation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the Tomcat Native Library can only connect over ipv6 But not over ipv4
Op 23-11-2012 22:04, André Warnier schreef: Zorro wrote: Op 23-11-2012 20:06, Christopher Schultz schreef: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zorro, On 11/22/12 5:07 PM, Zorro wrote: Hi, I tried to use the Apache Tomcat Native Library 1.1.24 using APR version 1.4.6 with my Tomcat 7.0.32 server but after installing it I cannot connect over ipv4. Using Tomcat with the Native Library on Fedora 14 everything starts up fine. However a telnet 127.0.0.1 80 gives a 'Connection refused'. But with a telnet ::1 80 I can connect to Tomcat! Using the http-bio-80 connector I can connect to Tomcat over ipv4 as well over ipv6. Both telnet 127.0.0.1 80 and telnet ::1 80 do connect to Tomcat. Is there a way to use the Apache Tomcat Native Library also for ipv4 connections? Try setting address=127.0.0.1 in your Connector. Or 0.0.0.0 if you want to listen on all IPv4 interfaces. - -chris Hi Chris, Thank you for your response. Indeed setting the address attribute to 0.0.0.0 in the Connector element solves the issue. Tomcat is then indeed listening to all IPv4 interfaces. Though connecting over IPv6 is not possible then. Can't you them set up a second Connector, with an equivalent IPv6 address ? Since it is bound to different addresses, it shouldn't conflict with the first, or would it ? I have set them up now as: For IPv4: Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 address=0.0.0.0 / For IPv6: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 address=::0 / As I understand it, this way one cannot use port 80 simultaneously for IPv4 and IPv6? Regards, Harm-Jan Zwinderman (its not really a problem but if we ever migrate the internet to IPv6 it would be brilliant to have the connector serving both protocols which the http-bio-80 connector seems to be able to do) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Am 2012-11-23 22:28, schrieb Mark Thomas: On 23/11/2012 21:23, Michael-O wrote: Am 2012-11-23 22:16, schrieb Mark Thomas: On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Well, I am still on Tomcat 6 but I would do the following: 1. Define a @Controller 2. Define @RequestMapping on a method 3. Map that controller in the web.xml Now here's the problem, that method would return ModelAndView or simply a view's string name. But I would like to use ResponseEntity as it would be necessary for REST. Did you had this in mind? Otherwise would produces with distinct methods work for such an error page? Sorry, I know next to nothing about Spring (and yes, I do work for SpringSource). For Tomcat 6 I'd define my own error valve but that is not portable. You could also define error pages for each error code you use and for java.lang.Exception The problem is that our Tomcat is serving a variety of apps. I do not want to code a custom valve to one app which would impact other ones. Neither I do want to subclass StandardHost class and disable the valve and add one on a per-webapp base. My reading of the specification text quoted above is that the server is expected to create HTML error pages unless the user defines a custom error page in web.xml. I don't see any room for an alternative interpretation. Well, that applies for the JavaDoc of sendError(int, String). sendError(int) does not say that the server has to auto-generate a HTML error page unless one is defined by the developer. Am I correct? Thanks, Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
On 23/11/2012 21:44, Michael-O wrote: Am 2012-11-23 22:28, schrieb Mark Thomas: On 23/11/2012 21:23, Michael-O wrote: Am 2012-11-23 22:16, schrieb Mark Thomas: On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Well, I am still on Tomcat 6 but I would do the following: 1. Define a @Controller 2. Define @RequestMapping on a method 3. Map that controller in the web.xml Now here's the problem, that method would return ModelAndView or simply a view's string name. But I would like to use ResponseEntity as it would be necessary for REST. Did you had this in mind? Otherwise would produces with distinct methods work for such an error page? Sorry, I know next to nothing about Spring (and yes, I do work for SpringSource). For Tomcat 6 I'd define my own error valve but that is not portable. You could also define error pages for each error code you use and for java.lang.Exception The problem is that our Tomcat is serving a variety of apps. I do not want to code a custom valve to one app which would impact other ones. Neither I do want to subclass StandardHost class and disable the valve and add one on a per-webapp base. My reading of the specification text quoted above is that the server is expected to create HTML error pages unless the user defines a custom error page in web.xml. I don't see any room for an alternative interpretation. Well, that applies for the JavaDoc of sendError(int, String). sendError(int) does not say that the server has to auto-generate a HTML error page unless one is defined by the developer. Am I correct? No. sendError(int) == sendError(int, null) sendError(int, null) requires an HTML response, even if the message is null. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Am 2012-11-23 22:50, schrieb Mark Thomas: On 23/11/2012 21:44, Michael-O wrote: Am 2012-11-23 22:28, schrieb Mark Thomas: On 23/11/2012 21:23, Michael-O wrote: Am 2012-11-23 22:16, schrieb Mark Thomas: On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Well, I am still on Tomcat 6 but I would do the following: 1. Define a @Controller 2. Define @RequestMapping on a method 3. Map that controller in the web.xml Now here's the problem, that method would return ModelAndView or simply a view's string name. But I would like to use ResponseEntity as it would be necessary for REST. Did you had this in mind? Otherwise would produces with distinct methods work for such an error page? Sorry, I know next to nothing about Spring (and yes, I do work for SpringSource). For Tomcat 6 I'd define my own error valve but that is not portable. You could also define error pages for each error code you use and for java.lang.Exception The problem is that our Tomcat is serving a variety of apps. I do not want to code a custom valve to one app which would impact other ones. Neither I do want to subclass StandardHost class and disable the valve and add one on a per-webapp base. My reading of the specification text quoted above is that the server is expected to create HTML error pages unless the user defines a custom error page in web.xml. I don't see any room for an alternative interpretation. Well, that applies for the JavaDoc of sendError(int, String). sendError(int) does not say that the server has to auto-generate a HTML error page unless one is defined by the developer. Am I correct? No. sendError(int) == sendError(int, null) sendError(int, null) requires an HTML response, even if the message is null. I am aware of that implementation detail. I was solely referring to the definition in the JavaDocs. They seem to be misleading. At least to me. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Using the Tomcat Native Library can only connect over ipv6 But not over ipv4
Zorro wrote: Op 23-11-2012 22:04, André Warnier schreef: Zorro wrote: Op 23-11-2012 20:06, Christopher Schultz schreef: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zorro, On 11/22/12 5:07 PM, Zorro wrote: Hi, I tried to use the Apache Tomcat Native Library 1.1.24 using APR version 1.4.6 with my Tomcat 7.0.32 server but after installing it I cannot connect over ipv4. Using Tomcat with the Native Library on Fedora 14 everything starts up fine. However a telnet 127.0.0.1 80 gives a 'Connection refused'. But with a telnet ::1 80 I can connect to Tomcat! Using the http-bio-80 connector I can connect to Tomcat over ipv4 as well over ipv6. Both telnet 127.0.0.1 80 and telnet ::1 80 do connect to Tomcat. Is there a way to use the Apache Tomcat Native Library also for ipv4 connections? Try setting address=127.0.0.1 in your Connector. Or 0.0.0.0 if you want to listen on all IPv4 interfaces. - -chris Hi Chris, Thank you for your response. Indeed setting the address attribute to 0.0.0.0 in the Connector element solves the issue. Tomcat is then indeed listening to all IPv4 interfaces. Though connecting over IPv6 is not possible then. Can't you them set up a second Connector, with an equivalent IPv6 address ? Since it is bound to different addresses, it shouldn't conflict with the first, or would it ? I have set them up now as: For IPv4: Connector port=80 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 address=0.0.0.0 / For IPv6: Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 address=::0 / As I understand it, this way one cannot use port 80 simultaneously for IPv4 and IPv6? Well, honestly I wonder. But on the face of it, I don't immediately see why not. Have you tried it ? (I mean, set both Connectors above for port 80) .. (its not really a problem but if we ever migrate the internet to IPv6 it would be brilliant to have the connector serving both protocols which the http-bio-80 connector seems to be able to do) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
On 23/11/2012 22:00, Michael-O wrote: Am 2012-11-23 22:50, schrieb Mark Thomas: On 23/11/2012 21:44, Michael-O wrote: Am 2012-11-23 22:28, schrieb Mark Thomas: On 23/11/2012 21:23, Michael-O wrote: Am 2012-11-23 22:16, schrieb Mark Thomas: On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Well, I am still on Tomcat 6 but I would do the following: 1. Define a @Controller 2. Define @RequestMapping on a method 3. Map that controller in the web.xml Now here's the problem, that method would return ModelAndView or simply a view's string name. But I would like to use ResponseEntity as it would be necessary for REST. Did you had this in mind? Otherwise would produces with distinct methods work for such an error page? Sorry, I know next to nothing about Spring (and yes, I do work for SpringSource). For Tomcat 6 I'd define my own error valve but that is not portable. You could also define error pages for each error code you use and for java.lang.Exception The problem is that our Tomcat is serving a variety of apps. I do not want to code a custom valve to one app which would impact other ones. Neither I do want to subclass StandardHost class and disable the valve and add one on a per-webapp base. My reading of the specification text quoted above is that the server is expected to create HTML error pages unless the user defines a custom error page in web.xml. I don't see any room for an alternative interpretation. Well, that applies for the JavaDoc of sendError(int, String). sendError(int) does not say that the server has to auto-generate a HTML error page unless one is defined by the developer. Am I correct? No. sendError(int) == sendError(int, null) sendError(int, null) requires an HTML response, even if the message is null. I am aware of that implementation detail. I was solely referring to the definition in the JavaDocs. They seem to be misleading. At least to me. I was referring only to the Javadoc you quoted. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Am 2012-11-23 23:02, schrieb Mark Thomas: On 23/11/2012 22:00, Michael-O wrote: Am 2012-11-23 22:50, schrieb Mark Thomas: On 23/11/2012 21:44, Michael-O wrote: Am 2012-11-23 22:28, schrieb Mark Thomas: On 23/11/2012 21:23, Michael-O wrote: Am 2012-11-23 22:16, schrieb Mark Thomas: On 23/11/2012 21:09, Michael-O wrote: Hi, I've been struggling recently with this builtin valve and some Spring-based REST services. I some cases I do return states like 404 or 400. SendError seems to be the right thing to do but Tomcat alters the response with the HTML page. Which is highly unwanted for a REST API. I have checked Oracle's original JavaDocs for #sendError(int) + Servlet Spec 2.5 and 3.0 all three of them, do not explicitly mention that an error HTML response is returned with this method. The JavaDoc [1] says: ...If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back the error page... I did not define a custom error page. Where as the #sendError(int,String) says: ... The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to text/html. This one is crystal clear. sendError(int) simply calls sendError(int,String) with a null string arg. Am I misunderstanding the the definition? Should I avoid sendError alltogher and resort to setStatus? What would be the implications? I do know that sendError commits and closes the response immediately. A clarification is highly appreciated. Use Tomcat 7 and define a custom, default error page. You'll then remain in complete control of the error response. Well, I am still on Tomcat 6 but I would do the following: 1. Define a @Controller 2. Define @RequestMapping on a method 3. Map that controller in the web.xml Now here's the problem, that method would return ModelAndView or simply a view's string name. But I would like to use ResponseEntity as it would be necessary for REST. Did you had this in mind? Otherwise would produces with distinct methods work for such an error page? Sorry, I know next to nothing about Spring (and yes, I do work for SpringSource). For Tomcat 6 I'd define my own error valve but that is not portable. You could also define error pages for each error code you use and for java.lang.Exception The problem is that our Tomcat is serving a variety of apps. I do not want to code a custom valve to one app which would impact other ones. Neither I do want to subclass StandardHost class and disable the valve and add one on a per-webapp base. My reading of the specification text quoted above is that the server is expected to create HTML error pages unless the user defines a custom error page in web.xml. I don't see any room for an alternative interpretation. Well, that applies for the JavaDoc of sendError(int, String). sendError(int) does not say that the server has to auto-generate a HTML error page unless one is defined by the developer. Am I correct? No. sendError(int) == sendError(int, null) sendError(int, null) requires an HTML response, even if the message is null. I am aware of that implementation detail. I was solely referring to the definition in the JavaDocs. They seem to be misleading. At least to me. I was referring only to the Javadoc you quoted. Yes, for the second one. Why do the Tomcat Servlet JavaDocs for sendError(int) not mention that [1]? SendError(int, String) is fine though. Care to update the docs to make this crystal clear? Thanks, Mike [1] http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/HttpServletResponse.html#sendError(int) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
On 23/11/2012 22:07, Michael-O wrote: Am 2012-11-23 23:02, schrieb Mark Thomas: On 23/11/2012 22:00, Michael-O wrote: snip/ I am aware of that implementation detail. I was solely referring to the definition in the JavaDocs. They seem to be misleading. At least to me. I was referring only to the Javadoc you quoted. Yes, for the second one. Why do the Tomcat Servlet JavaDocs for sendError(int) not mention that [1]? SendError(int, String) is fine though. Care to update the docs to make this crystal clear? You started off quoting the Oracle Javadocs and that is what I responded to. You are now moving the goal posts. If you think there is room for improvement in the Tomcat Javadocs then open an enhancement request and provide a patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HttpServletReponse#sendError(int) behavior in ErrorReportValve
Am 2012-11-23 23:10, schrieb Mark Thomas: On 23/11/2012 22:07, Michael-O wrote: Am 2012-11-23 23:02, schrieb Mark Thomas: On 23/11/2012 22:00, Michael-O wrote: snip/ I am aware of that implementation detail. I was solely referring to the definition in the JavaDocs. They seem to be misleading. At least to me. I was referring only to the Javadoc you quoted. Yes, for the second one. Why do the Tomcat Servlet JavaDocs for sendError(int) not mention that [1]? SendError(int, String) is fine though. Care to update the docs to make this crystal clear? You started off quoting the Oracle Javadocs and that is what I responded to. You are now moving the goal posts. If you think there is room for improvement in the Tomcat Javadocs then open an enhancement request and provide a patch. https://issues.apache.org/bugzilla/show_bug.cgi?id=54198 Done, thanks! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
