custom HttpSession server.xml

2006-08-12 Thread jeusdi

Hello, 
   I'm interested in customize the default HttpSession, but I don't know how
can I custom it? I should like when form my servlet I execute
req.getSession(), it returns me my customized HttpSession:
 
 HttpSession session = req.getSession(true);
 CustomHttpSession mySession =
(CustomHttpSession)session;

I want it because I need classes associated to session and I've thunk extend
a httpSession and add properties to use later. Is it possible modifying the
server.xml?

If it isn't possible to do it, Is possible create simple java classes that
behaviors with HttpSession.
-- 
View this message in context: 
http://www.nabble.com/custom-HttpSession-server.xml-tf2094591.html#a5773979
Sent from the Tomcat - Dev forum at Nabble.com.


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



Catching java.lang.Throwable

2006-08-12 Thread J Ross Nicoll
Found this recently: 
http://www.jroller.com/page/fate/?anchor=why_i_hate_tomcat


Most of it is ranting about parts of Tomcat I don't have any experience 
with working on, but it does mention Throwable being caught all over the 
place:


"The first issue is the fact that everywhere, Throwable is caught. Yes, 
even Error type exceptions are caught. Things that god and Sun never 
intended for applications to even try to handle, tomcat will (silently) 
catch and ignore. After all, when you run out of memory, best thing to 
do is keep going right?"


I'm currently working on some patches to reduce the number of places 
that catch Throwable, but felt a little bit of an explanation of what 
why catching Throwable is bad, might be in order. Trying not to make 
this sound too much like a lecture, and hope I don't irk people too much...


Looking at
"connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java", 
line 812:


try {
socket.setSoTimeout(soTimeout);
} catch (Throwable t) {
log.debug(sm.getString("http11processor.socket.timeout"), t);
error = true;
}

java.net.Socket.setSoTimeout(int) only lists java.net.SocketException as 
an exception it throws, so why are we catching everything? In 
particular, imagine the VM runs out of memory, the GC can't free any 
more up, and java.lang.OutOfMemoryError is thrown. This will happily 
ignore that error, only logging it if debugging level is enabled, and 
continue. While, sure, the alternative may be that Tomcat exits 
abruptly, but really is that any better to Tomcat grinding to an 
unpleasant halt? It's at least easy to tell a server has crashed, but 
unable to do anything because it's run out of memory is much trickier.


Further down the same file, line 838:

// Parsing the request header
try {
if( !disableUploadTimeout && keptAlive && soTimeout > 0 ) {
socket.setSoTimeout(soTimeout);
}
inputBuffer.parseRequestLine();
request.setStartTime(System.currentTimeMillis());
thrA.setParam( threadPool, request.requestURI() );
keptAlive = true;
if (!disableUploadTimeout) {
socket.setSoTimeout(timeout);
}
inputBuffer.parseHeaders();
} catch (IOException e) {
error = true;
break;
} catch (Throwable t) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("http11processor.header.parse"), t);
}
// 400 - Bad Request
response.setStatus(400);
error = true;
}

I'm fairly certain it should be returning 500, not 400, but that's not 
the point. Here, catching Throwable is correct; you do not want an error 
to leave the connection in an indeterminate state. However, once the 
error status has been sent, it should be thrown upwards again.


It might make sense to catch specific Error subclasses higher up, if 
they can be dealt with (for example, catch OutOfMemoryError, clear out 
caches, and then call the GC to try fixing the situation), but catching 
Throwable throughout the code is dangerous. Particularly, some of the 
errors, for example ThreadDeath, need to propagate upwards to ensure 
correct operation of the VM!


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



Re: custom HttpSession server.xml

2006-08-12 Thread Ian Darwin



   I'm interested in customize the default HttpSession, but I don't know how
can I custom it? I should like when form my servlet I execute
req.getSession(), it returns me my customized HttpSession:
 
 HttpSession session = req.getSession(true);

 CustomHttpSession mySession =
(CustomHttpSession)session;

I want it because I need classes associated to session and I've thunk extend
a httpSession and add properties to use later. Is it possible modifying the
server.xml?


This is not a question that belongs on the dev list, and I'm not even 
sure it belongs on the users list. You seem to be unaware that the 
HttpSession is designed to work as a container, so you don't need to 
subclass it to add properties (e.g., as you put it to associate objects 
with the user's session). It has methods that work like a Map (or a 
Hashtable), allowing you to set any properties on it that you like. 
Please refer to the documentation for HttpSession, or read any of the 
good books out there about Servlet development.


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



DO NOT REPLY [Bug 40240] New: - Incorrect status code returned in case of error (400 instead of 500)

2006-08-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40240

   Summary: Incorrect status code returned in case of error (400
instead of 500)
   Product: Tomcat 5
   Version: 5.5.17
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: P2
 Component: Connector:Coyote
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


In some cases where non-IOException exceptions and errors are thrown while
parsing an HTTP request, status code 400 (bad request) is turned instead of 500
(internal server error).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 40240] - Incorrect status code returned in case of error (400 instead of 500)

2006-08-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40240





--- Additional Comments From [EMAIL PROTECTED]  2006-08-12 15:17 ---
Created an attachment (id=18705)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18705&action=view)
Proposed patch for this bug


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 40241] New: - java.lang.Throwable is caught inappropriately

2006-08-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40241

   Summary: java.lang.Throwable is caught inappropriately
   Product: Tomcat 5
   Version: 5.5.17
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


In multiple places throughout the Tomcat source code, java.lang.Throwable is
caught, and dealt with as if it was an Exception subclass, meaning that
java.lang.Error subclasses may be ignored or dealt with inappropriately. I'm
making this as a bug to hold patches I've been working on, for this problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 40241] - java.lang.Throwable is caught inappropriately

2006-08-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40241





--- Additional Comments From [EMAIL PROTECTED]  2006-08-12 19:29 ---
Created an attachment (id=18706)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18706&action=view)
Patch for SSI filter and servlet


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 40241] - java.lang.Throwable is caught inappropriately

2006-08-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40241





--- Additional Comments From [EMAIL PROTECTED]  2006-08-12 19:30 ---
Created an attachment (id=18707)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18707&action=view)
Patch for DefaultServlet

Please note the two methods getBooleanInitParameter() and getIntInitParameter()
- if someone with a better understanding of the Tomcat code layout could move
these into a utility class or similar, it would probably be better.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



Re: Catching java.lang.Throwable

2006-08-12 Thread Remy Maucherat

J Ross Nicoll wrote:
I'm currently working on some patches to reduce the number of places 
that catch Throwable, but felt a little bit of an explanation of what 
why catching Throwable is bad, might be in order. Trying not to make 
this sound too much like a lecture, and hope I don't irk people too much...


Sorry, but we don't care about fixing this "issue", especially in the 
portions you mention. Thanks for your help anyway.


Rémy

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



DO NOT REPLY [Bug 40240] - Incorrect status code returned in case of error (400 instead of 500)

2006-08-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40240


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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



DO NOT REPLY [Bug 40241] - java.lang.Throwable is caught inappropriately

2006-08-12 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40241





--- Additional Comments From [EMAIL PROTECTED]  2006-08-12 19:44 ---
I am sure you mean well, but this is a bad idea, sorry. The only acceptable
change is for the parsing of the parameters, but it would need to be more
conservative than this.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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