Chris, That should be fine as long as your SessionManager is properly re-entrant/thread safe.
Dan On Sunday 03 February 2008, Chris Campbell wrote: > 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. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
