Daniel Doubleday wrote:
I don't think that a event.close() call should throw a NPE when the event
is
already closed. But I would rather catch an exception when I am writing
to
response object that has been closed.
that is possible to do, do you have the stack trace of the NPE?
Here is the stack trace:
Exception in thread "Thread-17" java.lang.NullPointerException
at
org.apache.catalina.connector.CometEventImpl.close(CometEventImpl.java:84)
at
com.mrtattle.tcniotest.CometServlet$Transport.close(CometServlet.java:42)
at com.mrtattle.tcniotest.CometServlet$1.run(CometServlet.java:117)
at java.lang.Thread.run(Thread.java:613)
yes, calling "close" on the begin event, and then expecting the
CometEvent object to still function is a misuse of the API
Maybe I am getting something wrong, but I think that the api should
rather
reflect a request model, where the end event is triggered when the
response
is closed. Now it seems that it more reflects the connection model. I am
sure that one can live with it as it is though.
not sure I understand this and what you are trying to get at.
I think that the comet api represents a socket connection. The event life
cycle is bound to the connection life cycle. You get an END (or ERROR etc)
when the connection gets closed. But when you are writing something that
still looks like a servlet you would expect that the event life cycle is
bound to the request / response model. As soon as the response is closed you
would expect an END event.
That's pretty much how it is
Filip
Filip Hanik - Dev Lists wrote:
Daniel Doubleday wrote:
Hi this post is a follow up from
http://issues.apache.org/bugzilla/show_bug.cgi?id=42198 where this post
does
not belong.
...
not sure I understand this and what you are trying to get at.
Filip
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
