On Friday, July 22, 2011 4:16:39 PM Algirdas Veitas wrote:
> Small world :)
> 
> RE: Hmm... with #3, you shouldn't even be hitting this.   The HEADER_LIST
> should
> be completely created per request since it wouldn't be pulled from the
> request
> context.     However, if the HEADER_LIST is added to the request context  at
> ANY time, even using #3 after that would cause an issue.  If you aren't
> touching the HEADER_LIST anywhere, then I'm not really sure what is going
> on.
> 
> Yeah, we are not manipulating the HEADER_LIST anywhere in our code, so am
> not sure what is going on either....
> 
> RE: 2) After returning from any method where you had set a header, call:  *
> context*.getMessageContext().remove(Header.HEADER_LIST);
> 
> How do I get a handle to the "context", in our situation where we are using
> generated code?

Sorry.  That would be the actual proxy object.    For example:

MyServiceInterface proxy = service.getMyServicePort();
((BindingProvider)proxy).getRequestContext().....

With JAX-WS, all the proxys implement not only the generated interface, but 
also the BindingProvider interface.


Dan




> 
> Thanks,
> Al
> 
> On Fri, Jul 22, 2011 at 4:04 PM, Daniel Kulp <[email protected]> wrote:
> > On Friday, July 22, 2011 3:58:06 PM Algirdas Veitas wrote:
> > > Hi Daniel,
> > > 
> > > Nice meeting you as well!
> > 
> > Just discovered you and I went to Northeastern at roughly the same time.
> > We
> > may have met before.  :-)
> > 
> > > One follow up question....the way we are adding headers is #3.  Our
> > > generated client code treats our headers like an ordinary parameter
> > > in
> > 
> > the
> > 
> > > method signature.  Will your solution work for this strategy as
> > > well?
> > 
> > Hmm... with #3, you shouldn't even be hitting this.   The HEADER_LIST
> > should
> > be completely created per request since it wouldn't be pulled from the
> > request
> > context.     However, if the HEADER_LIST is added to the request context
> > 
> >  at
> > 
> > ANY time, even using #3 after that would cause an issue.  If you aren't
> > touching the HEADER_LIST anywhere, then I'm not really sure what is
> > going
> > on.
> > Strange.   Definitely give it a try though.
> > 
> > 
> > Dan
> > 
> > > Al
> > > 
> > > On Fri, Jul 22, 2011 at 3:45 PM, Daniel Kulp <[email protected]> wrote:
> > > > We talked briefly about this at lunch today (nice to meet you
> > > > Al!) but wanted
> > > > to follow up here.....
> > > > 
> > > > 
> > > > The per-proxy request context can definitely come into play
> > > > here.   If any of
> > > > the threads add a header list to the RequestContext via the
> > > > method
> > > > mentioned
> > 
> > > > in #4 of:
> > http://cxf.apache.org/faq#FAQ-HowcanIaddsoapheaderstotherequest%2Frespon
> > 
> > > > se%3F
> > > > 
> > > > then those headers would be sent on all methods called on the
> > > > proxy.
> > > > 
> > > > What's worse, I THINK that List is just copied into the real
> > > > message
> > > > context
> > > > so any header processing done during the processing of the
> > > > message
> > 
> > would
> > 
> > > > affect that list, thus affecting all threads as well as future
> > > > method
> > > > calls on
> > > > the same thread.      Thinking about this, it may make sense to
> > > > clone
> > > > the
> > > > list
> > > > at the very start of processing messages to make sure the header
> > > > list
> > 
> > in
> > 
> > > > the
> > > > request context isn't modified.   That might be worth filing a
> > > > jira
> > 
> > for.
> > 
> > > > For now, I would suggest doing 2 things:
> > > > 
> > > > 1) Use the thread local request contexts:
> > > > 
> > > > <jaxws:client id="xService"
> > > > 
> > > >         serviceClass="com.XService"
> > > >         address="#xServiceUrl" >
> > > >     
> > > >     <jaxws:properties>
> > > >     
> > > >            <entry key="thread.local.request.context"
> > > >            value="true" />
> > > >        
> > > >        </jaxws:properties>
> > > > 
> > > > </jaxws:client>
> > > > 
> > > > 2) After returning from any method where you had set a header,
> > > > call:
> > > > context.getMessageContext().remove(Header.HEADER_LIST);
> > > > 
> > > > 
> > > > That should keep things in a good state.
> > > > 
> > > > Dan
> > > > 
> > > > On Friday, July 22, 2011 10:25:10 AM Algirdas Veitas wrote:
> > > > > Hi,
> > > > > 
> > > > > We are getting a ConcurrentModificationException exception
> > > > > in our
> > > > > CXF
> > > > > client, when it is processing SOAPHeaders.    We did find
> > > > > this
> > > > > following link that describes what is going on
> > 
> > http://cxf.547215.n5.nabble.com/jira-Created-CXF-2762-Cannot-deploy-csta
> > 
> > > > -web
> > > > 
> > > > > -service-td586662.html#a586663, and we will address that
> > > > > (Header
> > > > > object
> > > > > needs to be unique across threads), but something else
> > > > > strange is
> > > > > happening:
> > > > > 
> > > > > To start here is our client setup
> > > > > 
> > > > >   <!-- Web Service Clients -->
> > > > >   
> > > > >     <jaxws:client id="xService"
> > > > >     
> > > > >         serviceClass="com.XService"
> > > > >         address="#xServiceUrl" />
> > > > > 
> > > > > This WSDL that is associate with this client has some
> > > > > methods that
> > > > > DO
> > > > 
> > > > have a
> > > > 
> > > > > Header and some DO NOT.
> > > > > 
> > > > > And here is the shortened stack trace:
> > > > > 
> > > > > <http://newportave.jira.com/wiki/display/21+Jul+2011+19/11%3
> > > > > A46%2C87 4>
> > > > > java.util.ConcurrentModificationException
> > > > > at
> > 
> > java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
> > 
> > > > > at java.util.AbstractList$Itr.next(AbstractList.java:343)
> > > > > at
> > 
> > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnve
> > 
> > > > lope
> > > > 
> > > > > Start(SoapOutInterceptor.java:139) at
> > 
> > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage
> > 
> > > > (Soa
> > > > 
> > > > > pOutInterceptor.java:81) at
> > 
> > org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage
> > 
> > > > (Soa
> > > > 
> > > > > pOutInterceptor.java:61) at
> > 
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> > 
> > > > hain
> > > > 
> > > > > .java:255) at
> > > > 
> > > > org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:516)
> > > > 
> > > > > Here is the rub: This exception is being thrown when we are
> > > > > calling
> > > > > a
> > > > 
> > > > method
> > > > 
> > > > > that DOES NOT have a Header, but on line 139 in
> > > > > SoapOutInterceptor,
> > > > > it
> > > > > looks like we are trying to process an list that has atleast
> > > > > 1
> > > > > header.
> > > >  
> > > >  Am
> > > >  
> > > > > pretty certain (this is occurring only in a specific
> > > > > environment)
> > > > > that
> > > > > other methods on this service were made previous to this
> > > > > error that
> > > > > did
> > > > > include a SOAP Header.  Am speculating, but is the SOAP
> > > > > Header being
> > > > 
> > > > cached
> > > > 
> > > > > in the request context and the request context is scoped per
> > > > > client
> > > > > instance as per the FAQ (
> > > > > http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthre
> > > > > adsafe%3 F)?
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > Al
> > > > 
> > > > --
> > > > Daniel Kulp
> > > > [email protected]
> > > > http://dankulp.com/blog
> > > > Talend - http://www.talend.com
> > 
> > --
> > Daniel Kulp
> > [email protected]
> > http://dankulp.com/blog
> > Talend - http://www.talend.com
-- 
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com

Reply via email to