-
2. Re: J2EE-compliant way to retrieve ServletRequest and Servle
thomas.diesler Apr 11, 2006 11:06 AM (in response to claprun)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 Apr 11, 2006 1:36 PM (in response to 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 Apr 11, 2006 1:43 PM (in response to claprun)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 Apr 11, 2006 2:01 PM (in response to claprun)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 Apr 11, 2006 2:15 PM (in response to 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 Apr 11, 2006 3:30 PM (in response to claprun)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 Apr 11, 2006 11:11 PM (in response to claprun)"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 Apr 11, 2006 11:52 PM (in response to 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 Apr 12, 2006 12:11 AM (in response to claprun)"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 Apr 12, 2006 12:38 AM (in response to claprun)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 Apr 12, 2006 1:23 AM (in response to 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 Apr 12, 2006 1:25 AM (in response to 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 Apr 12, 2006 8:18 PM (in response to claprun)"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.