You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 20, 2021. It is now read-only.
I'm filing this issue to track the earlier discussion around exception handling
around read or any other similar filters in Grizzly. Here is detail description
of the problem, in the email archive :
The scenario is, when an exception happens (say, a connection error, or a parser
error while parsing..) the developer of Grizzly would like to take some
definitive action in the application. This requirement applies to both server
and client side.
Its a good idea to have a callback mechanism (or event handling /listeners) to
register for a specific exceptions and then pass them to the registered objects
for action upon their occurrence.
Environment
Operating System: All
Platform: Sun
Affected Versions
[1.9.22]
The text was updated successfully, but these errors were encountered:
I'm filing this issue to track the earlier discussion around exception handling
around read or any other similar filters in Grizzly. Here is detail description
of the problem, in the email archive :
https://grizzly.dev.java.net/servlets/ReadMsg?list=dev&msgNo=680
The scenario is, when an exception happens (say, a connection error, or a parser
error while parsing..) the developer of Grizzly would like to take some
definitive action in the application. This requirement applies to both server
and client side.
Its a good idea to have a callback mechanism (or event handling /listeners) to
register for a specific exceptions and then pass them to the registered objects
for action upon their occurrence.
Environment
Operating System: All
Platform: Sun
Affected Versions
[1.9.22]
The text was updated successfully, but these errors were encountered: