DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38943>. 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=38943 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #17877|0 |1 is obsolete| | ------- Additional Comments From [EMAIL PROTECTED] 2006-03-23 14:50 ------- Created an attachment (id=17951) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17951&action=view) patch, take 2 This addresses most of the concerns that were raised: - new JavaDoc and parameter name for HttpNotificationHandler.notifyResponse - only one boolean in public SimpleHttpHandle.provideProblem (there now is a private internalProvideProblem) - renamed NotifedAsyncGet to RoutingAsyncGet - new NotifiedAsyncGet with only one service thread (and without checks that should go into test cases) I've left the notification_handler attribute in AbstractHttpHandle as final, mainly because I don't know how to prioritize an automated call to setNotificationHandler by the Spring framework against a notification handler set by the application in the request specific HttpContext, or the default context. Let's revisit this when we have code that would actually use the Spring framework to instantiate the notification handler. The patch has the usual problems with the @version lines in 4 classes. cheers, Roland -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
