Hi Jesse,
yes. That's the idea.
We can introduce "find.dispatch.operation" in the dispatch client's
request context. So, if you want to preemptively turn on this switch,
you can do:
your client:
Dispatch<Source> dispatch = ...
dispatch.getRequestContext().put("find.dispatch.operation",
Boolean.TRUE);
We can read this property in DispatchImpl and activate this op-finding
operation.
DispatchImpl:
boolean findDispatchOp =
Boolean.TRUE.equals(getRequestContext().get("find.dispatch.operation"));
And I think this DispatchImpl's invoke method should be restructured
so that the op-finding code is not invoked if one of the following
conditions holds:
case 1: property MessageContext.WSDL_OPERATION is set (because this
means, the op is already given),
case 2: the addressing feature is absent and property
find.dispatch.operation is not set to True (because this means, no one
implicitly or explicitly requested the op to be determined),
Then, for all other cases, we invoke the op-finding code.
Another thing that I think we should be changing is that we should set
the binding operation info in the binding properties instead of the
binding operation qname with key "dispatchToOperation" after invoking
the op-finding code and finding the operation. This will make it much
easier to get the binding information such as the soapaction value.
Currently, SoapPreProtocolOutInterceptor is missing the soapaction
extraction code that was added to the addressing's MAPAggregator for
CXF-2836. If we pass the binding operation info instead, we can
directly extract the soapaction value from it. In that way, both
interceptors can have a simpler dispatch-case handling.
Alternatively, we could even think about replacing the original
binding operation in DispatchImpl when the operation is determined
after the op-finding code is invoked. In that case, we could remove
this special dispatch specific treatment part from
SoapPreprotocolOutInterceptor and MAPAggreagator and simply this part,
as the correct operation is already set.
I am asking Jim (who did the CXF-2836 fix) about how he thinks about
it. Maybe, there are some cases where we cannot pass the binding
operation info. I don't know. I hope he can give us some background.
Regards, aki
2011/8/24 Jesse Pangburn <jesse.pangb...@us.lawson.com>:
> 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:elak...@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.pangb...@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:dk...@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:elak...@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.pangb...@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:dk...@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
>>> > dk...@apache.org
>>> > http://dankulp.com/blog
>>> > Talend - http://www.talend.com
>> --
>> Daniel Kulp
>> dk...@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>>
>>
>
>
>
