Understand the following and agree it would work:
boolean endpointEnabled = getEndpoint().getProperty("ws.addressing...");
boolean busEnabled = bus.getProperty("ws.add....");
if (busEnabled || endpointEnabled) {
.....
}
If you prefer to revise the patch I submitted to do this instead, that's
totally fine by me. OTOH, when the list of features is typically going to be
under three anyway, looping over zero to three items is probably not going to
impact performance. I'm happy either way.
Thanks,
Jesse
-----Original Message-----
From: Daniel Kulp [mailto:[email protected]]
Sent: Tuesday, August 23, 2011 11:05 AM
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 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
