On Monday, August 22, 2011 3:59:39 PM Jesse Pangburn wrote:
> 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) {
WSAddressingFeature is a subclass of AbstractFeature which does have the
signature.
> 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.
Right, but a fairly simple:
boolean endpointEnabled = getEndpoint().getProperty("ws.addressing...");
boolean busEnabled = bus.getProperty("ws.add....");
if (busEnabled || endpointEnabled) {
.....
}
would work and simpler than searching all the features and such.
> 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?
I'm OK with this, it's just a little more processing on each request, but
nothing THAT major.
Dan
>
> Thanks,
> Jesse
>
> -----Original Message-----
> From: Daniel Kulp [mailto:[email protected]]
> Sent: Friday, August 19, 2011 2:29 PM
> To: [email protected]
> 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:[email protected]]
> > Sent: Friday, August 19, 2011 8:49 AM
> > To: [email protected]
> > 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 <[email protected]>:
> > > 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:[email protected]]
> > > Sent: Thursday, August 18, 2011 2:29 PM
> > > To: [email protected]
> > > 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(MojoExecu
> > >> tor.
> > >> java: 217)*15:57:55* at
> > >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecu
> > >> tor.
> > >> java: 153)*15:57:55* at
> > >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecu
> > >> tor.
> > >> java: 145)*15:57:55* at
> > >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildPr
> > >> ojec
> > >> t(Lif ecycleModuleBuilder.java:84)*15:57:55* at
> > >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildPr
> > >> ojec
> > >> t(Lif ecycleModuleBuilder.java:59)*15:57:55* at
> > >> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreade
> > >> dBui
> > >> ld(Li fecycleStarter.java:183)*15:57:55* at
> > >> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifec
> > >> ycle
> > >> 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(Maven3Launche
> > >> r.j
> > >> ava:79 )*15:57:55* at
> > >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > >> Method)*15:57:55*
> > >>
> > >> at
> > >>
> > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorIm
> > >> pl.j
> > >> ava:39 )*15:57:55* at
> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAc
> > >> cess
> > >> 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(L
> > >> aunc
> > >> 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:15
> > >> 8)*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(ThreadPoolE
> > >> xec
> > >> utor.j ava:886)*15:57:55* at
> > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecu
> > >> tor.
> > >> 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(WSDL2JavaM
> > >> ojo.
> > >> java:6 13)*15:57:55* at
> > >> org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.ja
> > >> va:4
> > >> 36)*1 5:57:55* at
> > >> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Defa
> > >> ultB
> > >> uildP luginManager.java:101)*15:57:55* at
> > >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecu
> > >> tor.
> > >> 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:5
> > >> 5*
> > >> 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:5
> > >> 5*
> > >>
> > >> at
> > >>
> > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf
> > >> (Cla
> > >> ssRea lm.java:386)*15:57:55* at
> > >> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadCla
> > >> ss(S
> > >> elfFi rstStrategy.java:42)*15:57:55* at
> > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRe
> > >> alm.
> > >> java: 244)*15:57:55* at
> > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRe
> > >> alm.
> > >> 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(Unk
> > >> nown
> > >> 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(Exte
> > >> nded
> > >> 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(WSDL2JavaM
> > >> ojo.
> > >> 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.loadCla
> > >> ss(S
> > >> elfFir stStrategy.java:50)*15:57:55* at
> > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRe
> > >> alm.
> > >> java: 244)*15:57:55* at
> > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRe
> > >> alm.
> > >> 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
> > > [email protected]
> > > http://dankulp.com/blog
> > > Talend - http://www.talend.com
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
