14 Replies Latest reply on Apr 12, 2006 8:18 PM by starksm64

    J2EE-compliant way to retrieve ServletRequest and ServletRes

    claprun

      I found a reference to using the MessageContext to retrieve this information:

      MessageContext messageContext = this.ctx.getMessageContext();
      HttpServletRequest request = (HttpServletRequest) messageContext.getProperty("transport.http.servletRequest");
      


      but I looked at my message context at runtime and it wasn't holding any property. The ServletEndpointContextImpl (the JBWS object implementing ServletEndpointContext) does contain references to the HttpServletRequest and HttpServletResponse.

      What is the J2EE-compliant way to retrieve this information?

      Thanks in advance.

        • 1. Re: J2EE-compliant way to retrieve ServletRequest and Servle
          thomas.diesler
          • 2. Re: J2EE-compliant way to retrieve ServletRequest and Servle
            thomas.diesler

            There is no J2EE-1.4 compliant way to get at the HttpServletRequest / HttpServletResponse.

            What is the use case?

            • 3. Re: J2EE-compliant way to retrieve ServletRequest and Servle
              claprun

              For WSRP, we need to have access to the servlet request and response information in order to perform the correct dispatch of the invocation on the portal.
              I currently use a ServletFilter to accomplish the goal... Just wanted to know if there was a standard way to get to that information.

              • 4. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                starksm64

                Explain the context as a webservice target may not even have an associated servlet/servlet request (a request delivered via jms). Why isn't this a portal container issue rather than a webservice issue?

                • 5. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                  anil.saldhana

                  I think this issue needs to be discussed further in the wsrp forums [WS is transport agnostic - dont know about wsrp]

                  The old ws4ee stack had the servlet request embedded in the MessageContext as a property. This was just a convenience value add. But no standard exists. The new jbossws does not (rightfully).

                  • 6. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                    claprun

                    WS is indeed transport-agnostic. However, WSRP is not necessarily. Some methods on the required interfaces (initCookie for example on the Markup interface), explicitely need to set HTTP headers (when using the HTTP transport, that is).

                    This is indeed a Portal issue but since there used to be a means to retrieve the servlet request/response information and this doesn't exist anymore, I was wondering if something had replaced it that I had missed.

                    • 7. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                      jimhenderson

                      Not sure if i should add this here - but it sounds very similar to the originally reported problem...

                      With jboss-4.0.3SP1 & jboss-4.0.4RC1 i have used this to get the url used to call my servlet style web service endpoint...

                      String transportUrl = (String)messageContext.getProperty("transport.url");


                      However i have just tried the same thing with jboss-4.0.4.CR2 and that property does not seem to exist.

                      Is there a new way i can find out the "transport.url" with jboss-4.0.4.CR2 or will the old way be added back in for the next release?



                      • 8. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                        starksm64

                         

                        "chris.laprun@jboss.com" wrote:
                        WS is indeed transport-agnostic. However, WSRP is not necessarily. Some methods on the required interfaces (initCookie for example on the Markup interface), explicitely need to set HTTP headers (when using the HTTP transport, that is).

                        This is indeed a Portal issue but since there used to be a means to retrieve the servlet request/response information and this doesn't exist anymore, I was wondering if something had replaced it that I had missed.

                        Especially since the context is regarding routing of requests, why isn't the integration context of the wsrp component providing this info? This is for the case of a portlet using wsrp to incorporate content from a webservice or what?

                        There is a jacc api for getting the servlet request, but its intended to be used as part of an authorization call and I don't know whether there are portlet thread pooling issues that could invalidate its use.


                        • 9. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                          claprun

                           

                          "scott.stark@jboss.org" wrote:
                          Especially since the context is regarding routing of requests, why isn't the integration context of the wsrp component providing this info? This is for the case of a portlet using wsrp to incorporate content from a webservice or what?


                          My question was meant to provide the WSRP component with the required context in a "standard" way. Retrieving that information is necessary for us to build the proper WSRP request context so that the rest of the routing is done correctly. Does that answer your question or am I missing your point?

                          Again, on second thought, since WS is transport agnostic, it does indeed make little sense to have a "standard" way to retrieve the servlet information, even though there's a ServletEndpointContext class in JAX-RPC. I thought that maybe there was a way to get to the ServletEndpointContext that I had missed.

                          "scott.stark@jboss.org" wrote:
                          There is a jacc api for getting the servlet request, but its intended to be used as part of an authorization call and I don't know whether there are portlet thread pooling issues that could invalidate its use.


                          As stated in one of my previous message, I am using a ServletFilter to retrieve the information. It is kind of hackish though and would like a cleaner solution if possible (though I'd undestand if there was none).

                          • 10. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                            starksm64

                             

                            "chris.laprun@jboss.com" wrote:
                            My question was meant to provide the WSRP component with the required context in a "standard" way. Retrieving that information is necessary for us to build the proper WSRP request context so that the rest of the routing is done correctly. Does that answer your question or am I missing your point?

                            Again, on second thought, since WS is transport agnostic, it does indeed make little sense to have a "standard" way to retrieve the servlet information, even though there's a ServletEndpointContext class in JAX-RPC. I thought that maybe there was a way to get to the ServletEndpointContext that I had missed.


                            Access to the ServletEndpointContext is available via the init method of the javax.xml.rpc.server.ServiceLifecycle interface. See the org.jboss.test.ws.samples.jsr109pojo.JaxRpcJSEEndpoint testcase.

                            I'm still missing exactly what piece you are building. The extension to the portal container that supports integration of wsrp available content? If that's the case, what is the integration point with the portlet request that triggers the delegation to the wsrp layer? I would expect that all portlet context was being provided by the callout context.


                            • 11. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                              anil.saldhana

                              The jacc way of obtaining the servlet request may work as Portal Security reuses the JBossSX Jacc layer. Chris, you need to check that out.

                              • 12. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                                claprun

                                 

                                "scott.stark@jboss.org" wrote:

                                Access to the ServletEndpointContext is available via the init method of the javax.xml.rpc.server.ServiceLifecycle interface. See the org.jboss.test.ws.samples.jsr109pojo.JaxRpcJSEEndpoint testcase.


                                It is indeed how I tried to access the information. The following code is found in the init method of my end points:
                                context = (ServletEndpointContext)object; // per init javadoc
                                
                                /*
                                // put the request and response in ServletAccess... not working, using a filter for now
                                MessageContext messageContext = context.getMessageContext();
                                HttpServletRequest request = (HttpServletRequest)messageContext.getProperty("transport.http.servletRequest");
                                HttpServletResponse response = (HttpServletResponse)messageContext.getProperty("transport.http.servletResponse");
                                ServletAccess.setRequestAndResponse(request, response);
                                */
                                

                                But this code is not working since the MessageContext does not contain the properties that used to be there anymore.

                                "scott.stark@jboss.org" wrote:

                                I'm still missing exactly what piece you are building. The extension to the portal container that supports integration of wsrp available content? If that's the case, what is the integration point with the portlet request that triggers the delegation to the wsrp layer? I would expect that all portlet context was being provided by the callout context.


                                We're currently building the WSRP producer, i.e. the part of portal which will publish the deployed portlets to WSRP consumers. A WSRP consumer will issue a WSRP request (via WS) and the producer will translate that WS request into a portal invocation. It's the translation part that requires information from the servlet context since the portal depends on it for its routing and we want to have a single architecture whether the invocation on a portlet is local to the portal or via WSRP. The portlet request hence happens AFTER the WSRP machinery has taken effect. In essence, the WSRP container is just another modality to access Portal content and builds the portal invocation based on the WS request received.

                                This thread should probably move to the WSRP dev forum... :)

                                • 13. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                                  claprun

                                   

                                  "anil.saldhana@jboss.com" wrote:
                                  The jacc way of obtaining the servlet request may work as Portal Security reuses the JBossSX Jacc layer. Chris, you need to check that out.


                                  The ServletFilter solution is probably good enough for now. If proven otherwise, I will check out the JACC solution. :)

                                  • 14. Re: J2EE-compliant way to retrieve ServletRequest and Servle
                                    starksm64

                                     

                                    "chris.laprun@jboss.com" wrote:

                                    It is indeed how I tried to access the information. The following code is found in the init method of my end points:
                                    context = (ServletEndpointContext)object; // per init javadoc
                                    
                                    /*
                                    // put the request and response in ServletAccess... not working, using a filter for now
                                    MessageContext messageContext = context.getMessageContext();
                                    HttpServletRequest request = (HttpServletRequest)messageContext.getProperty("transport.http.servletRequest");
                                    HttpServletResponse response = (HttpServletResponse)messageContext.getProperty("transport.http.servletResponse");
                                    ServletAccess.setRequestAndResponse(request, response);
                                    */
                                    

                                    But this code is not working since the MessageContext does not contain the properties that used to be there anymore.


                                    I don't know why we can't restore that option when the request is in fact coming in via an http request. It is not portable though so until the jaxws 2.0 (http://jcp.org/aboutJava/communityprocess/pfd/jsr224/index.html) which does define several servlet related MessageContext values:

                                    javax.xml.ws.servlet.context = javax.servlet.ServletContext
                                    javax.xml.ws.servlet.request = javax.servlet.http.HttpServletRequest
                                    javax.xml.ws.servlet.response = javax.servlet.http.HttpServletResponse
                                    javax.xml.ws.servlet.session = javax.servlet.http.HttpSession

                                    its not standard.