cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Campbell <ccampb...@quaris.com>
Subject Re: HttpSession and Endpoints
Date Sun, 03 Feb 2008 07:16:58 GMT
If I understand the code correctly, the HttpConduit holds the
session in a private field with no accessor method, and manages the
session itself. So I think I have to use an interceptor to set the
cookie on the other proxies.

My current work around (I think similar to what you suggested) is to
turn off the maintainSession on the conduit and have my own
SessionManager that an inbound interceptor can access and set when
the Set-Cookie comes back from the first request, and an outbound
interceptor can access and set the cookie header for any other
request, whichever proxy is making the request.

So the SessionManager is stateful, but not the interceptors. But the
interceptors do call into my application code, is that a bad practice?

Willem Jiang wrote:
> It is not easy to share the http conduit between the different proxy,
> since you need to hack the HttpTransportFactory and handle
> theconfiguration of the http conduit.
> 
> I don't think using the interceptor could resolve the problem that you
> met. Because when you using the
> interceptor to hold the first session cookie, you will make the
> interceptor stateful. We do not want the interceptor
> be stateful to avoid lock the multi thread calling.
> 
> My suggestion is
> We could put the cookie into the message context for application code to
> access and reset.
> Then you can get the cookie from the first proxy in your application
> code and then set cookie to the
> second proxy to get around it.
> 
> Thoughts?
> 
> Willem.
> 
> 
> Chris Campbell wrote:
>> That would have to be on the client side, correct? I think I would
>> need to have a client side inInterceptor to do that.
>>
>> I tend to load the proxies as needed, is there a way to probe the
>> bus to get any other loaded proxies so that a lazily instantiated
>> proxy can get a previously acquired session cookie from another?
>> Maybe the inInterceptor can just stash away the first session cookie
>> acquired, and an outInterceptor can apply it to any request. Any
>> thoughts as to what the best practice would be?
>>
>> I guess a feature request would be to be able to share an
>> http-conduit between proxies. I kind of think of the http-conduit as
>> an http client, is that bad analogy?
>>
>> Thanks for the insight, definitely narrowing in on a solution.
>>
>>
>> Daniel Kulp wrote:
>>  
>>> Oh.  Yea.   That would definitely do it.  Good catch.   Each client
>>> proxy holds it's own conduit and thus the cookie for the session is
>>> stored there is unique for each proxy.
>>>
>>> Most likely, you will need to do some cookie management your self. 
>>> Grab the protocol headers from the response headers and set them in
>>> the request headers for all the proxies.     You can use the
>>> org.apache.cxf.transport.http.Cookie class to help with the
>>> parsing/setting.
>>>
>>> Dan
>>>
>>>
>>> On Friday 01 February 2008, Chris Campbell wrote:
>>>    
>>>> The problem is that I get a different session for different
>>>> endpoints, maybe its how I set the client up? I do set the client up
>>>> in java code rather than with xml config, so maybe I am doing
>>>> something wrong there. Is it possible that each service interface is
>>>> getting a different http-conduit?
>>>>
>>>> Daniel Kulp wrote:
>>>>      
>>>>> On Friday 01 February 2008, Chris Campbell wrote:
>>>>>        
>>>>>> I am using CXFServlet in tomcat, and intend to load balance
>>>>>> instances of them with apache mod_jk, and want to use sticky
>>>>>> sessions.
>>>>>>
>>>>>> I figure I have to create a session somewhere, as I do not see a
>>>>>> session created (JSESSIONID ?) automatically. For reasons not worth
>>>>>> going into, I do not need the session for state, beyond making sure
>>>>>> that the sticky-ness works on the load-balancer.
>>>>>>
>>>>>> I have tried getting the HttpServletRequest in an interceptor
>>>>>> (USER_LOGICAL phase) and creating an HttpSession if there is none,
>>>>>> and it seems to work.
>>>>>>
>>>>>> The problem is that I have a few soap endpoints at different URLs,
>>>>>> and the session seems to be created for each endpoint, so calls to
>>>>>> Service /Foo gets on session and /Bar another. This causes my
>>>>>> sticky session load balancer to send /Foo to one of the load
>>>>>> balanced CXFServlet and /Bar to another .
>>>>>>
>>>>>> Is there some way to create the Session so that it is valid for all
>>>>>> the service endpoints? Is setting the Session in an interceptor a
>>>>>> bad idea?
>>>>>>           
>>>>> That should be completely fine assuming that works with tomcat.
>>>>> This really is a tomcat question which I don't really know much
>>>>> about.   I would assume if all the endpoints are on the CXFServlet
>>>>> instance they would have properly shared the session.   If they are
>>>>> in separate wars, maybe not.   I don't know know enough about the
>>>>> servlet spec to know what the rules are around that.
>>>>>         
>>>     
>>
>>   
> 
> 

Mime
View raw message