[jira] Closed: (CXF-2746) Wrong validation of Timestamp/Created value: always default TimeToLive is used (300 sec.)
[ https://issues.apache.org/jira/browse/CXF-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Khasanov closed CXF-2746. - Resolution: Invalid Fix Version/s: Invalid Sorry for disturbing, did not quite understand how it works. There may be "timeToLive" jaxws:property used. > Wrong validation of Timestamp/Created value: always default TimeToLive is > used (300 sec.) > - > > Key: CXF-2746 > URL: https://issues.apache.org/jira/browse/CXF-2746 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.2.7 >Reporter: Nikolay Khasanov > Fix For: Invalid > > > I can see two validations of Timestamp during executing > WSS4JInInterceptor.handleMessage() method. > First checks Timestamp/Expires value and looks good, but next one contains > errors: > When WSS4JInInterceptor.handleMessage() method calls > verifyTimestamp(timestamp, decodeTimeToLive(reqData))) second parameter is > always 300. I didn't found any places where ttl value is set for RequestData > - so default value eq 300 is always retured. > It is expected that ttl value will equal (Timestamp/Expires - > Timestamp/Created)/1000 > At the same time if Timestamp/Expires value is absent then message will never > expire. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2747) BeanCreationException wrapped as warning during cxf-codegen:wsdl2java
[ https://issues.apache.org/jira/browse/CXF-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinis Vicups resolved CXF-2747. Resolution: Not A Problem Fix Version/s: 2.3 I confirm, using cxf-codegen-plugin 2.3.0-SNAPSHOT eliminates the exception. > BeanCreationException wrapped as warning during cxf-codegen:wsdl2java > - > > Key: CXF-2747 > URL: https://issues.apache.org/jira/browse/CXF-2747 > Project: CXF > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows Vista > jdk1.6.0_07 >Reporter: Reinis Vicups >Priority: Minor > Fix For: 2.3 > > > My project starts and completes successfully but there is exception thrown > during build when wsdl2java gets called. I am not sure if this is wsdl2java > specific. I found this ticket which looks sortof similar to me: > http://brutus.apache.org/jira/browse/CXF-2630 > This is console output during build: > [INFO] [cxf-codegen:wsdl2java] > [DEBUG] Setting context classloader for plugin to: > /plugins/org.apache.cxf:cxf-codegen-plugin:2@48/thread:main (instance is: > ClassRealm[/plugins/org.apache.cxf:cxf-codegen-plugin:2@48/thread:main, > parent: ClassRealm[plexus.core, parent: null]]) > [DEBUG] Classpath: [file:blah/target/classes/, file:blah/target/classes/, > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxws/2.3.0-SNAPSHOT/cxf-rt-frontend-jaxws-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/xml-resolver/xml-resolver/1.2/xml-resolver-1.2.jar, > file:/C:/Users/rvicups/.m2/repository/asm/asm/2.2.3/asm-2.2.3.jar, > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-api/2.3.0-SNAPSHOT/cxf-api-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-common-utilities/2.3.0-SNAPSHOT/cxf-common-utilities-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/ws/commons/schema/XmlSchema/1.4.5/XmlSchema-1.4.5.jar, > > file:/C:/Users/rvicups/.m2/repository/org/codehaus/woodstox/woodstox-core-asl/4.0.7/woodstox-core-asl-4.0.7.jar, > > file:/C:/Users/rvicups/.m2/repository/org/codehaus/woodstox/stax2-api/3.0.1/stax2-api-3.0.1.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/neethi/neethi/2.0.4/neethi-2.0.4.jar, > file:/C:/Users/rvicups/.m2/repository/wsdl4j/wsdl4j/1.6.2/wsdl4j-1.6.2.jar, > file:/C:/Users/rvicups/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-common-schemas/2.3.0-SNAPSHOT/cxf-common-schemas-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-core/2.3.0-SNAPSHOT/cxf-rt-core-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.12/jaxb-impl-2.1.12.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/geronimo/specs/geronimo-javamail_1.4_spec/1.6/geronimo-javamail_1.4_spec-1.6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-bindings-soap/2.3.0-SNAPSHOT/cxf-rt-bindings-soap-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-tools-common/2.3.0-SNAPSHOT/cxf-tools-common-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-databinding-jaxb/2.3.0-SNAPSHOT/cxf-rt-databinding-jaxb-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/mina/mina-core/2.0.0-M6/mina-core-2.0.0-M6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/slf4j/slf4j-api/1.5.2/slf4j-api-1.5.2.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-bindings-xml/2.3.0-SNAPSHOT/cxf-rt-bindings-xml-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-frontend-simple/2.3.0-SNAPSHOT/cxf-rt-frontend-simple-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-ws-addr/2.3.0-SNAPSHOT/cxf-rt-ws-addr-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/2.3.0-SNAPSHOT/cxf-rt-frontend-jaxrs-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-core/2.5.6/spring-core-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/javax/ws/rs/jsr311-api/1.0/jsr311-api-1.0.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-transports-http/2.3.0-SNAPSHOT/cxf-rt-transports-http-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-web/2.5.6/spring-web-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-context/2.5.6/spring-context-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/aopalliance/aopalliance/1.0/aopa
[jira] Closed: (CXF-2690) Oneway MEP with fastInfoset without 'force' results in no compression
[ https://issues.apache.org/jira/browse/CXF-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinis Vicups closed CXF-2690. -- > Oneway MEP with fastInfoset without 'force' results in no compression > - > > Key: CXF-2690 > URL: https://issues.apache.org/jira/browse/CXF-2690 > Project: CXF > Issue Type: Bug > Components: OtherDatabindings, Transports >Affects Versions: 2.2.6 > Environment: Windows Vista > jdk1.6.0_07 >Reporter: Reinis Vicups >Assignee: Daniel Kulp > Fix For: Invalid > > > If a fastInfoset (accept=application/fastinfoset) @Oneway Message is sent to > the Server and 'force' option of the fastInfoset is not set to 'true', the > server would give 202 response and would use content-type: text/xml like this: > 15:04:33,000 DEBUG [main] cxf.transport.http.HTTPConduit (2132) - Header > fields: > null: [HTTP/1.1 202 Accepted] > Content-Length: [0] > Content-Type: [text/xml] > Server: [Jetty(6.1.21)] > I am not sure if this is the consequence of server answering with text/xml, > but as a result the client issues all of the following requests with text/xml > aswell instead of switching to application/fastinfoset. > Per definition fastinfoset works like this: > 1. client requests server with content-type:text/xml but indicates that it > (client) accept:application/fastinfoset; > 2. server responds with content-type:application/fastinfoset > 3. all the following requests from client to server will be with > content-type:application/fastinfoset > Additional info that might be relevant: > - I have tested with multiple messages (not just two) > - All messages were sent from the same instance of client and received by the > same instance of server (no new instances were created) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (CXF-2747) BeanCreationException wrapped as warning during cxf-codegen:wsdl2java
[ https://issues.apache.org/jira/browse/CXF-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinis Vicups closed CXF-2747. -- > BeanCreationException wrapped as warning during cxf-codegen:wsdl2java > - > > Key: CXF-2747 > URL: https://issues.apache.org/jira/browse/CXF-2747 > Project: CXF > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows Vista > jdk1.6.0_07 >Reporter: Reinis Vicups >Priority: Minor > Fix For: 2.3 > > > My project starts and completes successfully but there is exception thrown > during build when wsdl2java gets called. I am not sure if this is wsdl2java > specific. I found this ticket which looks sortof similar to me: > http://brutus.apache.org/jira/browse/CXF-2630 > This is console output during build: > [INFO] [cxf-codegen:wsdl2java] > [DEBUG] Setting context classloader for plugin to: > /plugins/org.apache.cxf:cxf-codegen-plugin:2@48/thread:main (instance is: > ClassRealm[/plugins/org.apache.cxf:cxf-codegen-plugin:2@48/thread:main, > parent: ClassRealm[plexus.core, parent: null]]) > [DEBUG] Classpath: [file:blah/target/classes/, file:blah/target/classes/, > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxws/2.3.0-SNAPSHOT/cxf-rt-frontend-jaxws-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/xml-resolver/xml-resolver/1.2/xml-resolver-1.2.jar, > file:/C:/Users/rvicups/.m2/repository/asm/asm/2.2.3/asm-2.2.3.jar, > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-api/2.3.0-SNAPSHOT/cxf-api-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-common-utilities/2.3.0-SNAPSHOT/cxf-common-utilities-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/ws/commons/schema/XmlSchema/1.4.5/XmlSchema-1.4.5.jar, > > file:/C:/Users/rvicups/.m2/repository/org/codehaus/woodstox/woodstox-core-asl/4.0.7/woodstox-core-asl-4.0.7.jar, > > file:/C:/Users/rvicups/.m2/repository/org/codehaus/woodstox/stax2-api/3.0.1/stax2-api-3.0.1.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/neethi/neethi/2.0.4/neethi-2.0.4.jar, > file:/C:/Users/rvicups/.m2/repository/wsdl4j/wsdl4j/1.6.2/wsdl4j-1.6.2.jar, > file:/C:/Users/rvicups/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-common-schemas/2.3.0-SNAPSHOT/cxf-common-schemas-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-core/2.3.0-SNAPSHOT/cxf-rt-core-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.12/jaxb-impl-2.1.12.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/geronimo/specs/geronimo-javamail_1.4_spec/1.6/geronimo-javamail_1.4_spec-1.6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-bindings-soap/2.3.0-SNAPSHOT/cxf-rt-bindings-soap-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-tools-common/2.3.0-SNAPSHOT/cxf-tools-common-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-databinding-jaxb/2.3.0-SNAPSHOT/cxf-rt-databinding-jaxb-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/mina/mina-core/2.0.0-M6/mina-core-2.0.0-M6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/slf4j/slf4j-api/1.5.2/slf4j-api-1.5.2.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-bindings-xml/2.3.0-SNAPSHOT/cxf-rt-bindings-xml-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-frontend-simple/2.3.0-SNAPSHOT/cxf-rt-frontend-simple-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-ws-addr/2.3.0-SNAPSHOT/cxf-rt-ws-addr-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-frontend-jaxrs/2.3.0-SNAPSHOT/cxf-rt-frontend-jaxrs-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-core/2.5.6/spring-core-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/javax/ws/rs/jsr311-api/1.0/jsr311-api-1.0.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-transports-http/2.3.0-SNAPSHOT/cxf-rt-transports-http-2.3.0-SNAPSHOT.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-web/2.5.6/spring-web-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-beans/2.5.6/spring-beans-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/org/springframework/spring-context/2.5.6/spring-context-2.5.6.jar, > > file:/C:/Users/rvicups/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar, > > file:/C:/Users/rvicups/.m2/repository/org/apache/cxf/cxf-rt-databinding-aegis/2.3.0-SNAPSHOT/cxf-rt-databinding-aeg
[jira] Commented: (CXF-2749) org.apache.cxf.configuration.spring.JAXBBeanFactory cannot handle elements with namespace prefixes
[ https://issues.apache.org/jira/browse/CXF-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852406#action_12852406 ] Daniel Kulp commented on CXF-2749: -- The better workaround would be just use woodstox. Woodstox is MUCH faster than Sun's implementation and thus, having woodstox available would help the performance of all the XML processing that CXF does (which is a lot). See: http://fusesource.com/issues/browse/SF-243 for some benchmarks I did. That said, this is a bug that needs fixing. > org.apache.cxf.configuration.spring.JAXBBeanFactory cannot handle elements > with namespace prefixes > -- > > Key: CXF-2749 > URL: https://issues.apache.org/jira/browse/CXF-2749 > Project: CXF > Issue Type: Bug > Components: Configuration, Transports >Affects Versions: 2.2.6 > Environment: Only when used with Sun StAX implementation 1.4.2; does > not seem to happen with Woodstox >Reporter: Jonathan Whitall >Priority: Minor > > I first noticed this when attempting to define the http:conduit element in a > Spring config file: > http://cxf.apache.org/transports/http/configuration"; > xmlns:beans="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > "> > >/> > > > It always fails with the following exception: > Caused by: javax.xml.bind.UnmarshalException > - with linked exception: > [javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,198] > Message: > http://www.w3.org/TR/1999/REC-xml-names-19990114#ElementPrefixUnbound?http&http:client] > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:426) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) > at > org.apache.cxf.configuration.spring.JAXBBeanFactory.createJAXBBean(JAXBBeanFactory.java:51) > ... 124 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at > [row,col]:[1,198] > Message: > http://www.w3.org/TR/1999/REC-xml-names-19990114#ElementPrefixUnbound?http&http:client > at > com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:593) > at > com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:160) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360) > ... 126 more > Looking at the source code, it appears that CXF is sending the body contents > of http:conduit verbatim to JAXBBeanFactory for parsing into a JAXB object. > Apparently, Woodstox doesn't care if there is an unregistered namespace > prefix, but the Sun StAX implementation does and throws the exception. > My current workaround is to define the http:conduit element in a separate XML > file and use it as the default namespace like this: > http://cxf.apache.org/transports/http/configuration"; > xmlns:beans="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > "> > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2639) Expose Cryptographic coverage checking code from PolicyBasedWSS4JInInterceptor in a non-WS-Policy based interceptor
[ https://issues.apache.org/jira/browse/CXF-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Valeri updated CXF-2639: -- Fix Version/s: 2.2.8 2.3 > Expose Cryptographic coverage checking code from > PolicyBasedWSS4JInInterceptor in a non-WS-Policy based interceptor > --- > > Key: CXF-2639 > URL: https://issues.apache.org/jira/browse/CXF-2639 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.3 >Reporter: David Valeri >Assignee: David Valeri >Priority: Minor > Fix For: 2.3, 2.2.8 > > > In some cases, manual configuration of security profile/policy is necessary. > In one particular example, I would like to validate cryptographic coverage of > a SOAP message while using a traditionally/manually configured interceptor > chain. The existing code that enforces such coverage is only accessible to > PolicyBasedWSS4JInInterceptor and cannot be reused. Additionally, this code > is affected by [CXF-2638]. > The solution could be a class that holds XPath expressions for the different > types of required cryptographic coverage and can be injected into a a simple > interceptor that is usable without policy based configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2748) Unmarshalling error when using fastinfoset
[
https://issues.apache.org/jira/browse/CXF-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852411#action_12852411
]
Daniel Kulp commented on CXF-2748:
--
Can you test your "live" project with the latest 2.2.8-SNAPSHOT jars? I
backported some more fixes from 2.3 for this so I THINK it should now work
fine. Before marking this resolved, I'd like to be sure.
> Unmarshalling error when using fastinfoset
> --
>
> Key: CXF-2748
> URL: https://issues.apache.org/jira/browse/CXF-2748
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.7
> Environment: Windows Vista
> jdk1.6.0_07
>Reporter: Reinis Vicups
> Fix For: 2.3
>
> Attachments: cxf.jaxws.infoset.twoway.mep.test.zip
>
>
> I have a webservice operation that returns primitive "string". I call this
> very same operation in three different ways: 1. without any sort of
> compression; 2. with mtom compression 3. with fastinfoset compression.
> The no compression call and mtom compression call works but fastinfoset call
> fails with this exception:
> 15:24:49,328 DEBUG [main] apache.cxf.phase.PhaseInterceptorChain (240) -
> Invoking handleMessage on interceptor
> org.apache.cxf.interceptor.docliteralinintercep...@1bb3e9a
> 15:24:49,343 WARN [main] apache.cxf.phase.PhaseInterceptorChain (365) -
> Interceptor for
> {http://blahblah/email/service}EmailUS#{http://blahblah/email/service}sendEmail
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: null
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:780)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderDecoder.java:624)
> at org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:128)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:106)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:672)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:2254)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2134)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1988)
> 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:639)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:484)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:310)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:262)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124)
> at $Proxy67.sendEmail(Unknown Source)
> at
> blahblah.email.service.EmailUSWSImplTest.prepareAndCallSendEmailWebService(EmailUSWSImplTest.java:332)
> at
> blahblah.email.service.EmailUSWSImplTest.testSendEmailWithFastinfosetCompression(EmailUSWSImplTest.java:304)
> 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 org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> at
> org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> at
> org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> at
> org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> at
> org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> at
> org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> at
[jira] Commented: (CXF-2721) org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
[ https://issues.apache.org/jira/browse/CXF-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852412#action_12852412 ] Daniel Kulp commented on CXF-2721: -- This is normally caused by an empty response coming back from the server. Can you wireshark it or similar and see what is in the payload coming back? > org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader Caused > by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog > > > Key: CXF-2721 > URL: https://issues.apache.org/jira/browse/CXF-2721 > Project: CXF > Issue Type: Sub-task >Affects Versions: 2.1 > Environment: geronimo 2.1.1, Spring 2.0.5 , CXF 2.1 >Reporter: rajesh Bose >Priority: Blocker > > Mar 12, 2010 12:47:29 PM org.apache.cxf.phase.PhaseInterceptorChain > doIntercept > INFO: Interceptor has thrown exception, unwinding now > org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader. > at > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:183) > at > org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:56) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:429) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:2001) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1828) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66) > at > org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:590) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:220) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) > at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) > at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) > at > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:171) > at $Proxy294.importDocument(Unknown Source) > at > com.oxseed.saas.createorder.services.internal.StdCreateOrderService.createOrder(StdCreateOrderService.java:121) > 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:585) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149) > at > org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77) > at > com.oxseed.saas.interceptors.log.JAMonTimeLoggingAspect.logAccessTime(JAMonTimeLoggingAspect.java:160) > at > com.oxseed.saas.interceptors.log.JAMonTimeLoggingAspect.logAccessTimeFlowService(JAMonTimeLoggingAspect.java:108) > at sun.reflect.GeneratedMethodAccessor828.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627) > at > org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616) > at > org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171) > at > org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77) > at > com.oxseed.saas.interceptors.log.TimeLoggingAspect.logAccessTime(TimeLoggingAspect.java:62) > at sun.reflect.GeneratedMethodAccessor757.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMetho
[jira] Resolved: (CXF-2639) Expose Cryptographic coverage checking code from PolicyBasedWSS4JInInterceptor in a non-WS-Policy based interceptor
[ https://issues.apache.org/jira/browse/CXF-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Valeri resolved CXF-2639. --- Resolution: Fixed > Expose Cryptographic coverage checking code from > PolicyBasedWSS4JInInterceptor in a non-WS-Policy based interceptor > --- > > Key: CXF-2639 > URL: https://issues.apache.org/jira/browse/CXF-2639 > Project: CXF > Issue Type: Improvement > Components: WS-* Components >Affects Versions: 2.3 >Reporter: David Valeri >Assignee: David Valeri >Priority: Minor > Fix For: 2.3, 2.2.8 > > > In some cases, manual configuration of security profile/policy is necessary. > In one particular example, I would like to validate cryptographic coverage of > a SOAP message while using a traditionally/manually configured interceptor > chain. The existing code that enforces such coverage is only accessible to > PolicyBasedWSS4JInInterceptor and cannot be reused. Additionally, this code > is affected by [CXF-2638]. > The solution could be a class that holds XPath expressions for the different > types of required cryptographic coverage and can be injected into a a simple > interceptor that is usable without policy based configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CXF-2742) CXF MBeans are not unregistered/reregistered properly on CXF Bus shutdown and restart controlled by Spring DM
[ https://issues.apache.org/jira/browse/CXF-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Valeri reassigned CXF-2742: - Assignee: David Valeri > CXF MBeans are not unregistered/reregistered properly on CXF Bus shutdown and > restart controlled by Spring DM > - > > Key: CXF-2742 > URL: https://issues.apache.org/jira/browse/CXF-2742 > Project: CXF > Issue Type: Bug > Components: Bus >Affects Versions: 2.2.6, 2.2.7 >Reporter: David Valeri >Assignee: David Valeri > > When initializing CXF in a Spring context file using the standard CXF Spring > XML imports and the standard CXF namespace handlers for CXF Bus > configuration, a restart of the Spring application context triggered by > Spring DM in an OSGi container results in the CXF registered MBeans > disappearing. The MBeans will not reappear until the JVM hosting the OSGi > container is restarted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2735) Implement Castor databinding
[ https://issues.apache.org/jira/browse/CXF-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852435#action_12852435 ] kevin wu commented on CXF-2735: --- Hi Dan, I just submitted a proposal for this project. My proposal in Apache wiki: http://wiki.apache.org/general/soc2010-cxf2735-proposal My proposal in GSoC: http://socghop.appspot.com/gsoc/student_proposal/private/google/gsoc2010/kevin/t127008961726 I think you may be my mentor. best regards, Kevin Wu. > Implement Castor databinding > > > Key: CXF-2735 > URL: https://issues.apache.org/jira/browse/CXF-2735 > Project: CXF > Issue Type: New Feature > Components: OtherDatabindings >Reporter: Daniel Kulp > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2727) NullPointerException at org.apache.cxf.transport.TransportURIResolver when the WSDL is not found instead of an exception with a useful message
[
https://issues.apache.org/jira/browse/CXF-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2727.
--
Resolution: Fixed
Fix Version/s: 2.2.8
Assignee: Daniel Kulp
> NullPointerException at org.apache.cxf.transport.TransportURIResolver when
> the WSDL is not found instead of an exception with a useful message
> --
>
> Key: CXF-2727
> URL: https://issues.apache.org/jira/browse/CXF-2727
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 2.2.4
>Reporter: Gary Gregory
>Assignee: Daniel Kulp
> Fix For: 2.2.8
>
>
> I get bit by this every time so you would I think I would learn: You get a
> {{NullPointerException at org.apache.cxf.transport.TransportURIResolver}}
> when the WSDL is not found instead of an Exception with a useful message,
> For example:
> {{WSDLServiceFactory factory = new
> WSDLServiceFactory(BusFactory.newInstance().createBus(),
> wsdlUrlString.trim(), null);}}
> Where wsdlUrlString points to a resource that is not there, in my case a
> resource on disk that is not there.
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:109)
> at
> org.apache.cxf.catalog.CatalogWSDLLocator.getBaseInputSource(CatalogWSDLLocator.java:72)
> at
> org.apache.cxf.wsdl11.AbstractWrapperWSDLLocator.getBaseInputSource(AbstractWrapperWSDLLocator.java:57)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:210)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:175)
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:91)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf$ValidatingInterceptor.initValidatingInterceptor(SoapServletCxf.java:952)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf$ValidatingInterceptor.addBefore(SoapServletCxf.java:931)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf.initValidators(SoapServletCxf.java:1303)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf.init(SoapServletCxf.java:1262)
> at
> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
> at
> org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:322)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:938)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)
> {noformat}
> I can see in TransportURIResolver, that there is a {{null}} check for
> {{base}} but that the last {{if}} in the method is not guarded for a {{null
> base}}
> Can we get a exception thrown with a URI not found or some such?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2749) org.apache.cxf.configuration.spring.JAXBBeanFactory cannot handle elements with namespace prefixes
[ https://issues.apache.org/jira/browse/CXF-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852487#action_12852487 ] Jonathan Whitall commented on CXF-2749: --- I wish I could use Woodstox, however I am running CXF on WebSphere 6.1. I get into some pretty serious class loading issues because of some of the classes that are bundled within WebSphere seem to load pieces of the Sun implementation, expecting that the rest of the implementation be there. While I have Woodstox on my classpath, I have only recently figured out that it's not being used. Do you know if there is a way to have more than one StAX implementation on the classpath and direct CXF to use the Woodstox one? > org.apache.cxf.configuration.spring.JAXBBeanFactory cannot handle elements > with namespace prefixes > -- > > Key: CXF-2749 > URL: https://issues.apache.org/jira/browse/CXF-2749 > Project: CXF > Issue Type: Bug > Components: Configuration, Transports >Affects Versions: 2.2.6 > Environment: Only when used with Sun StAX implementation 1.4.2; does > not seem to happen with Woodstox >Reporter: Jonathan Whitall >Priority: Minor > > I first noticed this when attempting to define the http:conduit element in a > Spring config file: > http://cxf.apache.org/transports/http/configuration"; > xmlns:beans="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > "> > >/> > > > It always fails with the following exception: > Caused by: javax.xml.bind.UnmarshalException > - with linked exception: > [javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,198] > Message: > http://www.w3.org/TR/1999/REC-xml-names-19990114#ElementPrefixUnbound?http&http:client] > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:426) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) > at > org.apache.cxf.configuration.spring.JAXBBeanFactory.createJAXBBean(JAXBBeanFactory.java:51) > ... 124 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at > [row,col]:[1,198] > Message: > http://www.w3.org/TR/1999/REC-xml-names-19990114#ElementPrefixUnbound?http&http:client > at > com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:593) > at > com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:160) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360) > ... 126 more > Looking at the source code, it appears that CXF is sending the body contents > of http:conduit verbatim to JAXBBeanFactory for parsing into a JAXB object. > Apparently, Woodstox doesn't care if there is an unregistered namespace > prefix, but the Sun StAX implementation does and throws the exception. > My current workaround is to define the http:conduit element in a separate XML > file and use it as the default namespace like this: > http://cxf.apache.org/transports/http/configuration"; > xmlns:beans="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > "> > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-2750) Output parameter and method name issue
Output parameter and method name issue -- Key: CXF-2750 URL: https://issues.apache.org/jira/browse/CXF-2750 Project: CXF Issue Type: Bug Components: JAXB Databinding Affects Versions: 2.2.7 Reporter: Derek Ryder I discovered an issue related to the name of a method and it's associated output parameter name. If you name the method foo and the output parameter is named fooResponse, you'll end up with an exception. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'eSessionAuthenticationWS': Invocation of init method failed; nested exception is javax.xml.ws.WebServiceException: org.apache.ws.commons.schema.XmlSchemaException: Schema for namespace '' already contains type 'fooResponse' I did some digging into the code and it appears to be an issue with the naming convention in the code. When generating the response object for an operation it takes the method name and adds Response to it and it ends up as a schema type. Then when the output parameter is being initialized there is already a fooResponse schema type and thus the schema type collision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2750) Output parameter and method name issue
[ https://issues.apache.org/jira/browse/CXF-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852493#action_12852493 ] Daniel Kulp commented on CXF-2750: -- This is per spec and not much we can do without violating the spec. In the event of a collision, the spec requires that the USER provide a new name via the @ResponseWrapper and @Response annotations. > Output parameter and method name issue > -- > > Key: CXF-2750 > URL: https://issues.apache.org/jira/browse/CXF-2750 > Project: CXF > Issue Type: Bug > Components: JAXB Databinding >Affects Versions: 2.2.7 >Reporter: Derek Ryder > > I discovered an issue related to the name of a method and it's associated > output parameter name. > If you name the method foo and the output parameter is named fooResponse, > you'll end up with an exception. > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'eSessionAuthenticationWS': Invocation of init method failed; > nested exception is javax.xml.ws.WebServiceException: > org.apache.ws.commons.schema.XmlSchemaException: Schema for namespace ' name space>' already contains type 'fooResponse' > I did some digging into the code and it appears to be an issue with the > naming convention in the code. When generating the response object for an > operation it takes the method name and adds Response to it and it ends up as > a schema type. Then when the output parameter is being initialized there is > already a fooResponse schema type and thus the schema type collision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2727) NullPointerException at org.apache.cxf.transport.TransportURIResolver when the WSDL is not found instead of an exception with a useful message
[
https://issues.apache.org/jira/browse/CXF-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852495#action_12852495
]
Gary Gregory commented on CXF-2727:
---
Ok, cool, thank you for the fix.
When I look at the call sites for the method fixed, I see in CatalogWSDLLocator:
{code:java}
public InputSource getBaseInputSource() {
InputSource result = null;
if (manager != null) {
try {
String s = manager.resolveSystem(baseUri);
if (s != null) {
result = resolver.resolve(s, null);
}
} catch (MalformedURLException e) {
//ignore
} catch (IOException e) {
//ignore
}
}
if (result == null) {
result = resolver.resolve(baseUri, null);
}
if (wsdlUrl == null
&& result != null) {
wsdlUrl = result.getSystemId();
}
baseUri = resolver.getURI();
return result;
}
{code}
I do not see what the end of the method does unless there are some side-effects
involved. IOW, is this needed?
{code:java}
if (wsdlUrl == null
&& result != null) {
wsdlUrl = result.getSystemId();
}
baseUri = resolver.getURI();
{code}
It does not affect the result, at first glance at least.
> NullPointerException at org.apache.cxf.transport.TransportURIResolver when
> the WSDL is not found instead of an exception with a useful message
> --
>
> Key: CXF-2727
> URL: https://issues.apache.org/jira/browse/CXF-2727
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 2.2.4
>Reporter: Gary Gregory
>Assignee: Daniel Kulp
> Fix For: 2.2.8
>
>
> I get bit by this every time so you would I think I would learn: You get a
> {{NullPointerException at org.apache.cxf.transport.TransportURIResolver}}
> when the WSDL is not found instead of an Exception with a useful message,
> For example:
> {{WSDLServiceFactory factory = new
> WSDLServiceFactory(BusFactory.newInstance().createBus(),
> wsdlUrlString.trim(), null);}}
> Where wsdlUrlString points to a resource that is not there, in my case a
> resource on disk that is not there.
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:109)
> at
> org.apache.cxf.catalog.CatalogWSDLLocator.getBaseInputSource(CatalogWSDLLocator.java:72)
> at
> org.apache.cxf.wsdl11.AbstractWrapperWSDLLocator.getBaseInputSource(AbstractWrapperWSDLLocator.java:57)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:210)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:175)
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:91)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf$ValidatingInterceptor.initValidatingInterceptor(SoapServletCxf.java:952)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf$ValidatingInterceptor.addBefore(SoapServletCxf.java:931)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf.initValidators(SoapServletCxf.java:1303)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf.init(SoapServletCxf.java:1262)
> at
> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
> at
> org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:322)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:938)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)
> {noformat}
> I can see in TransportURIResolver, that there is a {{null}} check f
[jira] Commented: (CXF-2727) NullPointerException at org.apache.cxf.transport.TransportURIResolver when the WSDL is not found instead of an exception with a useful message
[
https://issues.apache.org/jira/browse/CXF-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852498#action_12852498
]
Gary Gregory commented on CXF-2727:
---
Do you have a release time-frame for 2.2.8? This issue has bitten us a couple
of times. Thank you.
> NullPointerException at org.apache.cxf.transport.TransportURIResolver when
> the WSDL is not found instead of an exception with a useful message
> --
>
> Key: CXF-2727
> URL: https://issues.apache.org/jira/browse/CXF-2727
> Project: CXF
> Issue Type: Improvement
>Affects Versions: 2.2.4
>Reporter: Gary Gregory
>Assignee: Daniel Kulp
> Fix For: 2.2.8
>
>
> I get bit by this every time so you would I think I would learn: You get a
> {{NullPointerException at org.apache.cxf.transport.TransportURIResolver}}
> when the WSDL is not found instead of an Exception with a useful message,
> For example:
> {{WSDLServiceFactory factory = new
> WSDLServiceFactory(BusFactory.newInstance().createBus(),
> wsdlUrlString.trim(), null);}}
> Where wsdlUrlString points to a resource that is not there, in my case a
> resource on disk that is not there.
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.cxf.transport.TransportURIResolver.resolve(TransportURIResolver.java:109)
> at
> org.apache.cxf.catalog.CatalogWSDLLocator.getBaseInputSource(CatalogWSDLLocator.java:72)
> at
> org.apache.cxf.wsdl11.AbstractWrapperWSDLLocator.getBaseInputSource(AbstractWrapperWSDLLocator.java:57)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:210)
> at
> org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:175)
> at
> org.apache.cxf.wsdl11.WSDLServiceFactory.(WSDLServiceFactory.java:91)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf$ValidatingInterceptor.initValidatingInterceptor(SoapServletCxf.java:952)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf$ValidatingInterceptor.addBefore(SoapServletCxf.java:931)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf.initValidators(SoapServletCxf.java:1303)
> at
> com.seagullsw.appinterface.server.comm.soap.SoapServletCxf.init(SoapServletCxf.java:1262)
> at
> org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440)
> at
> org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:339)
> at
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
> at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.handle(Server.java:322)
> at
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:938)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
> at
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)
> {noformat}
> I can see in TransportURIResolver, that there is a {{null}} check for
> {{base}} but that the last {{if}} in the method is not guarded for a {{null
> base}}
> Can we get a exception thrown with a URI not found or some such?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2750) Output parameter and method name issue
[ https://issues.apache.org/jira/browse/CXF-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852502#action_12852502 ] Derek Ryder commented on CXF-2750: -- I wasn't recommending violating the spec and there is much to be said for knowing the spec and thereby being aware that one cannot create method in such a manner. However I would be in favor of an exception that provides more information to the developer using the tool. > Output parameter and method name issue > -- > > Key: CXF-2750 > URL: https://issues.apache.org/jira/browse/CXF-2750 > Project: CXF > Issue Type: Bug > Components: JAXB Databinding >Affects Versions: 2.2.7 >Reporter: Derek Ryder > > I discovered an issue related to the name of a method and it's associated > output parameter name. > If you name the method foo and the output parameter is named fooResponse, > you'll end up with an exception. > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'eSessionAuthenticationWS': Invocation of init method failed; > nested exception is javax.xml.ws.WebServiceException: > org.apache.ws.commons.schema.XmlSchemaException: Schema for namespace ' name space>' already contains type 'fooResponse' > I did some digging into the code and it appears to be an issue with the > naming convention in the code. When generating the response object for an > operation it takes the method name and adds Response to it and it ends up as > a schema type. Then when the output parameter is being initialized there is > already a fooResponse schema type and thus the schema type collision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (CXF-2750) Output parameter and method name issue
[ https://issues.apache.org/jira/browse/CXF-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852502#action_12852502 ] Derek Ryder edited comment on CXF-2750 at 4/1/10 6:55 PM: -- I wasn't recommending violating the spec and there is much to be said for knowing the spec and thereby being aware that one cannot create method in such a manner. However I would be in favor of an exception that provides more information to the developer using Apache CXF. was (Author: dryder): I wasn't recommending violating the spec and there is much to be said for knowing the spec and thereby being aware that one cannot create method in such a manner. However I would be in favor of an exception that provides more information to the developer using the tool. > Output parameter and method name issue > -- > > Key: CXF-2750 > URL: https://issues.apache.org/jira/browse/CXF-2750 > Project: CXF > Issue Type: Bug > Components: JAXB Databinding >Affects Versions: 2.2.7 >Reporter: Derek Ryder > > I discovered an issue related to the name of a method and it's associated > output parameter name. > If you name the method foo and the output parameter is named fooResponse, > you'll end up with an exception. > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'eSessionAuthenticationWS': Invocation of init method failed; > nested exception is javax.xml.ws.WebServiceException: > org.apache.ws.commons.schema.XmlSchemaException: Schema for namespace ' name space>' already contains type 'fooResponse' > I did some digging into the code and it appears to be an issue with the > naming convention in the code. When generating the response object for an > operation it takes the method name and adds Response to it and it ends up as > a schema type. Then when the output parameter is being initialized there is > already a fooResponse schema type and thus the schema type collision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2630) JmsConfiguration with custom TaskExecutor with Spring 3.0 => NoSuchMethodError
[ https://issues.apache.org/jira/browse/CXF-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2630. -- Resolution: Fixed DOH!!! > JmsConfiguration with custom TaskExecutor with Spring 3.0 => > NoSuchMethodError > --- > > Key: CXF-2630 > URL: https://issues.apache.org/jira/browse/CXF-2630 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.2.5 > Environment: All >Reporter: Milan Duriancik >Assignee: Daniel Kulp > Fix For: 2.2.8 > > > When configuring Jms Transport with a custom ThreadPoolTaskExecutor (using > JmsConfiguration), I get a NoSuchMethodError in > JmsFactory.createJmsListener (tested with cxf 2.2.5 and 2.2.6-SNAPSHOT, > 21/01/2010) . > This is caused by a change in Spring 3.0: > DefaultMessageListenerContainer.setTaskExecutor(TaskExecutor) -> > DefaultMessageListenerContainer.setTaskExecutor(Executor). > (TaskExecutor extends Executor in Spring 3.0 but not in Spring 2.5.x) > I tested to rebuilt cxf-rt-transports-jms with spring.version=3.0.0.RELEASE > and it was OK when executed with Spring 3.0 classes. > To support both spring versions 3.*.* and 2.5.* a reflexion call to > setTaskExecutor(...) should be made. > - > the exception: > java.lang.NoSuchMethodError: > org/springframework/jms/listener/DefaultMessageListenerContainer.setTaskExecutor(Lorg/springframework/core/task/TaskExecutor;)V > at > org.apache.cxf.transport.jms.JMSFactory.createJmsListener(JMSFactory.java:237) > at > org.apache.cxf.transport.jms.JMSFactory.createJmsListener(JMSFactory.java:150) > at > org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:116) > at > org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:48) > at > org.apache.cxf.binding.AbstractBindingFactory.addListener(AbstractBindingFactory.java:164) > at > org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:805) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:122) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:271) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:209) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:404) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:618) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1529) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1468) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1398) > ... 37 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2749) org.apache.cxf.configuration.spring.JAXBBeanFactory cannot handle elements with namespace prefixes
[ https://issues.apache.org/jira/browse/CXF-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852669#action_12852669 ] Daniel Kulp commented on CXF-2749: -- Can you test this with CXF 2.2.7? I think this is actually fixed. In anycase, I cannot reproduce it with 2.2.6 or 2.2.7 using the sun stax stuff built into the JDK.Any chance you can create a small testcase outside of WebSphere (since I don't have WebSphere)? > org.apache.cxf.configuration.spring.JAXBBeanFactory cannot handle elements > with namespace prefixes > -- > > Key: CXF-2749 > URL: https://issues.apache.org/jira/browse/CXF-2749 > Project: CXF > Issue Type: Bug > Components: Configuration, Transports >Affects Versions: 2.2.6 > Environment: Only when used with Sun StAX implementation 1.4.2; does > not seem to happen with Woodstox >Reporter: Jonathan Whitall >Priority: Minor > > I first noticed this when attempting to define the http:conduit element in a > Spring config file: > http://cxf.apache.org/transports/http/configuration"; > xmlns:beans="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > "> > >/> > > > It always fails with the following exception: > Caused by: javax.xml.bind.UnmarshalException > - with linked exception: > [javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,198] > Message: > http://www.w3.org/TR/1999/REC-xml-names-19990114#ElementPrefixUnbound?http&http:client] > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.handleStreamException(UnmarshallerImpl.java:426) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:362) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:339) > at > org.apache.cxf.configuration.spring.JAXBBeanFactory.createJAXBBean(JAXBBeanFactory.java:51) > ... 124 more > Caused by: javax.xml.stream.XMLStreamException: ParseError at > [row,col]:[1,198] > Message: > http://www.w3.org/TR/1999/REC-xml-names-19990114#ElementPrefixUnbound?http&http:client > at > com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:593) > at > com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:160) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:360) > ... 126 more > Looking at the source code, it appears that CXF is sending the body contents > of http:conduit verbatim to JAXBBeanFactory for parsing into a JAXB object. > Apparently, Woodstox doesn't care if there is an unregistered namespace > prefix, but the Sun StAX implementation does and throws the exception. > My current workaround is to define the http:conduit element in a separate XML > file and use it as the default namespace like this: > http://cxf.apache.org/transports/http/configuration"; > xmlns:beans="http://www.springframework.org/schema/beans"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation=" > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://cxf.apache.org/transports/http/configuration > http://cxf.apache.org/schemas/configuration/http-conf.xsd > "> > > > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
