cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Pangburn <Jesse.Pangb...@us.lawson.com>
Subject RE: setting wsa:addressing feature in cxf:bus causes wrong action header to be sent when using Dispatch API
Date Wed, 24 Aug 2011 19:10:06 GMT
Hi Aki,
Yeah, that's a good point.  It can't be setting the SOAPAction automatically either without
running this code.  So if we run this code all the time, then SOAPAction will be set correctly
with the result as well as ws-addressing action.  Then if the user wants to override the soap
action for some reason, he can update the dispatcher's request context (as you pointed out).

The downside is it looks like the getPayloadMethodName method is kinda heavy because if you're
working with a stream it makes a Document object and a copy of the stream in order to look
into the stream.  So I guess that's why you don't already have this code running all the time.

So you want to make this optional by passing some Boolean flag to the ServiceImpl's createDispatch
method to say explicitly whether to run this code or not?  That way the user can avoid this
expense if they don't need the soap action or ws-addressing action set?

Thanks,
Jesse

-----Original Message-----
From: Aki Yoshida [mailto:elakito@googlemail.com]
Sent: Wednesday, August 24, 2011 5:47 AM
To: users@cxf.apache.org
Subject: Re: setting wsa:addressing feature in cxf:bus causes wrong action header to be sent
when using Dispatch API

Hi Jesse, Dan,
My intention was to provide an option for the client to decide whether
to invoke this operation determination code independently of the use
of the addressing feature. In this way, if someone is creating a
dispatch client with some WSDL file, he can make the soapaction header
of his request message automatically set based on the payload element
instead of having to set the soapaction header explicitly in the
dispatch client's request context. Whereas someone else may prefer not
to have this code invoked as he sets the operation and soapaction
values manually in the dispatcher's request context.

Regards, aki

2011/8/22 Jesse Pangburn <Jesse.Pangburn@us.lawson.com>:
> I don't think that will work because the WSAddressingFeature doesn't have that method
signature, it has:
>    protected void initializeProvider(InterceptorProvider provider, Bus bus) {
>
> Client is a subclass of InterceptorProvider, but although you could do something like:
> if (provider instanceof Client){
>        client.getEndpoint().put("addressing.enabled", Boolean.TRUE);
> }
>
> This wouldn't get called if the wsAddressing was enabled on the bus.  The AbstractFeature
has the method signature you're referring to, but it's only called on a client object so again
if the bus is enabling it then it won't work.
>
> It appears that we have three remaining choices:
> 1.  in the DispatchImpl we will have to loop over the bus features, the endpoint features,
and the passed in dispatch features to determine if ws addressing is enabled or not during
the invoke operation
> 2.  we do that loop in the ServiceImpl when building the Dispatch and set some property
in the dispatch as Aki suggested.
> 3.  In the ServiceImpl we copy the features from the bus and the passed in dispatch feature
into the endpoint feature list.  Then the invoke method that already exists will find the
feature in the list.
>
> #1 is kind of ugly cause it's doing the same thing over and over on a dispatch object,
where if someone is re-using a dispatch object for multiple invoke operations then they'll
be paying that performance penalty over and over.  #3 is not quite so bad cause you still
have to loop over the same list, but at least it's already in once place to do it, but it's
almost as bad.  I'm not thrilled about #2 because I find adding properties/flags for information
we already have to be confusing to new developers.
>
> To come up with a solution, I decided this was similar to interceptors in that you have
to process a compound list from disparate sources.  To build the interceptor chain, you getInterceptors()
on the bus, the client, the endpoint, the binding, and service databinding.  This is done
on EVERY client invocation and then the full list is processed.  So to parallel the way you've
done interceptors, we should loop inside the invoke method over the features contained in
the client factory, the endpoint, and the bus (those are the features locations I know of).
 Unfortunately, the client factory is not retained outside the ServiceImpl so I think those
features must be copied into the endpoint's feature list so they're treated the same as features
added in the createDispatch method as a parameter to the method.  Then the Dispatch's invoke
will loop over that new endpoint feature list and the bus feature list to get the complete
set and determine if ws-addressing is enabled.
>
> I will create the patch this way unless anyone objects?
>
> Thanks,
> Jesse
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Friday, August 19, 2011 2:29 PM
> To: users@cxf.apache.org
> Cc: Jesse Pangburn
> Subject: Re: setting wsa:addressing feature in cxf:bus causes wrong action header to
be sent when using Dispatch API
>
> On Friday, August 19, 2011 3:07:50 PM Jesse Pangburn wrote:
>> Hi Aki,
>> I'm REALLY new to CXF so I don't quite understand your answer.  Could you
>> explain what sort of configuration option you mean, and what shape it would
>> take?  In that case, how would the code "find the option and set the action
>> accordingly"?
>
> I kind of wonder if the WSAddressingFeature should do something like:
>
>    public void initialize(Client client, Bus bus) {
>        super.initialize(client, bus);
>        client.getEndpoint().put("addressing.enabled", Boolean.TRUE);
>    }
>
> or  similar.  The frontend could then just do a simple
> client.getEndpoint().get("addressing.enabled") != null or similar and not have
> to go through looking for the feature and such.
>
> Dan
>
>
>
>>
>> Thanks,
>> Jesse
>>
>> -----Original Message-----
>> From: Aki Yoshida [mailto:elakito@googlemail.com]
>> Sent: Friday, August 19, 2011 8:49 AM
>> To: users@cxf.apache.org
>> Subject: Re: setting wsa:addressing feature in cxf:bus causes wrong action
>> header to be sent when using Dispatch API
>>
>> Hi,
>> I think we should just provide a configuration option to either enable
>> or disable this operation determination code in DispathImpl,
>> independently of whether the addressing feature is engaged. In this
>> way, you can decide whether to let this code find the operation and
>> set the action accordingly or manually set the operation and action at
>> the dispatcher.
>>
>> regards, aki
>>
>> 2011/8/19 Jesse Pangburn <Jesse.Pangburn@us.lawson.com>:
>> > Hi,
>> > Another Dispatch API / wsAddressing question.  I configured ws
>> > addressing on the cxf bus like this, instead of adding the feature
>> > directly to the dispatch client: <cxf:bus>
>> >        <cxf:features>
>> >                <wsa:addressing/>
>> >        </cxf:features>
>> > </cxf:bus>
>> >
>> > However using both SOAP 1.1 and 1.2 Dispatch API clients, I found that
>> > it sets the wrong Action header by just using a default rather than the
>> > one from the WSDL.  I'm not certain which code is responsible for this
>> > but I see in the DispatchImpl.java the following code: boolean
>> > wsaEnabled = false;
>> > for (AbstractFeature feature :
>> > ((JaxWsClientEndpointImpl)client.getEndpoint()).getFeatures()) { if
>> > (feature instanceof WSAddressingFeature) {
>> >    wsaEnabled = true;
>> >  }
>> > }
>> >
>> > This only looks for the features on the endpoint to determine if it
>> > should do ws addressing, not the features on the bus too.  So the
>> > DispatchImpl doesn't set this stuff up.  Is there other code down the
>> > line that should be doing a similar thing with the bus's features?  Or
>> > should the DispatchImpl be checking the bus features as well as the
>> > endpoint features here?
>> >
>> > Thanks,
>> > Jesse
>> >
>> > -----Original Message-----
>> > From: Daniel Kulp [mailto:dkulp@apache.org]
>> > Sent: Thursday, August 18, 2011 2:29 PM
>> > To: users@cxf.apache.org
>> > Cc: David Karlsen
>> > Subject: Re: java.lang.ClassNotFoundException:
>> > org.w3c.dom.ElementTraversal during wsdl2java generation - any clues?
>> >
>> >
>> > I would check you meven dependencies for any old versions of Xerces or
>> > xml- api's.   It kind of looks like it's pulling in some older stuff
>> > someplace that is conflicting.
>> >
>> > Dan
>> >
>> > On Thursday, August 18, 2011 4:07:25 PM David Karlsen wrote:
>> >> With 2.4.2 and the maven plugin doing wsdl2java I get:
>> >>
>> >> *15:57:55*  message : Failed to execute goal
>> >> org.apache.cxf:cxf-codegen-plugin:2.4.2:wsdl2java (generate-sources)
>> >> on project pays-web-ws-pays: org/w3c/dom/ElementTraversal*15:57:55*
>> >> cause : org/w3c/dom/ElementTraversal*15:57:55*  Stack trace :
>> >> *15:57:55*  org.apache.maven.lifecycle.LifecycleExecutionException:
>> >> Failed to execute goal
>> >> org.apache.cxf:cxf-codegen-plugin:2.4.2:wsdl2java (generate-sources)
>> >> on project pays-web-ws-pays: org/w3c/dom/ElementTraversal*15:57:55*
>> >>       at
>> >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.
>> >> java: 217)*15:57:55* at
>> >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.
>> >> java: 153)*15:57:55* at
>> >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.
>> >> java: 145)*15:57:55* at
>> >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec
>> >> t(Lif ecycleModuleBuilder.java:84)*15:57:55* at
>> >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProjec
>> >> t(Lif ecycleModuleBuilder.java:59)*15:57:55* at
>> >> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBui
>> >> ld(Li fecycleStarter.java:183)*15:57:55* at
>> >> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycle
>> >> Start er.java:161)*15:57:55* at
>> >> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)*15:57:5
>> >> 5* at
>> >> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)*15:57:55
>> >> * at
>> >> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.j
>> >> ava:79 )*15:57:55* at
>> >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)*15:57:55*
>> >>     at
>> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>> >> ava:39 )*15:57:55* at
>> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
>> >> orImp l.java:25)*15:57:55* at
>> >> java.lang.reflect.Method.invoke(Method.java:597)*15:57:55*    at
>> >> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launc
>> >> her.j ava:329)*15:57:55* at
>> >> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java
>> >> :239) *15:57:55* at
>> >> org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)*1
>> >> 5:57: 55* at
>> >> hudson.maven.Maven3Builder.call(Maven3Builder.java:121)*15:57:55* at
>> >> hudson.maven.Maven3Builder.call(Maven3Builder.java:73)*15:57:55* at
>> >> hudson.remoting.UserRequest.perform(UserRequest.java:118)*15:57:55*
>> >> at hudson.remoting.UserRequest.perform(UserRequest.java:48)*15:57:55*
>> >> at hudson.remoting.Request$2.run(Request.java:287)*15:57:55*     at
>> >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:44
>> >> 1)*15: 57:55* at
>> >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)*15:
>> >> 57:55 * at
>> >> java.util.concurrent.FutureTask.run(FutureTask.java:138)*15:57:55* at
>> >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
>> >> utor.j ava:886)*15:57:55* at
>> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
>> >> java: 908)*15:57:55* at
>> >> java.lang.Thread.run(Thread.java:662)*15:57:55*  Caused by:
>> >> org.apache.maven.plugin.MojoExecutionException:
>> >> org/w3c/dom/ElementTraversal*15:57:55*        at
>> >> org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.
>> >> java:6 13)*15:57:55* at
>> >> org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:4
>> >> 36)*1 5:57:55* at
>> >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultB
>> >> uildP luginManager.java:101)*15:57:55* at
>> >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.
>> >> java: 209)*15:57:55* ... 27 more*15:57:55*  Caused by:
>> >> java.lang.NoClassDefFoundError: org/w3c/dom/ElementTraversal*15:57:55*
>> >
>> > at
>> >
>> >> java.lang.ClassLoader.defineClass1(Native Method)*15:57:55*   at
>> >> java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)*15:57:55*
>> >>       at
>> >> java.lang.ClassLoader.defineClass(ClassLoader.java:615)*15:57:55* at
>> >> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141
>> >> )*15: 57:55* at
>> >> java.net.URLClassLoader.defineClass(URLClassLoader.java:283)*15:57:55*
>> >> at
>> >> java.net.URLClassLoader.access$000(URLClassLoader.java:58)*15:57:55*
>> >> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)*15:57:55*
>> >> at java.security.AccessController.doPrivileged(Native
>> >> Method)*15:57:55*     at
>> >> java.net.URLClassLoader.findClass(URLClassLoader.java:190)*15:57:55*
>> >>       at
>> >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(Cla
>> >> ssRea lm.java:386)*15:57:55* at
>> >> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(S
>> >> elfFi rstStrategy.java:42)*15:57:55* at
>> >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.
>> >> java: 244)*15:57:55* at
>> >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.
>> >> java: 230)*15:57:55* at
>> >> org.apache.xerces.parsers.AbstractDOMParser.startDocument(Unknown
>> >> Source)*15:57:55*     at
>> >> org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown
>> >> Source)*15:57:55*     at
>> >> org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown
>> >> Source)*15:57:55*     at
>> >> org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown
>> >> Source)*15:57:55*     at
>> >> org.apache.xerces.parsers.XML11Configuration.parse(Unknown
>> >> Source)*15:57:55*     at
>> >> org.apache.xerces.parsers.XML11Configuration.parse(Unknown
>> >> Source)*15:57:55*     at
>> >> org.apache.xerces.parsers.XMLParser.parse(Unknown Source)*15:57:55*
>> >>       at org.apache.xerces.parsers.DOMParser.parse(Unknown
>> >> Source)*15:57:55*     at
>> >> org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown
>> >> Source)*15:57:55*     at
>> >> javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:124)*15:5
>> >> 7:55* at
>> >> org.apache.cxf.tools.common.dom.ExtendedDocumentBuilder.parse(Extended
>> >> Docum entBuilder.java:95)*15:57:55* at
>> >> org.apache.cxf.tools.common.toolspec.ToolSpec.<init>(ToolSpec.java:71)
>> >> *15:5 7:55* at
>> >> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.jav
>> >> a:86) *15:57:55* at
>> >> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)*15:57:
>> >> 55* at
>> >> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)*15:57:
>> >> 55* at
>> >> org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.
>> >> java: 610)*15:57:55* ... 30 more*15:57:55*  Caused by:
>> >> java.lang.ClassNotFoundException:
>> >> org.w3c.dom.ElementTraversal*15:57:55*
>> >>       at
>> >> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(S
>> >> elfFir stStrategy.java:50)*15:57:55* at
>> >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.
>> >> java: 244)*15:57:55* at
>> >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.
>> >> java: 230)*15:57:55* ... 59 more
>> >>
>> >>
>> >> Running on latest sun 1.6 jdk.
>> >> Any clues?
>> >>
>> >> --
>> >> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://dankulp.com/blog
>> > Talend - http://www.talend.com
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
> Talend - http://www.talend.com
>
>
>



Mime
View raw message