[jira] Created: (CXF-3234) JAXRSOutInterceptor can be confused about response Type when Response entity is overidden
JAXRSOutInterceptor can be confused about response Type when Response entity is overidden - Key: CXF-3234 URL: https://issues.apache.org/jira/browse/CXF-3234 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 2.3.1 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Fix For: 2.3.2, 2.4 When ExceptionMappers or ResponseHandler filters override Response entity after the resource method has been invoked, JAXRSOutInterceptor will most likely get confused about the generic type of the Response entity, unless the new entity class is assignable to that of the method response type -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3233) JAXB xsd validation working on incoming messages but not outgoing messages
[
https://issues.apache.org/jira/browse/CXF-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978812#action_12978812
]
Benjamin Shults commented on CXF-3233:
--
I took an automatically generated UUID and added the 'z' character to the end.
This broke it in two ways: it made it too long and it added an illegal
character. ('z' is not allowed anywhere in the value.)
I have traced this all the way into com.sun.xml.bind.v2.runtime.MarshallerImpl.
That class doesn't seem to be doing validation closely enough. It is called
from org.apache.cxf.jaxb.JAXBEncoderDecoder.
> JAXB xsd validation working on incoming messages but not outgoing messages
> --
>
> Key: CXF-3233
> URL: https://issues.apache.org/jira/browse/CXF-3233
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 2.3.1
> Environment: webLogic
>Reporter: Benjamin Shults
>Assignee: Freeman Fang
> Fix For: NeedMoreInfo
>
>
> Using CXF 2.3.1.
> Generated Java from WSDLs using JAXB.
> Using
>
>
>
> in the client configuration.
> My test creates an object that fails this particular requirement of the WSDL:
>
>
>
> Universally Unique Identifier
>
>
>
>
>
> value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"
> />
>
>
> However, the message is marshalled and makes it all the way through the
> outgoing interceptor chain.
> The WSDL is one-way: input-only.
> wsdlLocation is specified in an annotation in the Impls.
> Interestingly, incoming messages that fail validation of this same constraint
> are blocked by the interceptor chain during unmarshalling.
> I'm testing on WebLogic. I could also test on WebSphere is needed.
> Other XSD validation failures (such as a missing required element) are being
> caught by the outgoing marshaller.
> The reason that we upgraded to 2.3.1 from 2.2.6 was that we were seeing
> similar issues on the inbound messages. In 2.3.1, complete XSD validation
> occurs for inbound messages but not for outbound ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3233) JAXB xsd validation working on incoming messages but not outgoing messages
[
https://issues.apache.org/jira/browse/CXF-3233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978835#action_12978835
]
Benjamin Shults commented on CXF-3233:
--
The server application is both a client and a server. The WSDLs are similar on
both sides in that they share most of their non-top-level types. So, I am
testing both inbound and outbound services on the same server.
I haven't gotten around to testing on WebSphere but I might get to it today.
So far, all of my testing of this particular issue has been on WebLogic.
> JAXB xsd validation working on incoming messages but not outgoing messages
> --
>
> Key: CXF-3233
> URL: https://issues.apache.org/jira/browse/CXF-3233
> Project: CXF
> Issue Type: Bug
> Components: Bus
>Affects Versions: 2.3.1
> Environment: webLogic
>Reporter: Benjamin Shults
>Assignee: Freeman Fang
> Fix For: NeedMoreInfo
>
>
> Using CXF 2.3.1.
> Generated Java from WSDLs using JAXB.
> Using
>
>
>
> in the client configuration.
> My test creates an object that fails this particular requirement of the WSDL:
>
>
>
> Universally Unique Identifier
>
>
>
>
>
> value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"
> />
>
>
> However, the message is marshalled and makes it all the way through the
> outgoing interceptor chain.
> The WSDL is one-way: input-only.
> wsdlLocation is specified in an annotation in the Impls.
> Interestingly, incoming messages that fail validation of this same constraint
> are blocked by the interceptor chain during unmarshalling.
> I'm testing on WebLogic. I could also test on WebSphere is needed.
> Other XSD validation failures (such as a missing required element) are being
> caught by the outgoing marshaller.
> The reason that we upgraded to 2.3.1 from 2.2.6 was that we were seeing
> similar issues on the inbound messages. In 2.3.1, complete XSD validation
> occurs for inbound messages but not for outbound ones.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3234) JAXRSOutInterceptor can be confused about response Type when Response entity is overidden
[ https://issues.apache.org/jira/browse/CXF-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-3234. --- Resolution: Fixed > JAXRSOutInterceptor can be confused about response Type when Response entity > is overidden > - > > Key: CXF-3234 > URL: https://issues.apache.org/jira/browse/CXF-3234 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 2.3.1 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 2.3.2, 2.4 > > > When ExceptionMappers or ResponseHandler filters override Response entity > after the resource method has been invoked, JAXRSOutInterceptor will most > likely get confused about the generic type of the Response entity, unless the > new entity class is assignable to that of the method response type -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3235) Introduce a switch for the soap/jms spec transport to turn of SoapJMSInInterceptor
Introduce a switch for the soap/jms spec transport to turn of SoapJMSInInterceptor -- Key: CXF-3235 URL: https://issues.apache.org/jira/browse/CXF-3235 Project: CXF Issue Type: Improvement Reporter: Christian Schneider Fix For: 2.3.2 The soap/jms spec requires several jms properties like SOAPJMS_contentType to be set on an incoming message. In case the required properties are not present a fault is returned. While this is perfectly compliant with the spec it creates interop problems with implementations that do not yet follow the spec. So I propose to introduce a switch that disables the SoapJMSInInterceptor or that turns the faults into warnings. This would allow older clients to interoperate with cxf. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3236) Add support for an Issued Token extracted from a SAML assertion
Add support for an Issued Token extracted from a SAML assertion --- Key: CXF-3236 URL: https://issues.apache.org/jira/browse/CXF-3236 Project: CXF Issue Type: Bug Components: WS-* Components Affects Versions: 2.3.1 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 2.3.2, 2.4 CXF cannot currently support the following use-case: A service endpoint has a security policy consisting of a sp:SymmetricBinding which uses a (SAML) sp:IssuedToken as the sp:ProtectionToken. A client parses this, and obtains the appropriate SAML token from an STS, which it sends to the service endpoint, securing the message appropriately. The service endpoint can process the request, but it falls down on the reply as it does not know how to get access to the Issued Token to secure the message reply. A patch to WSS4J to save the secret key extracted from the SAML assertion is here (https://issues.apache.org/jira/browse/WSS-263). A patch is required to CXF to parse the result set and save the appropriate token. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3236) Add support for an Issued Token extracted from a SAML assertion
[ https://issues.apache.org/jira/browse/CXF-3236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-3236: - Attachment: cxf-3234-tentative.patch Here is a *tentative* patch for this issue. I've tested it and a CXF endpoint can now secure the reply to the client appropriately. > Add support for an Issued Token extracted from a SAML assertion > --- > > Key: CXF-3236 > URL: https://issues.apache.org/jira/browse/CXF-3236 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.3.1 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 2.3.2, 2.4 > > Attachments: cxf-3234-tentative.patch > > > CXF cannot currently support the following use-case: > A service endpoint has a security policy consisting of a sp:SymmetricBinding > which uses a (SAML) sp:IssuedToken as the sp:ProtectionToken. A client parses > this, and obtains the appropriate SAML token from an STS, which it sends to > the service endpoint, securing the message appropriately. The service > endpoint can process the request, but it falls down on the reply as it does > not know how to get access to the Issued Token to secure the message reply. > A patch to WSS4J to save the secret key extracted from the SAML assertion is > here (https://issues.apache.org/jira/browse/WSS-263). A patch is required to > CXF to parse the result set and save the appropriate token. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3235) Introduce a switch for the soap/jms spec transport to turn of SoapJMSInInterceptor
[ https://issues.apache.org/jira/browse/CXF-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978884#action_12978884 ] Glen Mazza commented on CXF-3235: - Devil's advocate: Since this code is apparently new can't we hold off on adding the switch and instead put JIRAs in for other implementations to become compliant with the spec? The problem with adding this flag is that once it's in there, it will always be in there (with whatever subsequent security or accuracy risks inherent in shutting off these faults), and I'm not sure that CXF should worry about obsolete implementations that cannot send the required JMS properties. (Here I define "obsolete" as not an implementation that presently does not support the JMS properties but is so inactive that JIRAs to that particular project would *not* result in the problem being fixed.) What are the primary nonsupporting implementations you're concerned about right now that causes you to want to add this flag? Glen > Introduce a switch for the soap/jms spec transport to turn of > SoapJMSInInterceptor > -- > > Key: CXF-3235 > URL: https://issues.apache.org/jira/browse/CXF-3235 > Project: CXF > Issue Type: Improvement >Reporter: Christian Schneider > Fix For: 2.3.2 > > > The soap/jms spec requires several jms properties like SOAPJMS_contentType to > be set on an incoming message. In case the required properties are not > present a fault is returned. > While this is perfectly compliant with the spec it creates interop problems > with implementations that do not yet follow the spec. > So I propose to introduce a switch that disables the SoapJMSInInterceptor or > that turns the faults into warnings. This would allow older clients to > interoperate with cxf. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2687) CLONE -WSDL Schema Imports - include schema location doesnt have full path
[ https://issues.apache.org/jira/browse/CXF-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2687. -- Resolution: Fixed Fix Version/s: 2.3.2 > CLONE -WSDL Schema Imports - include schema location doesnt have full path > -- > > Key: CXF-2687 > URL: https://issues.apache.org/jira/browse/CXF-2687 > Project: CXF > Issue Type: Bug >Affects Versions: 2.2.5 >Reporter: Yogesh >Assignee: Daniel Kulp >Priority: Blocker > Fix For: 2.3.2 > > > Hi I have configured one webservice using following xml configuration > id="personService"> > > > WEB-INF/classes/app/valueobjects/RequestResponse.xsd > > > > > > CXF generates WSDL at runtime but generateds WSDL looks like > targetNamespace="http://www.webservice.com/ws"; > xmlns:ns1="http://cxf.apache.org/bindings/xformat"; > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > xmlns:tns="http://www.webservice.com/ws"; > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; > xmlns:xsd="http://www.w3.org/2001/XMLSchema";> > > targetNamespace="http://www.webservice.com/ws"; > xmlns="http://www.w3.org/2001/XMLSchema"; > xmlns:tns="http://www.webservice.com/ws";> > > > > > > > > > > > > /> > type="tns:GetPersonDetailsResponse" /> > > > ... > The include element in schema doesn't contain entire path and hence the > clients are not able to retrieve related elements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-3235) Introduce a switch for the soap/jms spec transport to turn of SoapJMSInInterceptor
[ https://issues.apache.org/jira/browse/CXF-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978999#action_12978999 ] Christian Schneider commented on CXF-3235: -- The first implementation where I noticed this is camel-jms together with camel-cxf. I guess that at the moment almost all other implementations do not support the spec. The problem is in any case that people will want to introduce this gradually at any bigger installation. So imagine a big company with a service that is used by 10 clients. If the service upgrades to be spec compliant then all clients will break. So even if all want to upgrade they will not do it at the same time. > Introduce a switch for the soap/jms spec transport to turn of > SoapJMSInInterceptor > -- > > Key: CXF-3235 > URL: https://issues.apache.org/jira/browse/CXF-3235 > Project: CXF > Issue Type: Improvement >Reporter: Christian Schneider > Fix For: 2.3.2 > > > The soap/jms spec requires several jms properties like SOAPJMS_contentType to > be set on an incoming message. In case the required properties are not > present a fault is returned. > While this is perfectly compliant with the spec it creates interop problems > with implementations that do not yet follow the spec. > So I propose to introduce a switch that disables the SoapJMSInInterceptor or > that turns the faults into warnings. This would allow older clients to > interoperate with cxf. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-3190) cvc-elt.1: Cannot find the declaration of element 'mappings'. at /com/webservice/Employee.aegis.xml
[
https://issues.apache.org/jira/browse/CXF-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-3190:
-
Description:
I have deployed a webservice on JBoss succesfully and was able to access it.
Now i want to include Aegis Databinding for the request and response XMLs. For
that i have written a mapping file on my client side with name
Employee.aegis.xml for the Employee bean and have done the configurations in my
client program. But when I try to execute my client prorgam I'm getting the
following error:
{code}
Dec 14, 2010 4:43:02 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
checkServiceClassAnnotations
WARNING: A JAX-WS Annotation was found on
com.webservice.EmployeeServicePortType while using the Simple frontend. For
better results, use the JAX-WS frontend.
Dec 14, 2010 4:43:03 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://webservice.com/}EmployeeServicePortType from
class com.webservice.EmployeeServicePortType
Dec 14, 2010 4:43:04 PM org.apache.cxf.aegis.type.XMLTypeCreator$1 error
SEVERE: cvc-elt.1: Cannot find the declaration of element 'mappings'. at
/com/webservice/Employee.aegis.xml line 1 column 42.
org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of
element 'mappings'.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
Source)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown
Source)
at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
at
org.apache.cxf.aegis.type.XMLTypeCreator.readAegisFile(XMLTypeCreator.java:181)
at
org.apache.cxf.aegis.type.XMLTypeCreator.getDocument(XMLTypeCreator.java:206)
at
org.apache.cxf.aegis.type.XMLTypeCreator.findMapping(XMLTypeCreator.java:265)
at
org.apache.cxf.aegis.type.XMLTypeCreator.isEnum(XMLTypeCreator.java:217)
at
org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:118)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.getParameterType(AegisDatabinding.java:634)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:345)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(AegisDatabinding.java:303)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:270)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:467)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:278)
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:99)
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:51)
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:102)
at
com.webservice.EmployeeServicePortType_EmployeeServicePor
[jira] Updated: (CXF-3190) cvc-elt.1: Cannot find the declaration of element 'mappings'. at /com/webservice/Employee.aegis.xml
[
https://issues.apache.org/jira/browse/CXF-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-3190:
-
Description:
I have deployed a webservice on JBoss succesfully and was able to access it.
Now i want to include Aegis Databinding for the request and response XMLs. For
that i have written a mapping file on my client side with name
Employee.aegis.xml for the Employee bean and have done the configurations in my
client program. But when I try to execute my client prorgam I'm getting the
following error:
{code}
Dec 14, 2010 4:43:02 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
checkServiceClassAnnotations
WARNING: A JAX-WS Annotation was found on
com.webservice.EmployeeServicePortType while using the Simple frontend. For
better results, use the JAX-WS frontend.
Dec 14, 2010 4:43:03 PM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service {http://webservice.com/}EmployeeServicePortType from
class com.webservice.EmployeeServicePortType
Dec 14, 2010 4:43:04 PM org.apache.cxf.aegis.type.XMLTypeCreator$1 error
SEVERE: cvc-elt.1: Cannot find the declaration of element 'mappings'. at
/com/webservice/Employee.aegis.xml line 1 column 42.
org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of
element 'mappings'.
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
at
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
Source)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown
Source)
at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
at
org.apache.cxf.aegis.type.XMLTypeCreator.readAegisFile(XMLTypeCreator.java:181)
at
org.apache.cxf.aegis.type.XMLTypeCreator.getDocument(XMLTypeCreator.java:206)
at
org.apache.cxf.aegis.type.XMLTypeCreator.findMapping(XMLTypeCreator.java:265)
at
org.apache.cxf.aegis.type.XMLTypeCreator.isEnum(XMLTypeCreator.java:217)
at
org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:118)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.getParameterType(AegisDatabinding.java:634)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:345)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(AegisDatabinding.java:303)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:270)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:467)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:530)
at
org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:278)
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:99)
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:51)
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:102)
at
com.webservice.EmployeeServicePortType_EmployeeServicePor
[jira] Commented: (CXF-3190) cvc-elt.1: Cannot find the declaration of element 'mappings'. at /com/webservice/Employee.aegis.xml
[
https://issues.apache.org/jira/browse/CXF-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979037#action_12979037
]
Daniel Kulp commented on CXF-3190:
--
I believe the mapping file should be:
{code:xml}
http://webservice.com"; >
{code}
The mapping element should be in the default namespace.
> cvc-elt.1: Cannot find the declaration of element 'mappings'. at
> /com/webservice/Employee.aegis.xml
> ---
>
> Key: CXF-3190
> URL: https://issues.apache.org/jira/browse/CXF-3190
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.2.9
> Environment: Windows XP, JDK 1.6.0_13, Eclipse 3.4 Ganemyde,
>Reporter: Asif Ali Mohammed
>Priority: Critical
>
> I have deployed a webservice on JBoss succesfully and was able to access it.
> Now i want to include Aegis Databinding for the request and response XMLs.
> For that i have written a mapping file on my client side with name
> Employee.aegis.xml for the Employee bean and have done the configurations in
> my client program. But when I try to execute my client prorgam I'm getting
> the following error:
> {code}
> Dec 14, 2010 4:43:02 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> checkServiceClassAnnotations
> WARNING: A JAX-WS Annotation was found on
> com.webservice.EmployeeServicePortType while using the Simple frontend. For
> better results, use the JAX-WS frontend.
> Dec 14, 2010 4:43:03 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass
> INFO: Creating Service {http://webservice.com/}EmployeeServicePortType from
> class com.webservice.EmployeeServicePortType
> Dec 14, 2010 4:43:04 PM org.apache.cxf.aegis.type.XMLTypeCreator$1 error
> SEVERE: cvc-elt.1: Cannot find the declaration of element 'mappings'. at
> /com/webservice/Employee.aegis.xml line 1 column 42.
> org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of
> element 'mappings'.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown
> Source)
> at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.readAegisFile(XMLTypeCreator.java:181)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.getDocument(XMLTypeCreator.java:206)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.findMapping(XMLTypeCreator.java:265)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.isEnum(XMLTypeCreator.java:217)
> at
> org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:118)
> at
> org.apache.cxf.aegis.databinding.AegisDatabinding.getParameterType(AegisDatabinding.java:634)
> at
> org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:345)
> at
> org.apache.cxf.aeg
[jira] Resolved: (CXF-3190) cvc-elt.1: Cannot find the declaration of element 'mappings'. at /com/webservice/Employee.aegis.xml
[
https://issues.apache.org/jira/browse/CXF-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3190.
--
Resolution: Fixed
Fix Version/s: Invalid
The mapping file namespace is incorrect.
> cvc-elt.1: Cannot find the declaration of element 'mappings'. at
> /com/webservice/Employee.aegis.xml
> ---
>
> Key: CXF-3190
> URL: https://issues.apache.org/jira/browse/CXF-3190
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.2.9
> Environment: Windows XP, JDK 1.6.0_13, Eclipse 3.4 Ganemyde,
>Reporter: Asif Ali Mohammed
>Priority: Critical
> Fix For: Invalid
>
>
> I have deployed a webservice on JBoss succesfully and was able to access it.
> Now i want to include Aegis Databinding for the request and response XMLs.
> For that i have written a mapping file on my client side with name
> Employee.aegis.xml for the Employee bean and have done the configurations in
> my client program. But when I try to execute my client prorgam I'm getting
> the following error:
> {code}
> Dec 14, 2010 4:43:02 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> checkServiceClassAnnotations
> WARNING: A JAX-WS Annotation was found on
> com.webservice.EmployeeServicePortType while using the Simple frontend. For
> better results, use the JAX-WS frontend.
> Dec 14, 2010 4:43:03 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass
> INFO: Creating Service {http://webservice.com/}EmployeeServicePortType from
> class com.webservice.EmployeeServicePortType
> Dec 14, 2010 4:43:04 PM org.apache.cxf.aegis.type.XMLTypeCreator$1 error
> SEVERE: cvc-elt.1: Cannot find the declaration of element 'mappings'. at
> /com/webservice/Employee.aegis.xml line 1 column 42.
> org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of
> element 'mappings'.
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown
> Source)
> at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.readAegisFile(XMLTypeCreator.java:181)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.getDocument(XMLTypeCreator.java:206)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.findMapping(XMLTypeCreator.java:265)
> at
> org.apache.cxf.aegis.type.XMLTypeCreator.isEnum(XMLTypeCreator.java:217)
> at
> org.apache.cxf.aegis.type.AbstractTypeCreator.createTypeForClass(AbstractTypeCreator.java:118)
> at
> org.apache.cxf.aegis.databinding.AegisDatabinding.getParameterType(AegisDatabinding.java:634)
> at
> org.apache.cxf.aegis.databinding.AegisDatabinding.initializeMessage(AegisDatabinding.java:345)
> at
> org.apache.cxf.aegis.databinding.AegisDatabinding.initializeOperation(AegisDatabinding.java:303)
> at
> org.apache.cxf.aegis.databind
[jira] Updated: (CXF-2811) org.apache.cxf.interceptor.Fault: UNMARSHAL_ERROR ((XMLBeans data binding with the CXF version 2.2.7/2.2.8
[ https://issues.apache.org/jira/browse/CXF-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp updated CXF-2811: - Fix Version/s: NeedMoreInfo Can you create a small testcase for this? I cannot reproduce it using a simple service here. > org.apache.cxf.interceptor.Fault: UNMARSHAL_ERROR ((XMLBeans data binding > with the CXF version 2.2.7/2.2.8 > -- > > Key: CXF-2811 > URL: https://issues.apache.org/jira/browse/CXF-2811 > Project: CXF > Issue Type: Bug > Components: OtherDatabindings >Affects Versions: 2.2.7, 2.2.8 > Environment: GlassFish 2.x/3, CXF Version 2.2.7/8 , Ant 1.6 , jdk 1.6 >Reporter: Sundar Ramamurthy >Priority: Critical > Fix For: NeedMoreInfo > > > This issue was created in the past (early 2009) and said to have been > addressed as of 2.1.7 ..but i am not sure if there is anything additional > that i am missing to make this work. > BTW ->I am new user to the cxf library and so i might be missing something. > This is the steps.. > 1) Generate the Webservices with Contract/WSDL First approach. > 2) I used the default databinding and everything works fine (i can test the > wsdl and get the response correctly). > 2) Then i change the configuration (cxf-servlet.xml and wsdl2java to) use > xmlbeans databinding and when i publish the wsdl to the GlassFish Server, i > can see the wsdl (through the browser) > 3) I test the wsdl, and i get the "org.apache.cxf.interceptor.Fault: > UNMARSHAL_ERROR". I > The stacktrace says: > org.apache.cxf.interceptor.Fault: UNMARSHAL_ERROR > at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:87) > at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:45) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:109) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243) > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:110) > at > org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98) > at > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:423) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:178) > 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.doPost(AbstractHTTPServlet.java:103) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) > at > org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:315) > at > org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) > at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) > at > com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587) > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) > at > org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587) > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093) > at > org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291) > at > com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666) >
[jira] Resolved: (CXF-3131) CXF XCJ DV Plugin removes XmlElement Annotation from Fields
[
https://issues.apache.org/jira/browse/CXF-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3131.
--
Resolution: Fixed
Fix Version/s: 2.3.2
Assignee: Daniel Kulp
> CXF XCJ DV Plugin removes XmlElement Annotation from Fields
> ---
>
> Key: CXF-3131
> URL: https://issues.apache.org/jira/browse/CXF-3131
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.3.0
>Reporter: Andreas Gudian
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 2.3.2
>
>
> Using the XJC default value plugin (org.apache.cxf.xjcplugins:cxf-xjc-dv)
> removes the @XmlElement(name=...) annotation from fields where it adds a
> default value.
> For example, see the following XSD fragment:
> {code:xml}
>
>
>type="tns:customerTypeWithDefaultValuesInside" />
>
>
> {code}
> *Without* dv, the following code is generated:
> {code:title=TypeA.java}
> ...
> @XmlElement(name = "Customer", required = true)
> protected CustomerTypeWithDefaultValuesInside customer;
> ...
> {code}
> Now, *With* -X-dv, the following code is generated:
> {code:title=TypeA.java}
> ...
> /*
> *
> */
> protected CustomerTypeWithDefaultValuesInside customer = new
> CustomerTypeWithDefaultValuesInside();
> ...
> {code}
> With the XmlElement annotation missing, the XML instance generated during
> marshalling contains an element {{}}, instead of {{}} -
> which does not correspond to the definition in the XSD and is therefor
> invalid.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3138) Implement better error checking in AbstractXSDToJavaMojo for missing extension fields
[ https://issues.apache.org/jira/browse/CXF-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3138. -- Resolution: Fixed Fix Version/s: 2.3.2 Assignee: Daniel Kulp > Implement better error checking in AbstractXSDToJavaMojo for missing > extension fields > - > > Key: CXF-3138 > URL: https://issues.apache.org/jira/browse/CXF-3138 > Project: CXF > Issue Type: Bug > Components: Tooling >Affects Versions: 2.3.0 >Reporter: David M. Karr >Assignee: Daniel Kulp >Priority: Trivial > Fix For: 2.3.2 > > > Maven POMs can be generated, or they can be hand-coded. It's useful in some > cases to not assume XML microformat conventions are not syntactically correct > in the POM, in case the POM is hand-coded. One case in point: > In "org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo", the "getArguments()" > method assumes the "extension" value is a colon-separated value with three > subfields. If the value is malformed, like missing the last subfield > (version), Maven just fails with "Could not download extension artifact" with > no information. If you then add "-X" to the command line, you'll see this > small additional information: > --- > [ERROR] Failed to execute goal org.apache.cxf:cxf-xjc-plugin:2.3.0:xsdtojava > (generate-sources) on project SunlightDataService-war: Could not download > extension artifact -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.cxf:cxf-xjc-plugin:2.3.0:xsdtojava (generate-sources) on > project SunlightDataService-war: Could not download extension artifact > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) > ... > Caused by: org.apache.maven.plugin.MojoExecutionException: Could not download > extension artifact > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.getArguments(AbstractXSDToJavaMojo.java:274) > ... > Caused by: java.lang.ArrayIndexOutOfBoundsException: 2 > at > org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.getArguments(AbstractXSDToJavaMojo.java:254) > --- > if someone then examined the source for AbstractXSDToJavaMojo, they would > then discover the reference to "s[2]" and hopefully realize that they left > off the version subfield in the "extension" value. > My suggestion is to check the array length and print an error message > indicating the required format of the "extension" value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2701) Make slf4j-jdk14 optional dependency in http-jetty
[ https://issues.apache.org/jira/browse/CXF-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2701. -- Resolution: Fixed Fix Version/s: 2.3.0 Been resolved for a while. > Make slf4j-jdk14 optional dependency in http-jetty > -- > > Key: CXF-2701 > URL: https://issues.apache.org/jira/browse/CXF-2701 > Project: CXF > Issue Type: Bug >Affects Versions: 2.2.5, 2.3.0 >Reporter: Roman Kalukiewicz >Priority: Trivial > Fix For: 2.3.0 > > > slf4j refuses to work properly if two bidings are present, but when I use > cxf-rt-transports-http-jetty artifact in maven it pulls also slf4j-jdk14 (as > it is transitive dependency). > I would like this dependency to be optional, as it really is one of many jars > that someone can choose to use in his own tests (I choose to use > slf4j-log4j12) and such person is forced to exclude slf4j-jdk14. > Another thing is I believe the scope should be 'runtime' as you don't use it > for main/test compilation, but only at runtime. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3202) Have XJC-Util work with both JAXB 2.1 and JAXB 2.2
[
https://issues.apache.org/jira/browse/CXF-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3202.
--
Resolution: Fixed
Fix Version/s: 2.3.2
Assignee: Daniel Kulp
Updating the dependency of the cxf-xjc plugin to jaxb 2.1.13 fixes this.
> Have XJC-Util work with both JAXB 2.1 and JAXB 2.2
> --
>
> Key: CXF-3202
> URL: https://issues.apache.org/jira/browse/CXF-3202
> Project: CXF
> Issue Type: Bug
>Reporter: Glen Mazza
>Assignee: Daniel Kulp
>Priority: Minor
> Fix For: 2.3.2
>
>
> When building the CXF-Trunk (mvn install -Pfastinstall) if I have JAXB 2.2
> (jaxb-api.jar) in my JDK 6 endorsed directory the cxf-api build fails
> (possibly others would fail as well) due to the XJC tooling expecting JAXB
> 2.1:
> gma...@gmazza-work:~/dataExt3/opensource/CXF-TRNK/api$ mvn clean install
> -Pfastinstall -e
> + Error stacktraces are turned on.
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Apache CXF API
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting /media/NewDriveExt3/opensource/CXF-TRNK/api/target
> [INFO] [dependency:unpack {execution: unpack-schemas}]
> [INFO] Configured Artifact:
> org.apache.cxf:cxf-common-schemas:2.4.0-SNAPSHOT:jar
> [INFO] Unpacking
> /home/gmazza/.m2/repository/org/apache/cxf/cxf-common-schemas/2.4.0-SNAPSHOT/cxf-common-schemas-2.4.0-SNAPSHOT.jar
> to
> /media/NewDriveExt3/opensource/CXF-TRNK/api/target/schemas
>with includes null and excludes:null
> [INFO] [cxf-xml2fastinfoset:xml2fastinfoset {execution: xml2fastinfoset}]
> [INFO] [cxf-xjc:xsdtojava {execution: generate-sources}]
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO]
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException
> at
> org.apache.cxf.maven_plugin.AbstractXSDToJavaMojo.execute(AbstractXSDToJavaMojo.java:230)
> at
> org.apache.cxf.maven_plugin.XSDToJavaMojo.execute(XSDToJavaMojo.java:38)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.cxf.xjc.dv.DefaultValuePlugin.updateSetter(DefaultValuePlugin.java:365)
> at
> org.apache.cxf.xjc.dv.DefaultValuePlugin.run(DefaultValuePlugin.java:165)
> at
> com.sun.tools.xjc.addon.apache_cxf.dv.DefaultValuePlugin.run(DefaultValuePlugin.java:59)
> at com.sun.tools.xjc.model.Model.generateCode(Model.java:290)
> at com.sun.tools.xjc.Driver.run(Driver.java:343)
> at com.sun.tools
[jira] Assigned: (CXF-3193) CachingXmlEventWriter.NSContext supports only one prefix for a namespace (backed by map)
[ https://issues.apache.org/jira/browse/CXF-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-3193: Assignee: Daniel Kulp > CachingXmlEventWriter.NSContext supports only one prefix for a namespace > (backed by map) > > > Key: CXF-3193 > URL: https://issues.apache.org/jira/browse/CXF-3193 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.3.2 > Environment: redhat tomcat >Reporter: Peter >Assignee: Daniel Kulp >Priority: Minor > Original Estimate: 1h > Remaining Estimate: 1h > > CachingXmlEventWriter.NSContext supports only one prefix for a namespace. As > a result we have DOUBLE declaration of the SAMEprefix in an element (output > xml). We use xmlbeans binding so that org.apache.cxf.xmlbeans.DataWriterImpl > uses StaxUtils.copy. This StaxUtils.copy.writeStartElement writes namespaces > from elements and attributes. If we have many different prefixes for the same > namespace and the prefixes are used also in attributes then > StaxUtils.copy.writeStartElement outputs DOUBLE declaration: > input > > output > > invalid: double a:xmlns="test" declaration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3193) CachingXmlEventWriter.NSContext supports only one prefix for a namespace (backed by map)
[ https://issues.apache.org/jira/browse/CXF-3193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3193. -- Resolution: Fixed Fix Version/s: 2.3.2 > CachingXmlEventWriter.NSContext supports only one prefix for a namespace > (backed by map) > > > Key: CXF-3193 > URL: https://issues.apache.org/jira/browse/CXF-3193 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.3.2 > Environment: redhat tomcat >Reporter: Peter >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.3.2 > > Original Estimate: 1h > Remaining Estimate: 1h > > CachingXmlEventWriter.NSContext supports only one prefix for a namespace. As > a result we have DOUBLE declaration of the SAMEprefix in an element (output > xml). We use xmlbeans binding so that org.apache.cxf.xmlbeans.DataWriterImpl > uses StaxUtils.copy. This StaxUtils.copy.writeStartElement writes namespaces > from elements and attributes. If we have many different prefixes for the same > namespace and the prefixes are used also in attributes then > StaxUtils.copy.writeStartElement outputs DOUBLE declaration: > input > > output > > invalid: double a:xmlns="test" declaration -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-1710) WSDL endpoint address incorrect when publishing similar endpoints through a servlet
[
https://issues.apache.org/jira/browse/CXF-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-1710:
-
Fix Version/s: NeedMoreInfo
This issue seems to be fixed now. I cannot reproduce it with the latest
wsdl_first code using the instructions above.
> WSDL endpoint address incorrect when publishing similar endpoints through a
> servlet
> ---
>
> Key: CXF-1710
> URL: https://issues.apache.org/jira/browse/CXF-1710
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.1.1
> Environment: Tomcat 6.0.16.
>Reporter: Kim
>Priority: Minor
> Fix For: NeedMoreInfo
>
>
> This issue is very similar to the problem described in issue CXF-793, but
> that is supposed to have been fixed in 2.0.4.
> This issue might relate to the use of servlets.
> When multiple published endpoints use the same WSDL, the served WSDLs (?wsdl)
> don't get the correct endpoint adress.
> I am subclassing CXFServlet and deploy multiple endpoints using the API as
> described in the docs:
>Endpoint.publish("/Greeter", new GreeterImpl());
>Endpoint.publish("/Greeter2", new GreeterImpl());
> In all the endpoints, the generated WSDL specifies soap:address location
> pointing to the last endpoint listed in the service list.
> The same happens using cxf-servlet.xml.
> Steps to reproduce:
> - Use sample "wsdl_first"
> - Edit cxf-servlet.xml: duplicate the section, change id and
> address in the copy
> - Build WAR
> - Deploy on Tomcat
> - Check the generated WSDLs
> The WSDLs are supposed to point to different adresses, right?
> In my test they don't.
> Regards,
> -- Kim
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-1710) WSDL endpoint address incorrect when publishing similar endpoints through a servlet
[
https://issues.apache.org/jira/browse/CXF-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-1710.
--
Resolution: Fixed
Please reopen if a new testcase can be produced.
> WSDL endpoint address incorrect when publishing similar endpoints through a
> servlet
> ---
>
> Key: CXF-1710
> URL: https://issues.apache.org/jira/browse/CXF-1710
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.1.1
> Environment: Tomcat 6.0.16.
>Reporter: Kim
>Priority: Minor
> Fix For: NeedMoreInfo
>
>
> This issue is very similar to the problem described in issue CXF-793, but
> that is supposed to have been fixed in 2.0.4.
> This issue might relate to the use of servlets.
> When multiple published endpoints use the same WSDL, the served WSDLs (?wsdl)
> don't get the correct endpoint adress.
> I am subclassing CXFServlet and deploy multiple endpoints using the API as
> described in the docs:
>Endpoint.publish("/Greeter", new GreeterImpl());
>Endpoint.publish("/Greeter2", new GreeterImpl());
> In all the endpoints, the generated WSDL specifies soap:address location
> pointing to the last endpoint listed in the service list.
> The same happens using cxf-servlet.xml.
> Steps to reproduce:
> - Use sample "wsdl_first"
> - Edit cxf-servlet.xml: duplicate the section, change id and
> address in the copy
> - Build WAR
> - Deploy on Tomcat
> - Check the generated WSDLs
> The WSDLs are supposed to point to different adresses, right?
> In my test they don't.
> Regards,
> -- Kim
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (CXF-3237) CXF Client connection refused error
CXF Client connection refused error
---
Key: CXF-3237
URL: https://issues.apache.org/jira/browse/CXF-3237
Project: CXF
Issue Type: Bug
Components: Core
Affects Versions: 2.3.1
Environment: OS: Windows Vista
Reporter: Kamlesh Bhatt
Hello,
I have written a simple(cxf based) web service. When I try to access it
from(cxf based web service) client, I am getting the connection refused error.
My web service is as follows:
@WebService
public interface ITest {
String sayHi(String name);
}
@WebService(targetNamespace ="http://tv.socialkast.ws";, name="socialkastSOAP")
public class Test implements ITest {
@Override
public String sayHi(String name) {
return "Hi "+name;
}
}
Client code is as follows
JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
Client client =
dcf.createClient("http://localhost:8080/socialkast-web/skservice/skservice?wsdl";);
Object[] results = client.invoke("sayHi", "kamlesh");
String result = (String)results[0];
When I run this client, I am getting the "connection refused" error. I am
invoking this client code from swing UI button click action. I am using cxf
version 2.3.1.
Please note I am able to access the wsdl at above url from browser.
Following is the exception stack of the client.
INFO: Pre-instantiating singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@2d13c1:
defining beans
[cxf,org.apache.cxf.bus.spring.BusApplicationListener,org.apache.cxf.bus.spring.BusWiringBeanFactoryPostProcessor,org.apache.cxf.bus.spring.Jsr250BeanPostProcessor,org.apache.cxf.bus.spring.BusExtensionPostProcessor,org.apache.cxf.resource.ResourceManager,org.apache.cxf.configuration.Configurer,org.apache.cxf.binding.BindingFactoryManager,org.apache.cxf.transport.DestinationFactoryManager,org.apache.cxf.transport.ConduitInitiatorManager,org.apache.cxf.wsdl.WSDLManager,org.apache.cxf.phase.PhaseManager,org.apache.cxf.workqueue.WorkQueueManager,org.apache.cxf.buslifecycle.BusLifeCycleManager,org.apache.cxf.endpoint.ServerRegistry,org.apache.cxf.endpoint.ServerLifeCycleManager,org.apache.cxf.endpoint.ClientLifeCycleManager,org.apache.cxf.transports.http.QueryHandlerRegistry,org.apache.cxf.endpoint.EndpointResolverRegistry,org.apache.cxf.headers.HeaderManager,org.apache.cxf.catalog.OASISCatalogManager,org.apache.cxf.endpoint.ServiceContractResolverRegistry,org.apache.cxf.binding.corba.CorbaBindingFactory,org.apache.cxf.binding.corba.wsdl.WSDLExtensionRegister#0,org.apache.cxf.jaxws.context.WebServiceContextResourceResolver,org.apache.cxf.jaxws.context.WebServiceContextImpl,org.apache.cxf.binding.soap.SoapBindingFactory,org.apache.cxf.binding.soap.SoapTransportFactory,org.apache.cxf.binding.soap.customEditorConfigurer,org.apache.cxf.binding.xml.XMLBindingFactory,org.apache.cxf.ws.addressing.policy.AddressingAssertionBuilder,org.apache.cxf.ws.addressing.policy.AddressingPolicyInterceptorProvider,org.apache.cxf.ws.addressing.policy.UsingAddressingAssertionBuilder,org.apache.cxf.javascript.JavascriptQueryHandlerRegistry,org.apache.cxf.transport.local.LocalTransportFactory,org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder,org.apache.cxf.transport.http.policy.HTTPServerAssertionBuilder,org.apache.cxf.transport.http.policy.NoOpPolicyInterceptorProvider,org.apache.cxf.transport.http.ClientOnlyHTTPTransportFactory,org.apache.cxf.management.InstrumentationManager,org.apache.cxf.transport.http_jetty.JettyHTTPTransportFactory,org.apache.cxf.transport.jms.JMSTransportFactory,org.apache.cxf.binding.object.ObjectBindingFactory,org.apache.cxf.binding.http.HttpBindingFactory,org.apache.cxf.ws.security.policy.WSSecurityPolicyLoader,org.apache.cxf.ws.policy.AssertionBuilderRegistry,org.apache.cxf.ws.policy.PolicyInterceptorProviderRegistry,org.apache.cxf.ws.policy.attachment.external.DomainExpressionBuilderRegistry,org.apache.cxf.ws.policy.attachment.external.EndpointReferenceDomainExpressionBuilder,org.apache.cxf.ws.policy.PolicyBuilder,org.apache.cxf.ws.policy.PolicyEngine,org.apache.cxf.ws.policy.attachment.wsdl11.Wsdl11AttachmentPolicyProvider,org.apache.cxf.ws.policy.attachment.ServiceModelPolicyProvider,org.apache.cxf.ws.policy.mtom.MTOMAssertionBuilder,org.apache.cxf.ws.policy.mtom.MTOMPolicyInterceptorProvider,org.apache.cxf.ws.rm.RMManager,org.apache.cxf.ws.rm.policy.RMPolicyInterceptorProvider,org.apache.cxf.ws.rm.RMAssertionBuilder,org.apache.cxf.binding.corba.wsdl.WSDLExtensionRegister#1];
root of factory hierarchy
org.apache.cxf.service.factory.ServiceConstructionException: Could not resolve
URL "http://localhost:8080/socialkast-web/skservice/skservice?wsdl";.
at
org.apache.cxf.endpoint.dynamic.DynamicClientFactory.composeUrl(DynamicClientFactory.java:566)
at
org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:253)
at
org.apache.cxf.endpoint.dynamic.DynamicClientFactory.
[jira] Resolved: (CXF-3165) SUN_TOOL_PATH references legacy vendor
[ https://issues.apache.org/jira/browse/CXF-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3165. -- Resolution: Fixed Fix Version/s: 2.3.2 Assignee: Daniel Kulp I just renamed it to TOOLS_JAR (applicable to IBM jdk as well). Also updated the text around the require JDK version. > SUN_TOOL_PATH references legacy vendor > -- > > Key: CXF-3165 > URL: https://issues.apache.org/jira/browse/CXF-3165 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.3.0 >Reporter: Robert Liguori >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.3.2 > > > Consider the Identifier SUN_TOOL_PATH in the tool scripts. > Sun (as in SUN_TOOL_PATH) is now Oracle... this wasn't a good idea of putting > the vendor's name in the the identifier name. > Consider renaming SUN_TOOL_PATH to JAVA_SE_TOOL_PATH or something similar. > Of course, Java SE is for JDK 1.6 and J2SE is for JDK 1.5. > TOOL_PATH by itself, leaves confusion as the assumption may be for the CXF > tool path, thus why SUN was probably added in the first place. > The recommendation is to make the update in all of the tool scripts (e.g. > wsdl2java). > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-3164) "echo ERROR: Set JAVA_HOME to the path where the J2SE 5.0 (JDK5.0) is installed" doesn't mention Java SE 6
[ https://issues.apache.org/jira/browse/CXF-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3164. -- Resolution: Fixed Fix Version/s: 2.3.2 Assignee: Daniel Kulp > "echo ERROR: Set JAVA_HOME to the path where the J2SE 5.0 (JDK5.0) is > installed" doesn't mention Java SE 6 > -- > > Key: CXF-3164 > URL: https://issues.apache.org/jira/browse/CXF-3164 > Project: CXF > Issue Type: Improvement >Affects Versions: 2.3.0 >Reporter: Robert Liguori >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.3.2 > > > Consider the following message seen in the tool script files (e.g., > wsdl2java): > :no_java_home > echo ERROR: Set JAVA_HOME to the path where the J2SE 5.0 (JDK5.0) is > installed > goto end > First off, J2SE 5.0 is relative to JDK 1.5 (not JDK 5.0). Also, J2SE 5.0 is > EOSL as of October 2009 > (http://www.oracle.com/technetwork/java/eol-135779.html). > Anyway, I think the message is misleading since it's specifying JDK 1.5, > makes one wonder, does the tool(s) work with JDK 1.6. We do know that they > do, so the message is incomplete. I guess the message was created to imply > that 1.4 is not supported, and this was probably done prior to JDK 1.6 being > released. > My recommendation: I would change the message in all of the scripts to > something like this: > :no_java_home > echo ERROR: Set JAVA_HOME to the path where J2SE 5.0 or later is installed > goto end > Also, it looks like the windows batch file equivalences do not show this > message at all... consider adding it to all of the batch files as well. > Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
