On Tuesday, August 23, 2011 1:55:45 PM Jesse Pangburn wrote:
> 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.
The way you did it is fine. Running tests now.
Dan
>
> Thanks,
> Jesse
>
> -----Original Message-----
> From: Daniel Kulp [mailto:dk...@apache.org]
> Sent: Tuesday, August 23, 2011 11:05 AM
> 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 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: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(MojoE
> > > >> xecu
> > > >> tor.
> > > >> java: 217)*15:57:55* at
> > > >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoE
> > > >> xecu
> > > >> tor.
> > > >> java: 153)*15:57:55* at
> > > >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoE
> > > >> xecu
> > > >> tor.
> > > >> java: 145)*15:57:55* at
> > > >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.bui
> > > >> ldPr
> > > >> ojec
> > > >> t(Lif ecycleModuleBuilder.java:84)*15:57:55* at
> > > >> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.bui
> > > >> ldPr
> > > >> ojec
> > > >> t(Lif ecycleModuleBuilder.java:59)*15:57:55* at
> > > >> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThr
> > > >> eade
> > > >> dBui
> > > >> ld(Li fecycleStarter.java:183)*15:57:55* at
> > > >> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(L
> > > >> ifec
> > > >> 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)*1
> > > >> 5:57
> > > >>
> > > >> :55
> > > >>
> > > >> * at
> > > >> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Lau
> > > >> nche
> > > >> r.j
> > > >> ava:79 )*15:57:55* at
> > > >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > > >> Method)*15:57:55*
> > > >>
> > > >> at
> > > >>
> > > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> > > >> orIm
> > > >> pl.j
> > > >> ava:39 )*15:57:55* at
> > > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> > > >> odAc
> > > >> 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.launchStanda
> > > >> rd(L
> > > >> aunc
> > > >> her.j ava:329)*15:57:55* at
> > > >> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launc
> > > >> her.
> > > >> java
> > > >>
> > > >> :239) *15:57:55* at
> > > >>
> > > >> org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.jav
> > > >> a: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:5
> > > >> 5*
> > > >> at
> > > >> hudson.remoting.UserRequest.perform(UserRequest.java:118)*15:5
> > > >> 7: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(ThreadP
> > > >> oolE
> > > >> xec
> > > >> utor.j ava:886)*15:57:55* at
> > > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
> > > >> xecu
> > > >> 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(WSDL2J
> > > >> avaM
> > > >> ojo.
> > > >> java:6 13)*15:57:55* at
> > > >> org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMoj
> > > >> o.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(MojoE
> > > >> xecu
> > > >> 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)*1
> > > >> 5: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:5
> > > >> 5*
> > > >> 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.loadClassFrom
> > > >> Self
> > > >> (Cla
> > > >> ssRea lm.java:386)*15:57:55* at
> > > >> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loa
> > > >> dCla
> > > >> ss(S
> > > >> elfFi rstStrategy.java:42)*15:57:55* at
> > > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(Cla
> > > >> ssRe
> > > >> alm.
> > > >> java: 244)*15:57:55* at
> > > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(Cla
> > > >> ssRe
> > > >> alm.
> > > >> java: 230)*15:57:55* at
> > > >> org.apache.xerces.parsers.AbstractDOMParser.startDocument(Unkn
> > > >> own
> > > >> Source)*15:57:55* at
> > > >> org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unkno
> > > >> wn
> > > >> Source)*15:57:55* at
> > > >> org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unkn
> > > >> own
> > > >> 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:1
> > > >> 24)*
> > > >> 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(ToolRu
> > > >> nner
> > > >> .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(WSDL2J
> > > >> avaM
> > > >> 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.loa
> > > >> dCla
> > > >> ss(S
> > > >> elfFir stStrategy.java:50)*15:57:55* at
> > > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(Cla
> > > >> ssRe
> > > >> alm.
> > > >> java: 244)*15:57:55* at
> > > >> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(Cla
> > > >> ssRe
> > > >> 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
> > > > 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
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
