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
