4.2.23 to 5.1.3 upgrade questions / problems

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

4.2.23 to 5.1.3 upgrade questions / problems

Steve Wardell
I was attempting to upgrade the Jetty version used in
my application from 4.2.23 to 5.1.3 and had some
questions and problems:

1) I have a class that implements
org.mortbay.http.HttpListener and I noticed that in
v1.13 (in 5.0 beta 0) of that file, that a new method
was added to that interface with the comment "handle
browsers that do not grok persistent SSL (msie5)". I'm
not sure what I should have my implementation do
within this method. Can someone clarify?

2) In another class that extends
org.mortbay.http.HttpContext, I see that in version
1.105 (same comment, "handle browsers that do not grok
persistent SSL (msie5)") that the signature of handle
was changed from returning boolean to now returning
void. What is the reasoning on this / what effect does
it have in terms of why the change was made? It's easy
to change my calls to it to assume the void return,
but wondering if there were any effects that I might
not be aware of as a result.

3) Lastly, when I request a JSP page, I get a
NullPointerException. This seems due to a change made
in org.mortbay.jetty.servlet.Dispatcher in v1.60
(comment "context scope enter and exit methods") in
which dispatch method was changed from:

ServletHttpRequest servletHttpRequest=
(httpConnection!=null)
           
?(ServletHttpRequest)httpConnection.getRequest().getWrapper()
                     
           
:ServletHttpRequest.unwrap(servletRequest);
to:
ServletHttpRequest
servletHttpRequest=(ServletHttpRequest)httpConnection.getRequest().getWrapper();

It was checking for null httpConnection (which is what
I'm having) and getting the servlet request another
way. What do I need to do such that the httpConnection
would not be null so the new code that doesn't handle
nulls would work.

WARNING: /admin/banner.jsp:
java.lang.NullPointerException
        at
org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:191)
        at
org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:161)
        at
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:822)
        at
org.apache.jsp.banner_jsp._jspService(banner_jsp.java:58)
        at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
        at
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204)
        at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
        at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
        at
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427)
        at
org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:654)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:556)
        at
org.mortbay.http.HttpContext.handle(HttpContext.java:1563)
        at
com.myapp.server.BanterHttpServer$2.handle(BanterHttpServer.java:243)
        at
org.mortbay.http.HttpContext.handle(HttpContext.java:1515)
        at
org.mortbay.http.HttpServer.service(HttpServer.java:956)
        at
org.mortbay.http.HttpConnection.service(HttpConnection.java:814)
        at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:981)
        at
com.myapp.server.BanterHttpServer.handleSocket(BanterHttpServer.java:137)
        at
com.myapp.server.ConnectionManager.route(ConnectionManager.java:716)
        at
com.myapp.server.io.AbstractConnectionManager.serviceRequest(AbstractConnectionManager.java:366)
        at
com.myapp.server.io.ClientChannel.serviceRequest(ClientChannel.java:662)
        at
com.myapp.RequestQueueWorker.run(RequestQueueWorker.java:60
                  )
        at java.lang.Thread.run(Thread.java:595)

Thanks in advance,
Steve


               
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: 4.2.23 to 5.1.3 upgrade questions / problems

Greg Wilkins-5
Steve,

explanations below:

Steve Wardell wrote:

> I was attempting to upgrade the Jetty version used in
> my application from 4.2.23 to 5.1.3 and had some
> questions and problems:
>
> 1) I have a class that implements
> org.mortbay.http.HttpListener and I noticed that in
> v1.13 (in 5.0 beta 0) of that file, that a new method
> was added to that interface with the comment "handle
> browsers that do not grok persistent SSL (msie5)". I'm
> not sure what I should have my implementation do
> within this method. Can someone clarify?

This method allows a listener specific handler to be configured.
So a listener can have a HttpHandler which is called before the normal
server based handling is called.   This was added so that the
MSIE SSL specific handler could be added just to the SSL listeners.

If you do not use this handler, then it is safe just to return null,
but I would implement a basic getter/setter for future flexibility.



> 2) In another class that extends
> org.mortbay.http.HttpContext, I see that in version
> 1.105 (same comment, "handle browsers that do not grok
> persistent SSL (msie5)") that the signature of handle
> was changed from returning boolean to now returning
> void. What is the reasoning on this / what effect does
> it have in terms of why the change was made? It's easy
> to change my calls to it to assume the void return,
> but wondering if there were any effects that I might
> not be aware of as a result.

This return was being ignored and the request.isHandled() method
is used to check of a handler actually has handled the request.




> 3) Lastly, when I request a JSP page, I get a
> NullPointerException. This seems due to a change made
> in org.mortbay.jetty.servlet.Dispatcher in v1.60
> (comment "context scope enter and exit methods") in
> which dispatch method was changed from:
>
> ServletHttpRequest servletHttpRequest=
> (httpConnection!=null)
>            
> ?(ServletHttpRequest)httpConnection.getRequest().getWrapper()
>            
>            
> :ServletHttpRequest.unwrap(servletRequest);
> to:
> ServletHttpRequest
> servletHttpRequest=(ServletHttpRequest)httpConnection.getRequest().getWrapper();
>
> It was checking for null httpConnection (which is what
> I'm having) and getting the servlet request another
> way. What do I need to do such that the httpConnection
> would not be null so the new code that doesn't handle
> nulls would work.


There are HttpConnection methods associateThread and disassociateThread.
These are normally called by the HttpConnection.handle method.
If you don't call this method directly (eg the nio listener does not),
then your listener must call these methods to bind a connection to the
thread that is handling it.

cheers







-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support