[ https://issues.apache.org/jira/browse/CXF-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787179#action_12787179
]
Daniel Kulp commented on CXF-2569:
----------------------------------
Can you create a testcase for this? CXF never uses the ObjectFactory things. All of
that stuff is delegated down to JAXB. Thus, I'd like to see a testcase to see what is happening.
> Consuming a wsdl file which is having a nested complex types in xsd
> -------------------------------------------------------------------
>
> Key: CXF-2569
> URL: https://issues.apache.org/jira/browse/CXF-2569
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Environment: jdk 1.5 ,windows xp,IBM websphere server
> Reporter: vijay valeti
> Priority: Blocker
> Original Estimate: 0.03h
> Remaining Estimate: 0.03h
>
> When we are trying to consume a wsdl file which is having a nested complex type xsd element
we are getting an exception
> IllegalArgumentException:Wrong Number of Arguments provided
> when ever you have a nested complex type in xsd,in the ObjectFactory.java class will
be having two create methods for the nested element.i feel cxf is not implemented properly
to handle this kind of situation . i believe that cxf developers/community assuemd that there
wont be any overloaded create methods in the OBjectFactory.java class
> sample XSD
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element>
> <xsd:complexType name="testList">
> <xsd:sequence>
> <xsd:element name="test" type="xsd:string" maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:element>
> <xsd:element name="name" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787172#action_12787172
]
Daniel Kulp commented on CXF-2570:
----------------------------------
I'm pretty sure this is "working as designed" more or less. In your cxf-servlet.xml or beans
or whatever where you define your jaxws:endpoint things, are you putting address attributes
on them to define the address (should be just "/OrderService" in your case)? If not, you
need to when using a Servlet.
> ServletDestinationFacotry and Tomcat can't locate services
> ----------------------------------------------------------
>
> Key: CXF-2570
> URL: https://issues.apache.org/jira/browse/CXF-2570
> Project: CXF
> Issue Type: Bug
> Environment:
> « Hide
> System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> Java:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Apache CXF 2.2.3 (not in version list)
> Reporter: Christian Connert
> Attachments: cxf.xml, TomcatDestinationFactory.java
>
>
> The problem is that the service destinations aren't found by the destination factory.
> I think this problem isn't Tomcat specific. It should occur if cxf is deployed as a war
inside some application server.
> I would suggest the following workaround:
> 1.) Implement a ServletTransportFactory (see attachment 1)
> 2.) Register this ServletTransportFactory in the default cxf.xml (classpath root, see
attachment 2)
> As a clean fix the ServletTransportFactory should make the static String getTrimmedPath(String
path) method to a protected non static method. Than it can be easily overriden by custom subclasses.
> Greetings
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2571.
------------------------------
Resolution: Fixed
Fix Version/s: 2.2.6
Assignee: Daniel Kulp
Workaround/hack committed to 2.2 branch. Tomorrows snapshots should have the fix. It would
be great if you could rerun your tests and such with the snapshot.
> wsdl2java and jax-ws-catalog: failing to resolve schemas included with xsd:include in
jar-file
> ----------------------------------------------------------------------------------------------
>
> Key: CXF-2571
> URL: https://issues.apache.org/jira/browse/CXF-2571
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.1.8, 2.2.5
> Environment: Apache Maven 2.2.1
> Java version: 1.5.0_21
> OS name: "windows xp"
> Reporter: HÃ¥kan Dahl
> Assignee: Daniel Kulp
> Fix For: 2.2.6
>
> Attachments: jax-ws-catalog-test-20091203.zip
>
>
> cxf-codegen-plugin/wsdl2java (2.1.8, 2.2.5)
> Refer user-list thread:
> http://old.nabble.com/jax-ws-catalog-and-resolving-schemas-in-jars-that-do-xsd%3Ainclude-td26590812.html
> Schema resolution from a jar-file (using jax-ws-catalog as per 4.4 Catalog Facility in
the JAX-WS 2.1 spec) fails when:
> * The referenced schema in a jar makes xsd:include on another schema in the
> jar (all schemas in a jar share the same namespace).
> Stacktrace below for CXF 2.1.8 below. CXF 2.2.5 also fails but with a NullPointerException.
> Note: xsd:import works but requires imported schema to be in another
> namespace.
> Projects look like:
> common-types-domain1
> META-INF/jax-ws-catalog.xml
> schemas/domain1/domain1-schema1.xsd
> schemas/domain1/domain1-schema2.xsd
> wsdl-project-1
> src\main\resources\schemas\GetX.xsd
> src\main\resources\schemas\GetXService.wsdl
> where the GetXService.wsdl imports GetX.xsd which imports
> domain1-schema2.xsd like this:
> GetX.xsd:
> <xsd:import namespace="http://www.example.org/schemas/domain1"
> schemaLocation="
> http://www.example.org/schemas/domain1/domain1-schema2.xsd"/>
> domain1-schema2.xsd:
> <xsd:include schemaLocation="domain1-schema1.xsd"/>
> common-types-domain1/META-INF/jax-ws-catalog.xml:
> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
> prefer="system">
> <system systemId="
> http://www.example.org/schemas/domain1/domain1-schema1.xsd"
> uri="classpath:schemas/domain1/domain1-schema1.xsd"/>
> <system systemId="
> http://www.example.org/schemas/domain1/domain1-schema2.xsd"
> uri="classpath:schemas/domain1/domain1-schema2.xsd"/>
> </catalog>
> results in:
> Caused by: org.apache.cxf.tools.common.ToolException: Thrown by JAXB :
> http://www.example.org/schemas/domain1/domain1-schema1.xsd
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:34)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:285)
> at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:90)
> at
> com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:402)
> at
> com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:301)
> at
> com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
> at
> org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:240)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:277)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:246)
> at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:123)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:135)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addSchemas(JAXBDataBinding.java:253)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:196)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:588)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:239)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:130)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:283)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
> at
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:337)
> ... 20 more
> Caused by: java.io.FileNotFoundException:
> http://www.example.org/schemas/domain1/domain1-schema1.xsd
> ... 39 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787158#action_12787158
]
Daniel Kulp commented on CXF-2574:
----------------------------------
This is normally caused due to a version conflict with a jar CXF ships and the one websphere
provides. In this case, it's LIKELY to be the wsdl4j jar. See the Websphere section
of:
http://cxf.apache.org/docs/application-server-specific-configuration-guide.html
> WSDL file not getting generated in WebSphere 6.1
> ------------------------------------------------
>
> Key: CXF-2574
> URL: https://issues.apache.org/jira/browse/CXF-2574
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2.5
> Environment: Windows XP, Websphere 6.1, CXF 2.2.5, spring 2.5
> Reporter: Vivek Pandian S
> Priority: Critical
>
> I could access the CXF WebService thro url from the browser. But if try to access the
wsdl file for the same, i get page not found error. In the server console , i get the following
exception
> [12/5/09 16:08:35:468 IST] 00000022 ServletContro W Can't find the request for http://localhost:9083/CXF//'s
Observer
> [12/5/09 16:08:36:655 IST] 00000022 ServletWrappe E SRVE0068E: Uncaught exception thrown
in one of the service methods of the servlet: CXFServlet. Exception thrown : java.lang.IncompatibleClassChangeError
> at org.apache.cxf.wsdl11.ServiceWSDLBuilder.addExtensibilityElements(ServiceWSDLBuilder.java:229)
> at org.apache.cxf.wsdl11.ServiceWSDLBuilder.buildBindingInput(ServiceWSDLBuilder.java:355)
> at org.apache.cxf.wsdl11.ServiceWSDLBuilder.buildBindingOperation(ServiceWSDLBuilder.java:324)
> at org.apache.cxf.wsdl11.ServiceWSDLBuilder.buildBinding(ServiceWSDLBuilder.java:305)
> at org.apache.cxf.wsdl11.ServiceWSDLBuilder.build(ServiceWSDLBuilder.java:193)
> at org.apache.cxf.wsdl11.ServiceWSDLBuilder.build(ServiceWSDLBuilder.java:148)
> at org.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:146)
> at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:156)
> at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:108)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
> at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
> at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3129)
> at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:238)
> at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811)
> at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433)
> at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:93)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
> at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
> at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
> at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
> at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
> at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:194)
> at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:741)
> at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:863)
> at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1510)
> Please help me in this regard
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2293.
------------------------------
Resolution: Cannot Reproduce
Fix Version/s: Invalid
No response for a month and unable to reproduce.
> cxf-codegen-plugin fails with 'Mojo Execution Failed'
> -----------------------------------------------------
>
> Key: CXF-2293
> URL: https://issues.apache.org/jira/browse/CXF-2293
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Environment: Windows XP / Eclipse 3.4.2 / m2eclipse 0.9.9
> Reporter: Roger Cracel
> Fix For: Invalid
>
>
> I can't seem to create a new project using maven for the wsdl first osgi archetype.
> Steps to reproduce the problem:
> in Eclipse, use m2eclipse pluging to create a new project using the servicemix-osgi-cxf-wsdl-first-archetype.
> Watch the console for the error message :
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin
manager executing goal 'org.apache.cxf:cxf-codegen-plugin:2.2.0.0-fuse:wsdl2java': Mojo execution
failed.
> This appears to be a classpath resolution problem, since the stack trace seems to indicate
org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl cannot be found.
> The exception stack trace:
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin
manager executing goal 'org.apache.cxf:cxf-codegen-plugin:2.2.0.0-fuse:wsdl2java': Mojo execution
failed.
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
> at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
> at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
> at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
> at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
> at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
> at org.maven.ide.eclipse.jdt.internal.JavaProjectConfigurator$1.execute(JavaProjectConfigurator.java:313)
> at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
> at org.maven.ide.eclipse.project.MavenProjectManager.execute(MavenProjectManager.java:160)
> at org.maven.ide.eclipse.jdt.internal.JavaProjectConfigurator.generateSourceEntries(JavaProjectConfigurator.java:307)
> at org.maven.ide.eclipse.jdt.internal.JavaProjectConfigurator.collectSourceEntries(JavaProjectConfigurator.java:366)
> at org.maven.ide.eclipse.jdt.internal.JavaProjectConfigurator.updateSourceFolders(JavaProjectConfigurator.java:112)
> at org.maven.ide.eclipse.jdt.internal.JavaProjectConfigurator.configure(JavaProjectConfigurator.java:99)
> at org.maven.ide.eclipse.internal.project.DefaultLifecycleMapping.configure(DefaultLifecycleMapping.java:60)
> at org.maven.ide.eclipse.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:347)
> at org.maven.ide.eclipse.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:327)
> at org.maven.ide.eclipse.actions.UpdateSourcesAction$1.runInWorkspace(UpdateSourcesAction.java:82)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Mojo execution failed.
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601)
> at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
> ... 22 more
> Caused by: org.apache.maven.plugin.MojoExecutionException: javax.xml.datatype.DatatypeConfigurationException:
Provider org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl not found
> at org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:363)
> at org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:257)
> at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
> ... 23 more
> Caused by: java.lang.Error: javax.xml.datatype.DatatypeConfigurationException: Provider
org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl not found
> at com.sun.xml.bind.DatatypeConverterImpl.<clinit>(DatatypeConverterImpl.java:785)
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl$3.run(JAXBContextImpl.java:266)
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl$3.run(JAXBContextImpl.java:265)
> at java.security.AccessController.doPrivileged(Native Method)
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:264)
> at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
> at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
> at com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:128)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:277)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:244)
> at org.apache.cxf.tools.wsdlto.core.PluginLoader.init(PluginLoader.java:82)
> at org.apache.cxf.tools.wsdlto.core.PluginLoader.<init>(PluginLoader.java:72)
> at org.apache.cxf.tools.wsdlto.core.PluginLoader.getInstance(PluginLoader.java:121)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.<init>(WSDLToJava.java:45)
> at org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:360)
> ... 25 more
> Caused by: javax.xml.datatype.DatatypeConfigurationException: Provider org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl
not found
> at javax.xml.datatype.DatatypeFactory.newInstance(DatatypeFactory.java:137)
> at com.sun.xml.bind.DatatypeConverterImpl.<clinit>(DatatypeConverterImpl.java:783)
> ... 46 more
> Caused by: java.lang.ClassNotFoundException: org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at javax.xml.datatype.FactoryFinder.getProviderClass(FactoryFinder.java:115)
> at javax.xml.datatype.FactoryFinder.newInstance(FactoryFinder.java:146)
> at javax.xml.datatype.FactoryFinder.findJarServiceProvider(FactoryFinder.java:298)
> at javax.xml.datatype.FactoryFinder.find(FactoryFinder.java:223)
> at javax.xml.datatype.DatatypeFactory.newInstance(DatatypeFactory.java:131)
> ... 47 more
> Environment:
> Eclipse Platform Version: 3.4.2
> Build id: M20090211-1700
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787133#action_12787133
]
Daniel Kulp commented on CXF-2571:
----------------------------------
I got past the NPE in 2.2.5 (we were not setting the systemId), but ran into a bug in XJC.
They are doing:
new URI(locator.getSystemId()).resolve(new URI(schemaLocation))
to resolve the include. However, that doesn't work with a "jar" url as the systemId of the
original schema. The URI in that case is considered opaque and thus resolve just returns
the child value as is. I THINK I can work around this by kind of DOM loading the schemas
and preprocessing the includes and such, but yuck.
I'm going to doubt I'll be able to fix this on 2.1.x as the databinding/schema code there
is very different.
> wsdl2java and jax-ws-catalog: failing to resolve schemas included with xsd:include in
jar-file
> ----------------------------------------------------------------------------------------------
>
> Key: CXF-2571
> URL: https://issues.apache.org/jira/browse/CXF-2571
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.1.8, 2.2.5
> Environment: Apache Maven 2.2.1
> Java version: 1.5.0_21
> OS name: "windows xp"
> Reporter: HÃ¥kan Dahl
> Attachments: jax-ws-catalog-test-20091203.zip
>
>
> cxf-codegen-plugin/wsdl2java (2.1.8, 2.2.5)
> Refer user-list thread:
> http://old.nabble.com/jax-ws-catalog-and-resolving-schemas-in-jars-that-do-xsd%3Ainclude-td26590812.html
> Schema resolution from a jar-file (using jax-ws-catalog as per 4.4 Catalog Facility in
the JAX-WS 2.1 spec) fails when:
> * The referenced schema in a jar makes xsd:include on another schema in the
> jar (all schemas in a jar share the same namespace).
> Stacktrace below for CXF 2.1.8 below. CXF 2.2.5 also fails but with a NullPointerException.
> Note: xsd:import works but requires imported schema to be in another
> namespace.
> Projects look like:
> common-types-domain1
> META-INF/jax-ws-catalog.xml
> schemas/domain1/domain1-schema1.xsd
> schemas/domain1/domain1-schema2.xsd
> wsdl-project-1
> src\main\resources\schemas\GetX.xsd
> src\main\resources\schemas\GetXService.wsdl
> where the GetXService.wsdl imports GetX.xsd which imports
> domain1-schema2.xsd like this:
> GetX.xsd:
> <xsd:import namespace="http://www.example.org/schemas/domain1"
> schemaLocation="
> http://www.example.org/schemas/domain1/domain1-schema2.xsd"/>
> domain1-schema2.xsd:
> <xsd:include schemaLocation="domain1-schema1.xsd"/>
> common-types-domain1/META-INF/jax-ws-catalog.xml:
> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
> prefer="system">
> <system systemId="
> http://www.example.org/schemas/domain1/domain1-schema1.xsd"
> uri="classpath:schemas/domain1/domain1-schema1.xsd"/>
> <system systemId="
> http://www.example.org/schemas/domain1/domain1-schema2.xsd"
> uri="classpath:schemas/domain1/domain1-schema2.xsd"/>
> </catalog>
> results in:
> Caused by: org.apache.cxf.tools.common.ToolException: Thrown by JAXB :
> http://www.example.org/schemas/domain1/domain1-schema1.xsd
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:34)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:285)
> at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:90)
> at
> com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:402)
> at
> com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:301)
> at
> com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
> at
> org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:240)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:277)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:246)
> at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:123)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:135)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addSchemas(JAXBDataBinding.java:253)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:196)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:588)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:239)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:130)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:283)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
> at
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:337)
> ... 20 more
> Caused by: java.io.FileNotFoundException:
> http://www.example.org/schemas/domain1/domain1-schema1.xsd
> ... 39 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ankur sarkar updated CXF-2575:
------------------------------
Attachment: mcso-mpacopalws-spring-beans.xml
ManageProductAvailability.wsdl
ManageCustomer.20080728.wsdl
Files for reference for issue 2575
> Not able to configure connection and receive timeouts through http-conf:conduit in spring
beans
> -----------------------------------------------------------------------------------------------
>
> Key: CXF-2575
> URL: https://issues.apache.org/jira/browse/CXF-2575
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.2
> Reporter: ankur sarkar
> Attachments: ManageCustomer.20080728.wsdl, ManageProductAvailability.wsdl, mcso-mpacopalws-spring-beans.xml
>
>
> I am using a spring based application to consume multiple services through cxf 2.2. I
have configured the connection timeout and receive timeouts in spring beans through the http-conf:conduit.
Now when I am doing this by using the wild card i.e.
> <http-conf:conduit name="*.http-conduit">
> <http-conf:client ConnectionTimeout="180000" ReceiveTimeout="180000"/>
> </http-conf:conduit>
> then both connection and receive timeouts are working fine but whenever we use the targetnamespace
and the portname the timeouts are not working.
> <http-conf:conduit name="{http://capabilities.nat.bt.com/wsdl/ManageProductAvailability/2007/04/30}ManageProductAvailabilitySyncPort.http-conduit">
> <http-conf:client ConnectionTimeout="180000" ReceiveTimeout="180000"/>
> </http-conf:conduit>
> Attached herewith are the springbeans and wsdls for your reference
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Not able to configure connection and receive timeouts through http-conf:conduit in spring beans
-----------------------------------------------------------------------------------------------
Key: CXF-2575
URL: https://issues.apache.org/jira/browse/CXF-2575
Project: CXF
Issue Type: Bug
Affects Versions: 2.2
Reporter: ankur sarkar
I am using a spring based application to consume multiple services through cxf 2.2. I have
configured the connection timeout and receive timeouts in spring beans through the http-conf:conduit.
Now when I am doing this by using the wild card i.e.
<http-conf:conduit name="*.http-conduit">
<http-conf:client ConnectionTimeout="180000" ReceiveTimeout="180000"/>
</http-conf:conduit>
then both connection and receive timeouts are working fine but whenever we use the targetnamespace
and the portname the timeouts are not working.
<http-conf:conduit name="{http://capabilities.nat.bt.com/wsdl/ManageProductAvailability/2007/04/30}ManageProductAvailabilitySyncPort.http-conduit">
<http-conf:client ConnectionTimeout="180000" ReceiveTimeout="180000"/>
</http-conf:conduit>
Attached herewith are the springbeans and wsdls for your reference
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
CXF - Monday, December 7, 2009
13 Issues with Attachments
(sorted oldest to newest)
[CXF-2183] wsdl2java "only one global bindings customization is allowed" with embedded
imported schema namespace
(2009-04-21 - Bug - Bob Fields)
http://issues.apache.org/jira/browse/CXF-2183
[CXF-2527] SymmetricBindingHandler wrongly uses relative references to wsc:Identifiers
(2009-11-06 - Bug - Colm O hEigeartaigh)
http://issues.apache.org/jira/browse/CXF-2527
[CXF-2540] JMX ResponseTimeFeature does not count client side exceptions
(2009-11-16 - Bug - Cyrille Le Clerc)
http://issues.apache.org/jira/browse/CXF-2540
[CXF-2541] JMX Per Operation ResponseTime not collected for JAX-RS services
(2009-11-16 - Bug - Cyrille Le Clerc)
http://issues.apache.org/jira/browse/CXF-2541
[CXF-2546] NullPointerException when trying to find WS-Addressing Action
(2009-11-17 - Bug - John Hite)
http://issues.apache.org/jira/browse/CXF-2546
[CXF-2550] transactions don't work in jaxws Endpoint with jms transport
(2009-11-19 - Bug - javier)
http://issues.apache.org/jira/browse/CXF-2550
[CXF-2551] NullPointerException at org.apache.cxf.transport.servlet.ServletController.updateDests(ServletController.java:92)
(2009-11-20 - Bug - Gary Gregory)
http://issues.apache.org/jira/browse/CXF-2551
[CXF-2554] JaxWsDynamicClientFactory.createClient(URL) and o.a.cxf.endpoint.Client.invoke(String
operationName, Object... params) generates illegal XML, WstxParsingException on server.
(2009-11-20 - Bug - Gary Gregory)
http://issues.apache.org/jira/browse/CXF-2554
[CXF-2555] JaxWsDynamicClientFactory unable to handle custom exceptions
(2009-11-21 - Bug - pavan kumar)
http://issues.apache.org/jira/browse/CXF-2555
[CXF-2562] Make it possible to change the title of the service list page
(2009-11-30 - Improvement - Rémi Flament)
http://issues.apache.org/jira/browse/CXF-2562
[CXF-2566] Missing translation for INSTRUMENTATION_REGISTER_FAULT_MSG
(2009-12-01 - Bug - Cyrille Le Clerc)
http://issues.apache.org/jira/browse/CXF-2566
[CXF-2570] ServletDestinationFacotry and Tomcat can't locate services
(2009-12-02 - Bug - Christian Connert)
http://issues.apache.org/jira/browse/CXF-2570
[CXF-2571] wsdl2java and jax-ws-catalog: failing to resolve schemas included with xsd:include
in jar-file
(2009-12-03 - Bug - Håkan Dahl)
http://issues.apache.org/jira/browse/CXF-2571
WSDL file not getting generated in WebSphere 6.1
------------------------------------------------
Key: CXF-2574
URL: https://issues.apache.org/jira/browse/CXF-2574
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.2.5
Environment: Windows XP, Websphere 6.1, CXF 2.2.5, spring 2.5
Reporter: Vivek Pandian S
Priority: Critical
I could access the CXF WebService thro url from the browser. But if try to access the wsdl
file for the same, i get page not found error. In the server console , i get the following
exception
[12/5/09 16:08:35:468 IST] 00000022 ServletContro W Can't find the request for http://localhost:9083/CXF//'s
Observer
[12/5/09 16:08:36:655 IST] 00000022 ServletWrappe E SRVE0068E: Uncaught exception thrown
in one of the service methods of the servlet: CXFServlet. Exception thrown : java.lang.IncompatibleClassChangeError
at org.apache.cxf.wsdl11.ServiceWSDLBuilder.addExtensibilityElements(ServiceWSDLBuilder.java:229)
at org.apache.cxf.wsdl11.ServiceWSDLBuilder.buildBindingInput(ServiceWSDLBuilder.java:355)
at org.apache.cxf.wsdl11.ServiceWSDLBuilder.buildBindingOperation(ServiceWSDLBuilder.java:324)
at org.apache.cxf.wsdl11.ServiceWSDLBuilder.buildBinding(ServiceWSDLBuilder.java:305)
at org.apache.cxf.wsdl11.ServiceWSDLBuilder.build(ServiceWSDLBuilder.java:193)
at org.apache.cxf.wsdl11.ServiceWSDLBuilder.build(ServiceWSDLBuilder.java:148)
at org.apache.cxf.transport.http.WSDLQueryHandler.writeResponse(WSDLQueryHandler.java:146)
at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:156)
at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:142)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3129)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:238)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:811)
at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:93)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:194)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:741)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:863)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1510)
Please help me in this regard
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Holtzman resolved CXF-2252.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: dOSGi-1.2)
dOSGi-1.1
This was implemented, and is available in v1.1 by setting the service property org.apache.cxf.ws.frontend=jaxws
and org.apache.cxf.ws.databinding=jaxb as documented at http://cxf.apache.org/distributed-osgi-reference.html
> Add support JAX-WS for DOSGi
> ----------------------------
>
> Key: CXF-2252
> URL: https://issues.apache.org/jira/browse/CXF-2252
> Project: CXF
> Issue Type: New Feature
> Components: Distributed-OSGi
> Affects Versions: dOSGi-1.0
> Reporter: Josh Holtzman
> Fix For: dOSGi-1.1
>
> Attachments: dosgi_jaxws.diff, dosgi_jaxws_jaxrs.diff
>
>
> Individual service registrations should be able to choose whether to utilize the Aegis
or JAX-WS databindings for distributed OSGi. The Aegis databinding, however, should remain
the default. See the discussion at http://www.nabble.com/Configuring-DOSGI-to-use-JAX-WS-td23487668.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-2252:
-----------------------------
Fix Version/s: (was: dOSGi-1.1)
dOSGi-1.2
> Add support JAX-WS for DOSGi
> ----------------------------
>
> Key: CXF-2252
> URL: https://issues.apache.org/jira/browse/CXF-2252
> Project: CXF
> Issue Type: New Feature
> Components: Distributed-OSGi
> Affects Versions: dOSGi-1.0
> Reporter: Josh Holtzman
> Fix For: dOSGi-1.2
>
> Attachments: dosgi_jaxws.diff, dosgi_jaxws_jaxrs.diff
>
>
> Individual service registrations should be able to choose whether to utilize the Aegis
or JAX-WS databindings for distributed OSGi. The Aegis databinding, however, should remain
the default. See the discussion at http://www.nabble.com/Configuring-DOSGI-to-use-JAX-WS-td23487668.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-2352:
-----------------------------
Fix Version/s: (was: dOSGi-1.1)
dOSGi-1.2
> dOSGi creates new databinding instance instead of using a spring-loaded databinding if
available
> ------------------------------------------------------------------------------------------------
>
> Key: CXF-2352
> URL: https://issues.apache.org/jira/browse/CXF-2352
> Project: CXF
> Issue Type: Bug
> Components: Distributed-OSGi
> Affects Versions: dOSGi-1.1
> Reporter: Ahmed Aadel
> Fix For: dOSGi-1.2
>
>
> It seems dOSGI doesn't look for the user spring-configured data binding instance but
instead creates and uses a new one, leading to a faulty context with default properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-2452:
-----------------------------
Fix Version/s: (was: dOSGi-1.1)
dOSGi-1.2
> DOSGI CXF Distributed Software Bundle (1.1.0.SNAPSHOT) fails on startup
> -----------------------------------------------------------------------
>
> Key: CXF-2452
> URL: https://issues.apache.org/jira/browse/CXF-2452
> Project: CXF
> Issue Type: Bug
> Components: Distributed-OSGi
> Affects Versions: dOSGi-1.1
> Environment: adz20:~ azeckoski$ java -version
> java version "1.6.0_15"
> Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226)
> Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode)
> Reporter: Aaron Zeckoski
> Priority: Critical
> Fix For: dOSGi-1.2
>
>
> One of the DOSGI bundles is failing to startup using Felix 2.0 as the container
> cxf-dosgi-ri-dsw-cxf (1.1.0.SNAPSHOT)
> The exception and ps info from felix will be added in comments
> Here is the log of the attempt to startup and the exception at the end:
> http://pastebin.com/m4da7142
> Some tracing shows that this seems to fail when felix tries to load the org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean
class and is unable to load the javax.ws.rs.WebApplicationException class. The constructor
called here is never actually reached.
> JAXRSServerFactoryBean factory = new JAXRSServerFactoryBean();
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-2560.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Sergey Beryozkin
> WebClient doesns't read response body if status code means some error
> ---------------------------------------------------------------------
>
> Key: CXF-2560
> URL: https://issues.apache.org/jira/browse/CXF-2560
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.2.5
> Reporter: Roman Kalukiewicz
> Assignee: Sergey Beryozkin
> Fix For: 2.3
>
>
> In {{org.apache.cxf.jaxrs.client.AbstractClient.readBody(Response, HttpURLConnection,
Message, Class<?>, Type, Annotation[])}} there is a conddition that causes {{WebClient}}
not to read the content of the response if status code describes some kind of error.
> I believe that if some response is sent by the server I should be able to read it even
if the status is for example 404.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-2268.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Sergey Beryozkin
Documentation to follow
> Collapse Atom Feed and Entry providers and support Atom reflectively
> --------------------------------------------------------------------
>
> Key: CXF-2268
> URL: https://issues.apache.org/jira/browse/CXF-2268
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 2.3
> Reporter: Sergey Beryozkin
> Assignee: Sergey Beryozkin
> Priority: Minor
> Fix For: 2.3
>
>
> it should be possible to serialize a given wrapper collection like customers without
users haveing to explicitly deal with Abdera, for example :
> @Path("/")
> public class SomeService {
> @GET
> @Produces("application/atom+feed")
> public Customers getCustomers() {}
> }
> public class Customers {
> private List<Customer> customers;
> }
> Atom provider would introspect Customers for top level feed properties and every Customer
for individual entry properties. It would check for well known properties, like getId(), etc,
and will default to some reasonable values when needed. Atom provider should also accept class-specific
out-of-band atom properties (beans) which can customize the serialization as needed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2572.
------------------------------
Resolution: Fixed
Fix Version/s: 2.2.6
Assignee: Daniel Kulp
> WS-Addressing interceptors throw NPE when processing JAX-WS @WebServiceProvider requests
in MESSAGE mode
> --------------------------------------------------------------------------------------------------------
>
> Key: CXF-2572
> URL: https://issues.apache.org/jira/browse/CXF-2572
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime, WS-* Components
> Affects Versions: 2.2.4, 2.2.5, 2.3
> Environment: WinXP32, Sun JDK 1.6.0_16
> Reporter: Alexandros Karypidis
> Assignee: Daniel Kulp
> Fix For: 2.2.6
>
> Attachments: cxf-systests-ws-specs_Addressing-MMode-JAX-WS.patch
>
>
> When publishing a service using JAX-WS and the @WebServiceProvider using the MESSAGE
mode (i.e. access to full SOAP envelope), the WS-Addressing interceptors throw an NPE.
> Problem was first-reported here:
> http://thread.gmane.org/gmane.comp.apache.cxf.user/4153
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2553.
------------------------------
Resolution: Fixed
Fix Version/s: 2.2.6
Assignee: Daniel Kulp
Thanks!
Just had to fix a single checkstyle error and a line break in the readme. Thanks a bunch!
> WS-Security UsernameToken sample using WS-SecurityPolicy
> --------------------------------------------------------
>
> Key: CXF-2553
> URL: https://issues.apache.org/jira/browse/CXF-2553
> Project: CXF
> Issue Type: Improvement
> Affects Versions: 2.2
> Reporter: Oliver Wulff
> Assignee: Daniel Kulp
> Priority: Minor
> Fix For: 2.2.6
>
> Attachments: ut_policy.zip
>
>
> I'd like to submit this demo which combines https and usernametoken based on WS-SecurityPolicy
configuration.
> The attached demo is an extension of the ws-sec demo ut. I took the demo wsdl_first_https
as the base for https and configured UsernameToken enforcement with WS-SecurityPolicy.
> We configure the CXF version like this:
> <properties>
> <cxf.version>[2,)</cxf.version>
> </properties>
> Is this really intended that when I download CXF 2.2.4 and run the demo with maven, the
more recent CXF version (2.2.5) is used?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Exception when Remoting Service with Single-Bundle Distro w/o Discovery Server
------------------------------------------------------------------------------
Key: CXF-2573
URL: https://issues.apache.org/jira/browse/CXF-2573
Project: CXF
Issue Type: Bug
Components: Distributed-OSGi
Affects Versions: dOSGi-1.1
Reporter: David Bosschaert
Priority: Minor
When using the Single Bundle Distribution you may get the following exception when remoting
a service:
SEVERE: Exception while processing the addition of a ServicePublication.
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss
at org.apache.zookeeper.KeeperException.create(KeeperException.java:59)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:593)
at org.apache.zookeeper.ZooKeeper.exists(ZooKeeper.java:620)
at org.apache.cxf.dosgi.discovery.zookeeper.PublishToZooKeeperCustomizer.ensurePath(PublishToZooKeeperCustomizer.java:112)
at org.apache.cxf.dosgi.discovery.zookeeper.PublishToZooKeeperCustomizer.addingService(PublishToZooKeeperCustomizer.java:68)
at org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1021)
at org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:999)
at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:924)
at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:124)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:930)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:149)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:757)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:712)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:129)
at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:506)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:524)
at org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.publish(ServiceHookUtils.java:55)
at org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:82)
at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
This happens when you don't have a Zookeeper Discovery Server running.
The exception is harmless and everything still works but it should be changed into an INFO
log message as running without Discovery is a perfectly valid use case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
WS-Addressing interceptors throw NPE when processing JAX-WS @WebServiceProvider requests in
MESSAGE mode
--------------------------------------------------------------------------------------------------------
Key: CXF-2572
URL: https://issues.apache.org/jira/browse/CXF-2572
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime, WS-* Components
Affects Versions: 2.2.5, 2.2.4, 2.3
Environment: WinXP32, Sun JDK 1.6.0_16
Reporter: Alexandros Karypidis
When publishing a service using JAX-WS and the @WebServiceProvider using the MESSAGE mode
(i.e. access to full SOAP envelope), the WS-Addressing interceptors throw an NPE.
Problem was first-reported here:
http://thread.gmane.org/gmane.comp.apache.cxf.user/4153
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785799#action_12785799
]
Christian Connert commented on CXF-2570:
----------------------------------------
O.k,
I'm trying to descripe the problem in detail:
first I've some wsdl with the following soap location:
<soap:address location="http://192.168.130.7:8080/BasicBusinessServices/services/OrderService"
/>
It's also used by clients to know the location of the service endpoint.
The ServletTransportFactory only removes the prefixs http://localhost/ and https://localhost/,
thus in my case no prefixes are removed and the services are stored by the full path in the
destinations map.
When invoking the service the ServletController uses the following line in the invoke method
(line 131):
String address = request.getPathInfo() == null ? "" : request.getPathInfo();
For my sample this call returns "/OrderService", but since the ServletTransportFactory destinations
map uses the full path as key (http://192.168.130.7:8080/BasicBusinessServices/services/OrderService)
the ServletController calls ServletDestination d = getDestination(ei.getAddress()); (line
135) but this returns null and the call ends in the following code (line 153 - 157) of the
ServletController:
if (d == null || d.getMessageObserver() == null) {
LOG.warning("Can't find the request for "
+ request.getRequestURL() + "'s Observer ");
generateNotFound(request, res);
}
> ServletDestinationFacotry and Tomcat can't locate services
> ----------------------------------------------------------
>
> Key: CXF-2570
> URL: https://issues.apache.org/jira/browse/CXF-2570
> Project: CXF
> Issue Type: Bug
> Environment:
> « Hide
> System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> Java:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Apache CXF 2.2.3 (not in version list)
> Reporter: Christian Connert
> Attachments: cxf.xml, TomcatDestinationFactory.java
>
>
> The problem is that the service destinations aren't found by the destination factory.
> I think this problem isn't Tomcat specific. It should occur if cxf is deployed as a war
inside some application server.
> I would suggest the following workaround:
> 1.) Implement a ServletTransportFactory (see attachment 1)
> 2.) Register this ServletTransportFactory in the default cxf.xml (classpath root, see
attachment 2)
> As a clean fix the ServletTransportFactory should make the static String getTrimmedPath(String
path) method to a protected non static method. Than it can be easily overriden by custom subclasses.
> Greetings
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785451#action_12785451
]
Daniel Kulp commented on CXF-2570:
----------------------------------
I'm trying to figure out exactly what the problem is. What problem are you seeing that is
requiring this?
Basically, I'd rather fix the ServletTransportFactory (or the CXFServlet) if something is
needed there, but I really kind of need to know what the problem is. Do you have a testcase
or something that shows the problem?
> ServletDestinationFacotry and Tomcat can't locate services
> ----------------------------------------------------------
>
> Key: CXF-2570
> URL: https://issues.apache.org/jira/browse/CXF-2570
> Project: CXF
> Issue Type: Bug
> Environment:
> « Hide
> System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> Java:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Apache CXF 2.2.3 (not in version list)
> Reporter: Christian Connert
> Attachments: cxf.xml, TomcatDestinationFactory.java
>
>
> The problem is that the service destinations aren't found by the destination factory.
> I think this problem isn't Tomcat specific. It should occur if cxf is deployed as a war
inside some application server.
> I would suggest the following workaround:
> 1.) Implement a ServletTransportFactory (see attachment 1)
> 2.) Register this ServletTransportFactory in the default cxf.xml (classpath root, see
attachment 2)
> As a clean fix the ServletTransportFactory should make the static String getTrimmedPath(String
path) method to a protected non static method. Than it can be easily overriden by custom subclasses.
> Greetings
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Not sure if this is the correct forum or the correct format.
In CXF 2.2.4 with a JMS bases service we are getting the following
exception when the web application starts up in WebLogic 10.3.
This only seems to happen when we set the "reconnectOnException"
property of the JMSConfiguration to true:
http://cwiki.apache.org/CXF20DOC/using-the-jmsconfigfeature.html
Please let me know what additional information I can provide or any
ideas on what I can do to fix this issue or if it is a configuration
error on my side.
Caused by: org.springframework.jms.UncategorizedJmsException:
Uncategorized exception occured during JMS processing; nested exception
is javax.jms.JMSException: [JMSPool:169801]The JMS method
setExceptionListener may not be called inside an EJB or servlet
at
org.springframework.jms.support.JmsUtils.convertJmsAccessException(JmsUt
ils.java:308)
at
org.springframework.jms.support.JmsAccessor.convertJmsAccessException(Jm
sAccessor.java:168)
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:474)
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:436)
at
org.apache.cxf.transport.jms.JMSFactory.resolveOrCreateDestination(JMSFa
ctory.java:260)
at
org.apache.cxf.transport.jms.JMSFactory.createJmsListener(JMSFactory.jav
a:240)
at
org.apache.cxf.transport.jms.JMSFactory.createJmsListener(JMSFactory.jav
a:146)
at
org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java
:111)
at
org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractO
bservable.java:48)
at
org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindin
gFactory.java:164)
at
org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFa
ctory.java:766)
at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:122)
at
org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:271)
... 61 more
Caused by: javax.jms.JMSException: [JMSPool:169801]The JMS method
setExceptionListener may not be called inside an EJB or servlet
at
weblogic.deployment.jms.JMSExceptions.getJMSException(JMSExceptions.java
:22)
at
weblogic.deployment.jms.PooledConnection.setExceptionListener(PooledConn
ection.java:180)
at
org.springframework.jms.connection.SingleConnectionFactory.prepareConnec
tion(SingleConnectionFactory.java:365)
at
org.springframework.jms.connection.SingleConnectionFactory.initConnectio
n(SingleConnectionFactory.java:291)
at
org.springframework.jms.connection.SingleConnectionFactory.createConnect
ion(SingleConnectionFactory.java:227)
at
org.springframework.jms.support.JmsAccessor.createConnection(JmsAccessor
.java:184)
at
org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:461)
... 71 more
Thanks,
Erich
---------------------------------------------------------------------------------------------------------
This e-mail message may contain privileged and/or confidential information, and is intended
to be received only by persons entitled to receive such information. If you have received
this e-mail in error, please notify the sender immediately. Please delete it and all attachments
from any servers, hard drives or any other media. Other use of this e-mail by you is strictly
prohibited.
All e-mails and attachments sent and received are subject to monitoring, reading and archival
by Monsanto, including its subsidiaries. The recipient of this e-mail is solely responsible
for checking for the presence of "Viruses" or other "Malware". Monsanto, along with its subsidiaries,
accepts no liability for any damage caused by any such code transmitted by or accompanying
this e-mail or any attachment.
---------------------------------------------------------------------------------------------------------
[ https://issues.apache.org/jira/browse/CXF-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
HÃ¥kan Dahl updated CXF-2571:
----------------------------
Attachment: jax-ws-catalog-test-20091203.zip
Attached test-projects.
To reproduce problem, run the following in the root-project:
mvn -e clean install
> wsdl2java and jax-ws-catalog: failing to resolve schemas included with xsd:include in
jar-file
> ----------------------------------------------------------------------------------------------
>
> Key: CXF-2571
> URL: https://issues.apache.org/jira/browse/CXF-2571
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.1.8, 2.2.5
> Environment: Apache Maven 2.2.1
> Java version: 1.5.0_21
> OS name: "windows xp"
> Reporter: HÃ¥kan Dahl
> Attachments: jax-ws-catalog-test-20091203.zip
>
>
> cxf-codegen-plugin/wsdl2java (2.1.8, 2.2.5)
> Refer user-list thread:
> http://old.nabble.com/jax-ws-catalog-and-resolving-schemas-in-jars-that-do-xsd%3Ainclude-td26590812.html
> Schema resolution from a jar-file (using jax-ws-catalog as per 4.4 Catalog Facility in
the JAX-WS 2.1 spec) fails when:
> * The referenced schema in a jar makes xsd:include on another schema in the
> jar (all schemas in a jar share the same namespace).
> Stacktrace below for CXF 2.1.8 below. CXF 2.2.5 also fails but with a NullPointerException.
> Note: xsd:import works but requires imported schema to be in another
> namespace.
> Projects look like:
> common-types-domain1
> META-INF/jax-ws-catalog.xml
> schemas/domain1/domain1-schema1.xsd
> schemas/domain1/domain1-schema2.xsd
> wsdl-project-1
> src\main\resources\schemas\GetX.xsd
> src\main\resources\schemas\GetXService.wsdl
> where the GetXService.wsdl imports GetX.xsd which imports
> domain1-schema2.xsd like this:
> GetX.xsd:
> <xsd:import namespace="http://www.example.org/schemas/domain1"
> schemaLocation="
> http://www.example.org/schemas/domain1/domain1-schema2.xsd"/>
> domain1-schema2.xsd:
> <xsd:include schemaLocation="domain1-schema1.xsd"/>
> common-types-domain1/META-INF/jax-ws-catalog.xml:
> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
> prefer="system">
> <system systemId="
> http://www.example.org/schemas/domain1/domain1-schema1.xsd"
> uri="classpath:schemas/domain1/domain1-schema1.xsd"/>
> <system systemId="
> http://www.example.org/schemas/domain1/domain1-schema2.xsd"
> uri="classpath:schemas/domain1/domain1-schema2.xsd"/>
> </catalog>
> results in:
> Caused by: org.apache.cxf.tools.common.ToolException: Thrown by JAXB :
> http://www.example.org/schemas/domain1/domain1-schema1.xsd
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:34)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:285)
> at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:90)
> at
> com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:402)
> at
> com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:301)
> at
> com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
> at
> org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:240)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:277)
> at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:246)
> at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:123)
> at
> com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:135)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addSchemas(JAXBDataBinding.java:253)
> at
> org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:196)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:588)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:239)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:130)
> at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:283)
> at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
> at
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:337)
> ... 20 more
> Caused by: java.io.FileNotFoundException:
> http://www.example.org/schemas/domain1/domain1-schema1.xsd
> ... 39 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
wsdl2java and jax-ws-catalog: failing to resolve schemas included with xsd:include in jar-file
----------------------------------------------------------------------------------------------
Key: CXF-2571
URL: https://issues.apache.org/jira/browse/CXF-2571
Project: CXF
Issue Type: Bug
Affects Versions: 2.2.5, 2.1.8
Environment: Apache Maven 2.2.1
Java version: 1.5.0_21
OS name: "windows xp"
Reporter: HÃ¥kan Dahl
cxf-codegen-plugin/wsdl2java (2.1.8, 2.2.5)
Refer user-list thread:
http://old.nabble.com/jax-ws-catalog-and-resolving-schemas-in-jars-that-do-xsd%3Ainclude-td26590812.html
Schema resolution from a jar-file (using jax-ws-catalog as per 4.4 Catalog Facility in the
JAX-WS 2.1 spec) fails when:
* The referenced schema in a jar makes xsd:include on another schema in the
jar (all schemas in a jar share the same namespace).
Stacktrace below for CXF 2.1.8 below. CXF 2.2.5 also fails but with a NullPointerException.
Note: xsd:import works but requires imported schema to be in another
namespace.
Projects look like:
common-types-domain1
META-INF/jax-ws-catalog.xml
schemas/domain1/domain1-schema1.xsd
schemas/domain1/domain1-schema2.xsd
wsdl-project-1
src\main\resources\schemas\GetX.xsd
src\main\resources\schemas\GetXService.wsdl
where the GetXService.wsdl imports GetX.xsd which imports
domain1-schema2.xsd like this:
GetX.xsd:
<xsd:import namespace="http://www.example.org/schemas/domain1"
schemaLocation="
http://www.example.org/schemas/domain1/domain1-schema2.xsd"/>
domain1-schema2.xsd:
<xsd:include schemaLocation="domain1-schema1.xsd"/>
common-types-domain1/META-INF/jax-ws-catalog.xml:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="system">
<system systemId="
http://www.example.org/schemas/domain1/domain1-schema1.xsd"
uri="classpath:schemas/domain1/domain1-schema1.xsd"/>
<system systemId="
http://www.example.org/schemas/domain1/domain1-schema2.xsd"
uri="classpath:schemas/domain1/domain1-schema2.xsd"/>
</catalog>
results in:
Caused by: org.apache.cxf.tools.common.ToolException: Thrown by JAXB :
http://www.example.org/schemas/domain1/domain1-schema1.xsd
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBBindErrorListener.error(JAXBBindErrorListener.java:34)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.error(SchemaCompilerImpl.java:285)
at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:90)
at
com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:402)
at
com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:301)
at
com.sun.tools.xjc.reader.internalizer.AbstractReferenceFinderImpl.startElement(AbstractReferenceFinderImpl.java:95)
at
org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:240)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:277)
at com.sun.xml.bind.unmarshaller.DOMScanner.visit(DOMScanner.java:246)
at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMScanner.java:123)
at
com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.parseSchema(SchemaCompilerImpl.java:135)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.addSchemas(JAXBDataBinding.java:253)
at
org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:196)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:588)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:239)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:130)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:283)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:337)
... 20 more
Caused by: java.io.FileNotFoundException:
http://www.example.org/schemas/domain1/domain1-schema1.xsd
... 39 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Connert updated CXF-2570:
-----------------------------------
Attachment: cxf.xml
TomcatDestinationFactory.java
> ServletDestinationFacotry and Tomcat can't locate services
> ----------------------------------------------------------
>
> Key: CXF-2570
> URL: https://issues.apache.org/jira/browse/CXF-2570
> Project: CXF
> Issue Type: Bug
> Environment:
> « Hide
> System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> Java:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Apache CXF 2.2.3 (not in version list)
> Reporter: Christian Connert
> Attachments: cxf.xml, TomcatDestinationFactory.java
>
>
> The problem is that the service destinations aren't found by the destination factory.
> I think this problem isn't Tomcat specific. It should occur if cxf is deployed as a war
inside some application server.
> I would suggest the following workaround:
> 1.) Implement a ServletTransportFactory (see attachment 1)
> 2.) Register this ServletTransportFactory in the default cxf.xml (classpath root, see
attachment 2)
> As a clean fix the ServletTransportFactory should make the static String getTrimmedPath(String
path) method to a protected non static method. Than it can be easily overriden by custom subclasses.
> Greetings
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
ServletDestinationFacotry and Tomcat can't locate services
----------------------------------------------------------
Key: CXF-2570
URL: https://issues.apache.org/jira/browse/CXF-2570
Project: CXF
Issue Type: Bug
Environment:
« Hide
System:
2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
Java:
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
Apache CXF 2.2.3 (not in version list)
Reporter: Christian Connert
The problem is that the service destinations aren't found by the destination factory.
I think this problem isn't Tomcat specific. It should occur if cxf is deployed as a war inside
some application server.
I would suggest the following workaround:
1.) Implement a ServletTransportFactory (see attachment 1)
2.) Register this ServletTransportFactory in the default cxf.xml (classpath root, see attachment
2)
As a clean fix the ServletTransportFactory should make the static String getTrimmedPath(String
path) method to a protected non static method. Than it can be easily overriden by custom subclasses.
Greetings
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Consuming a wsdl file which is having a nested complex types in xsd
-------------------------------------------------------------------
Key: CXF-2569
URL: https://issues.apache.org/jira/browse/CXF-2569
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Environment: jdk 1.5 ,windows xp,IBM websphere server
Reporter: vijay valeti
Priority: Blocker
When we are trying to consume a wsdl file which is having a nested complex type xsd element
we are getting an exception
IllegalArgumentException:Wrong Number of Arguments provided
when ever you have a nested complex type in xsd,in the ObjectFactory.java class will be having
two create methods for the nested element.i feel cxf is not implemented properly to handle
this kind of situation . i believe that cxf developers/community assuemd that there wont be
any overloaded create methods in the OBjectFactory.java class
sample XSD
<xsd:complexType>
<xsd:sequence>
<xsd:element>
<xsd:complexType name="testList">
<xsd:sequence>
<xsd:element name="test" type="xsd:string" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:element>
<xsd:element name="name" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies resolved CXF-2568.
-----------------------------------
Resolution: Fixed
Fix checked in. Fix could be more comprehensively tested.
> default values don't get quoted properly in generated Javascript
> ----------------------------------------------------------------
>
> Key: CXF-2568
> URL: https://issues.apache.org/jira/browse/CXF-2568
> Project: CXF
> Issue Type: Bug
> Components: JavaScript Client
> Affects Versions: 2.2.4, 2.1.8, 2.2.5
> Reporter: Benson Margulies
> Fix For: 2.3
>
>
> The schema stored all default values as strings. If they are really string values, they
need to be quoted in Javascript. They are not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
default values don't get quoted properly in generated Javascript
----------------------------------------------------------------
Key: CXF-2568
URL: https://issues.apache.org/jira/browse/CXF-2568
Project: CXF
Issue Type: Bug
Components: JavaScript Client
Affects Versions: 2.2.5, 2.1.8, 2.2.4
Reporter: Benson Margulies
Fix For: 2.3
The schema stored all default values as strings. If they are really string values, they need
to be quoted in Javascript. They are not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784122#action_12784122
]
Kees de Kooter commented on CXF-2559:
-------------------------------------
Unfortunately the webservice will not be fixed anytime soon. Is there a way to work around
this?
> Soap11FaultInInterceptor.unmarshalFault for valid SOAP message
> --------------------------------------------------------------
>
> Key: CXF-2559
> URL: https://issues.apache.org/jira/browse/CXF-2559
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.2.5
> Reporter: Kees de Kooter
>
> I call a webservice which returns the following (fault) message:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <SOAP-ENV:Body>
> <SOAP-ENV:Fault>
> <faultstring>engine::exception: Can't call method "namespaceURI" on an undefined
value at /var/www/html/XXXXX/package/engine/xml_utils.pm line 272.
> </faultstring>
> <faultcode/>
> <stacktrace>Session:eurogroup_ajCqNqED3rZakVOh, Time:2009-11-25 19:43:14,
Version:2.0.76-370, Username:pharos
> /var/www/html/XXXXX/package/engine/exception.pm (53)
> - /var/www/html/XXXXX/package/engine/instanciable.pm(22):engine::exception::create
> - /var/www/html/XXXXX/package/engine/exception.pm(159):engine::instanciable::new
> - /var/www/html/XXXXX/package/engine.pm(788):engine::exception::getExceptionFromError
> - /var/www/html/XXXXX/package/engine.pm(786):(eval)
> - /var/www/html/XXXXX/cgi/rsoapserver.cgi(18):engine::end
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(204):ModPerl::ROOT::ModPerl::Registry::var_www_html_XXXXX_cgi_rsoapserver_2ecgi::handler
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(204):(eval)
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(170):ModPerl::RegistryCooker::run
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/Registry.pm(31):ModPerl::RegistryCooker::default_handler
> - -e(0):ModPerl::Registry::handler
> - -e(0):(eval)
> </stacktrace>
> </SOAP-ENV:Fault>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
> {code}
> The message contains valid xml as far a I can tell. Still the following exception is
thrown:
> {noformat}
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS
or CDATA event in nextTag().
> at [row,col {unknown-source}]: [21,0]
> at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:580)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:453)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:438)
> at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1141)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:57)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:671)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2205)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2084)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1982)
> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:637)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 25 more
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784117#action_12784117
]
Kees de Kooter commented on CXF-2559:
-------------------------------------
Thanks Daniel. I will try to persuade the owner of the server to adjust their service accordingly.
> Soap11FaultInInterceptor.unmarshalFault for valid SOAP message
> --------------------------------------------------------------
>
> Key: CXF-2559
> URL: https://issues.apache.org/jira/browse/CXF-2559
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.2.5
> Reporter: Kees de Kooter
>
> I call a webservice which returns the following (fault) message:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <SOAP-ENV:Body>
> <SOAP-ENV:Fault>
> <faultstring>engine::exception: Can't call method "namespaceURI" on an undefined
value at /var/www/html/XXXXX/package/engine/xml_utils.pm line 272.
> </faultstring>
> <faultcode/>
> <stacktrace>Session:eurogroup_ajCqNqED3rZakVOh, Time:2009-11-25 19:43:14,
Version:2.0.76-370, Username:pharos
> /var/www/html/XXXXX/package/engine/exception.pm (53)
> - /var/www/html/XXXXX/package/engine/instanciable.pm(22):engine::exception::create
> - /var/www/html/XXXXX/package/engine/exception.pm(159):engine::instanciable::new
> - /var/www/html/XXXXX/package/engine.pm(788):engine::exception::getExceptionFromError
> - /var/www/html/XXXXX/package/engine.pm(786):(eval)
> - /var/www/html/XXXXX/cgi/rsoapserver.cgi(18):engine::end
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(204):ModPerl::ROOT::ModPerl::Registry::var_www_html_XXXXX_cgi_rsoapserver_2ecgi::handler
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(204):(eval)
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(170):ModPerl::RegistryCooker::run
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/Registry.pm(31):ModPerl::RegistryCooker::default_handler
> - -e(0):ModPerl::Registry::handler
> - -e(0):(eval)
> </stacktrace>
> </SOAP-ENV:Fault>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
> {code}
> The message contains valid xml as far a I can tell. Still the following exception is
thrown:
> {noformat}
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS
or CDATA event in nextTag().
> at [row,col {unknown-source}]: [21,0]
> at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:580)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:453)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:438)
> at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1141)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:57)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:671)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2205)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2084)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1982)
> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:637)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 25 more
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stevo Slavic reopened CXF-2563:
-------------------------------
Please look from CXF users perspective, there are numerous issues caused by this unneeded
repository definition, e.g. while building a project with dependency to cxf-rt-ws-security,
maven and its various core plugins pickup all the repository definitions from the project
but also from its dependencies (including transitive ones) to lookup dependencies, so maven
will waste time looking up snapshots at apache.snapshots repository and build will last longer.
> CXF RT WS Security artifact POM at maven central repo wrongfuly contains reference to
external repository
> ---------------------------------------------------------------------------------------------------------
>
> Key: CXF-2563
> URL: https://issues.apache.org/jira/browse/CXF-2563
> Project: CXF
> Issue Type: Bug
> Components: Build system
> Affects Versions: 2.2.5
> Reporter: Stevo Slavic
> Fix For: Invalid
>
>
> [cxf-rt-ws-security-2.2.5.pom|http://repo2.maven.org/maven2/org/apache/cxf/cxf-rt-ws-security/2.2.5/cxf-rt-ws-security-2.2.5.pom]
contains reference to external (non maven central) repository, so it does not adhere to the
rules for deploying artifacts to maven central repository (see "FAQ and common mistakes" in
official ["Guide to uploading artifacts to the Central Repository"|http://maven.apache.org/guides/mini/guide-central-repository-upload.html]).
Please check other CXF modules too for the same error, before deploying to maven central.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784091#action_12784091
]
Stevo Slavic commented on CXF-2565:
-----------------------------------
This is it, thanks, issue can be closed.
> Enable wiki renderer for CXF
> ----------------------------
>
> Key: CXF-2565
> URL: https://issues.apache.org/jira/browse/CXF-2565
> Project: CXF
> Issue Type: Improvement
> Reporter: Stevo Slavic
> Assignee: Daniel Kulp
> Fix For: Invalid
>
>
> Please enable wiki renderer for CXF JIRA project. This renderer would allow users to
create better readable issues. See following JIRA doc for more details on the feature: http://confluence.atlassian.com/display/JIRA/Configuring+Rich-Text+Renderers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784041#action_12784041
]
Daniel Kulp commented on CXF-2559:
----------------------------------
That isn't a valid soap fault message. The stacktrace element would need to be placed in
a details element.
Also, the faultcode element cannot be empty. Per the soap 1.1 spec:
The faultcode MUST be present in a SOAP Fault element and the faultcode value MUST be a qualified
name
Thus, the soap fault message is invalid.
> Soap11FaultInInterceptor.unmarshalFault for valid SOAP message
> --------------------------------------------------------------
>
> Key: CXF-2559
> URL: https://issues.apache.org/jira/browse/CXF-2559
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding
> Affects Versions: 2.2.5
> Reporter: Kees de Kooter
>
> I call a webservice which returns the following (fault) message:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <SOAP-ENV:Body>
> <SOAP-ENV:Fault>
> <faultstring>engine::exception: Can't call method "namespaceURI" on an undefined
value at /var/www/html/XXXXX/package/engine/xml_utils.pm line 272.
> </faultstring>
> <faultcode/>
> <stacktrace>Session:eurogroup_ajCqNqED3rZakVOh, Time:2009-11-25 19:43:14,
Version:2.0.76-370, Username:pharos
> /var/www/html/XXXXX/package/engine/exception.pm (53)
> - /var/www/html/XXXXX/package/engine/instanciable.pm(22):engine::exception::create
> - /var/www/html/XXXXX/package/engine/exception.pm(159):engine::instanciable::new
> - /var/www/html/XXXXX/package/engine.pm(788):engine::exception::getExceptionFromError
> - /var/www/html/XXXXX/package/engine.pm(786):(eval)
> - /var/www/html/XXXXX/cgi/rsoapserver.cgi(18):engine::end
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(204):ModPerl::ROOT::ModPerl::Registry::var_www_html_XXXXX_cgi_rsoapserver_2ecgi::handler
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(204):(eval)
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/RegistryCooker.pm(170):ModPerl::RegistryCooker::run
> - /opt/rsl/usr/lib/perl5/vendor_perl/5.10.0/i686-linux-thread-multi/ModPerl/Registry.pm(31):ModPerl::RegistryCooker::default_handler
> - -e(0):ModPerl::Registry::handler
> - -e(0):(eval)
> </stacktrace>
> </SOAP-ENV:Fault>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
> {code}
> The message contains valid xml as far a I can tell. Still the following exception is
thrown:
> {noformat}
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS
or CDATA event in nextTag().
> at [row,col {unknown-source}]: [21,0]
> at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:580)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:453)
> at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:438)
> at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1141)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:57)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:46)
> at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:35)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
> at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:671)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2205)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2084)
> at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1982)
> at org.apache.cxf.io.CacheAndWriteOutputStream.postClose(CacheAndWriteOutputStream.java:47)
> at org.apache.cxf.io.CachedOutputStream.close(CachedOutputStream.java:188)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:637)
> at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:239)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:483)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:309)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:261)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> ... 25 more
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2563.
------------------------------
Resolution: Won't Fix
Fix Version/s: Invalid
It defines a snapshot only repository which is needed for testing various snapshot related
things. All non-snapshot deps are in central.
> CXF RT WS Security artifact POM at maven central repo wrongfuly contains reference to
external repository
> ---------------------------------------------------------------------------------------------------------
>
> Key: CXF-2563
> URL: https://issues.apache.org/jira/browse/CXF-2563
> Project: CXF
> Issue Type: Bug
> Components: Build system
> Affects Versions: 2.2.5
> Reporter: Stevo Slavic
> Fix For: Invalid
>
>
> [cxf-rt-ws-security-2.2.5.pom|http://repo2.maven.org/maven2/org/apache/cxf/cxf-rt-ws-security/2.2.5/cxf-rt-ws-security-2.2.5.pom]
contains reference to external (non maven central) repository, so it does not adhere to the
rules for deploying artifacts to maven central repository (see "FAQ and common mistakes" in
official ["Guide to uploading artifacts to the Central Repository"|http://maven.apache.org/guides/mini/guide-central-repository-upload.html]).
Please check other CXF modules too for the same error, before deploying to maven central.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784037#action_12784037
]
Daniel Kulp commented on CXF-2565:
----------------------------------
* test
* test
> Enable wiki renderer for CXF
> ----------------------------
>
> Key: CXF-2565
> URL: https://issues.apache.org/jira/browse/CXF-2565
> Project: CXF
> Issue Type: Improvement
> Reporter: Stevo Slavic
> Fix For: Invalid
>
>
> Please enable wiki renderer for CXF JIRA project. This renderer would allow users to
create better readable issues. See following JIRA doc for more details on the feature: http://confluence.atlassian.com/display/JIRA/Configuring+Rich-Text+Renderers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2565.
------------------------------
Resolution: Fixed
Fix Version/s: Invalid
Assignee: Daniel Kulp
Looks like I've managed to enable it. Please give it a try to make sure.
> Enable wiki renderer for CXF
> ----------------------------
>
> Key: CXF-2565
> URL: https://issues.apache.org/jira/browse/CXF-2565
> Project: CXF
> Issue Type: Improvement
> Reporter: Stevo Slavic
> Assignee: Daniel Kulp
> Fix For: Invalid
>
>
> Please enable wiki renderer for CXF JIRA project. This renderer would allow users to
create better readable issues. See following JIRA doc for more details on the feature: http://confluence.atlassian.com/display/JIRA/Configuring+Rich-Text+Renderers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
javac calling problem when creating client in DynamicClientFactory
------------------------------------------------------------------
Key: CXF-2567
URL: https://issues.apache.org/jira/browse/CXF-2567
Project: CXF
Issue Type: Improvement
Environment: linux
Reporter: Wilson Lam
Priority: Minor
When there are multiple JDK on a machine, DynamicClientFactory is currently not supported
to switch javac executable since CXF always call default javac.
The problem comes from compileJavaSrc:
Class - org.apache.cxf.endpoint.dynamic.DynamicClientFactory
Method - compileJavaSrc()
[ Code segment ]
...
javacCommand[0] = "javac";
javacCommand[1] = "-classpath";
javacCommand[2] = classPath;
javacCommand[3] = "-d";
javacCommand[4] = dest;
javacCommand[5] = "-target";
javacCommand[6] = "1.5";
...
return javaCompiler.internalCompile(javacCommand, 7);
There is no mechanism in Complier.internalCompile() to detect JAVA_HOME and execute the desired
javac command. Another Complier method "compileFiles()" is better in this way:
Class - org.apache.cxf.common.util.Complier
Method - compileFiles()
[ Code segment ]
...
if (new File(System.getProperty("java.home") + fsep + platformjavacname).exists())
{
// check if java.home is jdk home
javacstr = System.getProperty("java.home") + fsep + platformjavacname;
} else if (new File(System.getProperty("java.home") + fsep + ".." + fsep + "bin" +
fsep
+ platformjavacname).exists()) {
// check if java.home is jre home
javacstr = System.getProperty("java.home") + fsep + ".." + fsep + "bin" + fsep
+ platformjavacname;
}
...
It is possible to add this JAVA_HOME checking in Complier.internalCompile() or DynamicClientFactory.
compileJavaSrc() ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/CXF-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cyrille Le Clerc updated CXF-2566:
----------------------------------
Attachment: CXF-2566.patch
Patch description :
* o.a.c.management.counters.CounterRepository : Add objectName vairable in the logger call
to enhance log message
* o.a.c.management.counters.CounterRepository : Add translation "INSTRUMENTATION_REGISTER_FAULT_MSG=Can't
register counter with object name {0}. {1}"
> Missing translation for INSTRUMENTATION_REGISTER_FAULT_MSG
> ----------------------------------------------------------
>
> Key: CXF-2566
> URL: https://issues.apache.org/jira/browse/CXF-2566
> Project: CXF
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2.5
> Reporter: Cyrille Le Clerc
> Priority: Minor
> Attachments: CXF-2566.patch
>
>
> Translation is missing for INSTRUMENTATION_REGISTER_FAULT_MSG in rt/management/src/main/java/org/apache/cxf/management/counters/Messages.properties
.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.