[jira] [Updated] (CXF-2193) Allow for WRAPPED style code generation for "wrapper elements" with xsd:extension of a wrapper-compatible type
[ https://issues.apache.org/jira/browse/CXF-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated CXF-2193: - Fix Version/s: 2.3.5 2.4.1 > Allow for WRAPPED style code generation for "wrapper elements" with > xsd:extension of a wrapper-compatible type > -- > > Key: CXF-2193 > URL: https://issues.apache.org/jira/browse/CXF-2193 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 2.1.2 >Reporter: Eric Sirianni >Assignee: jimma > Fix For: 2.4.1, 2.3.5 > > > JAX-WS Spec: > 2.3.1.2 Wrapper Style > > A WSDL operation qualifies for wrapper style mapping only if the following > criteria are met: >(i) The operation's input and output messages (if present) each contain > only a single part > (ii) The input message part refers to a global element declaration whose > localname is equal to the operation name > > (iii) The output message part refers to a global element declaration > > (iv) The elements referred to by the input and output message parts > (henceforth referred to as wrapper >elements) are both complex types defined using the xsd:sequence > compositor > (v) The wrapper elements only contain child elements, they must not contain > other structures such as >wildcards (element or attribute), xsd:choice, substitution groups > (element references are not per- >mitted) or attributes; furthermore, they must not be nillable. > CXF wsdl2java does not encode the following as > SOAPBinding.ParameterStyle.WRAPPED: > > > > > > > > > > > > > > > > > ... > According to the JAX-WS spec, I don't understand why CXF cannot generate > WRAPPED style code for this construct -- namely xsd:extension of a type that > is already "Wrapped-compliant". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3547) Enable http proxy support in the cxf-codegen-plugin for retrieval of WSDL files through the java.net.URL class
Enable http proxy support in the cxf-codegen-plugin for retrieval of WSDL files through the java.net.URL class -- Key: CXF-3547 URL: https://issues.apache.org/jira/browse/CXF-3547 Project: CXF Issue Type: Improvement Components: Tooling Affects Versions: 2.4 Environment: Java, WSDL2Java Reporter: Mark Wolfe Currently this plugin ignores the proxy server configured in maven and requires you to pass in a http.proxyHost and http.proxyPort variables. It would be nice if it used the maven configuration to ensure these variables were set before using the java.net.URL class to retrieve the WSDL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3547) Enable http proxy support in the cxf-codegen-plugin for retrieval of WSDL files through the java.net.URL class
[ https://issues.apache.org/jira/browse/CXF-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039029#comment-13039029 ] Mark Wolfe commented on CXF-3547: - I am going to investigate it a bit futher and build up a patch to resolve this issue. > Enable http proxy support in the cxf-codegen-plugin for retrieval of WSDL > files through the java.net.URL class > -- > > Key: CXF-3547 > URL: https://issues.apache.org/jira/browse/CXF-3547 > Project: CXF > Issue Type: Improvement > Components: Tooling >Affects Versions: 2.4 > Environment: Java, WSDL2Java >Reporter: Mark Wolfe > > Currently this plugin ignores the proxy server configured in maven and > requires you to pass in a http.proxyHost and http.proxyPort variables. It > would be nice if it used the maven configuration to ensure these variables > were set before using the java.net.URL class to retrieve the WSDL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-3548) EndPointImpl's hasCode value should not change when its mutable properties are changed
EndPointImpl's hasCode value should not change when its mutable properties are changed -- Key: CXF-3548 URL: https://issues.apache.org/jira/browse/CXF-3548 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.3.4, 2.4 Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 2.4.1, 2.3.5 The current implementation of hashCode() simply calls HashMap's hashCode(). Consequently, the hashCode changes whenever some changes occur in this property table. The endpoint's hashCode should be calculated on the immutable part to avoid confusion as the following abnormality can be observed: Endpoint ep = ... map = new HashMap<...>(); map.put(ep, "A"); assertNotNull(map.get(ep)); // okay ep.put(USING_ADDRESSING, b); assertEquals(ep, map.keySet().iterator().next()); // okay assertNotNull(map.get(ep)); // error This issue was discussed in dev@cxf: http://cxf.547215.n5.nabble.com/org-apache-cxf-endpoint-EndpointImpl-may-not-be-used-as-a-hash-map-key-td4393354.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-3526) Aegis cannot handle nested map inheritance
[
https://issues.apache.org/jira/browse/CXF-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-3526:
-
Assignee: Freeman Fang
> Aegis cannot handle nested map inheritance
> --
>
> Key: CXF-3526
> URL: https://issues.apache.org/jira/browse/CXF-3526
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.3.3
> Environment: Debian GNU/Linux tomcat 6
>Reporter: Vassilis Virvilis
>Assignee: Freeman Fang
> Attachments: ws-test.tgz
>
>
> The following code fails when trying to retrieve data with the simple fronted
> public class ComplexMapResult extends
> HashMap> {
> }
> // fail returns null map value
> public ComplexMapResult testComplexMapResult();
> How it fails. On retrieve when I try to print the resulting matrix I get
> INFO: client.TestClient.testComplexMapResult(TestClient.java:35):
> {key1=[#document: null]}
> where I should get a valid map for the key "key1"
> The following code succeeds
> // success
> public Map> testDirectComplexMapResult();
> So my guess is Aegis doesn't handle the inheritance very well.
> Further more the following code succeeds
> // success
> public class SimpleMapResult extends HashMap {
> }
> // success
> public SimpleMapResult testSimpleMapResult();
> so that means it handles the extension when there is no nesting
> I will try to attach the eclipse project for this (~7k)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3526) Aegis cannot handle nested map inheritance
[
https://issues.apache.org/jira/browse/CXF-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039056#comment-13039056
]
Freeman Fang commented on CXF-3526:
---
Hi,
As the super class HashMap> of ComplexMapResult
isn't directly visible by reflection of the service interface, so actually this
is the expected behavior, the solution(as described from[1],Using Java Classes
That Aren't Visible to the Service Interface) is declare the method signature
using base type(HashMap> for your case)
So the code should be
{code}
Map> testComplexMapResult();
{code}
in interface
and
{code}
public Map> testComplexMapResult() {
ComplexMapResult result
= new ComplexMapResult();
Map map1 = new HashMap();
map1.put(1, 3);
result.put("key1", map1);
return result;
}
{code}
in impl class.
Anyway, I'm going to commit a testcase to demonstrate how it works.
[1]http://cxf.apache.org/docs/aegis-21.html
Freeman
> Aegis cannot handle nested map inheritance
> --
>
> Key: CXF-3526
> URL: https://issues.apache.org/jira/browse/CXF-3526
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.3.3
> Environment: Debian GNU/Linux tomcat 6
>Reporter: Vassilis Virvilis
>Assignee: Freeman Fang
> Attachments: ws-test.tgz
>
>
> The following code fails when trying to retrieve data with the simple fronted
> public class ComplexMapResult extends
> HashMap> {
> }
> // fail returns null map value
> public ComplexMapResult testComplexMapResult();
> How it fails. On retrieve when I try to print the resulting matrix I get
> INFO: client.TestClient.testComplexMapResult(TestClient.java:35):
> {key1=[#document: null]}
> where I should get a valid map for the key "key1"
> The following code succeeds
> // success
> public Map> testDirectComplexMapResult();
> So my guess is Aegis doesn't handle the inheritance very well.
> Further more the following code succeeds
> // success
> public class SimpleMapResult extends HashMap {
> }
> // success
> public SimpleMapResult testSimpleMapResult();
> so that means it handles the extension when there is no nesting
> I will try to attach the eclipse project for this (~7k)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3526) Aegis cannot handle nested map inheritance
[
https://issues.apache.org/jira/browse/CXF-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-3526.
---
Resolution: Fixed
Fix Version/s: 2.3.5
2.4.1
not a real fix but a testcase demonstrate how to use inherited nested map with
aegis databinding
http://svn.apache.org/viewvc?rev=1127459&view=rev for trunk
http://svn.apache.org/viewvc?rev=1127464&view=rev for 2.3.x branch
> Aegis cannot handle nested map inheritance
> --
>
> Key: CXF-3526
> URL: https://issues.apache.org/jira/browse/CXF-3526
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.3.3
> Environment: Debian GNU/Linux tomcat 6
>Reporter: Vassilis Virvilis
>Assignee: Freeman Fang
> Fix For: 2.4.1, 2.3.5
>
> Attachments: ws-test.tgz
>
>
> The following code fails when trying to retrieve data with the simple fronted
> public class ComplexMapResult extends
> HashMap> {
> }
> // fail returns null map value
> public ComplexMapResult testComplexMapResult();
> How it fails. On retrieve when I try to print the resulting matrix I get
> INFO: client.TestClient.testComplexMapResult(TestClient.java:35):
> {key1=[#document: null]}
> where I should get a valid map for the key "key1"
> The following code succeeds
> // success
> public Map> testDirectComplexMapResult();
> So my guess is Aegis doesn't handle the inheritance very well.
> Further more the following code succeeds
> // success
> public class SimpleMapResult extends HashMap {
> }
> // success
> public SimpleMapResult testSimpleMapResult();
> so that means it handles the extension when there is no nesting
> I will try to attach the eclipse project for this (~7k)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3526) Aegis cannot handle nested map inheritance
[
https://issues.apache.org/jira/browse/CXF-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039127#comment-13039127
]
Vassilis Virvilis commented on CXF-3526:
Looks like that I missed the documentation.
Do you think that it would be possible to give a warning when that happens
during deploy so the user can tell when something goes wrong from the logs and
not wait the runtime to see the problem.
Thanks
> Aegis cannot handle nested map inheritance
> --
>
> Key: CXF-3526
> URL: https://issues.apache.org/jira/browse/CXF-3526
> Project: CXF
> Issue Type: Bug
> Components: Aegis Databinding
>Affects Versions: 2.3.3
> Environment: Debian GNU/Linux tomcat 6
>Reporter: Vassilis Virvilis
>Assignee: Freeman Fang
> Fix For: 2.4.1, 2.3.5
>
> Attachments: ws-test.tgz
>
>
> The following code fails when trying to retrieve data with the simple fronted
> public class ComplexMapResult extends
> HashMap> {
> }
> // fail returns null map value
> public ComplexMapResult testComplexMapResult();
> How it fails. On retrieve when I try to print the resulting matrix I get
> INFO: client.TestClient.testComplexMapResult(TestClient.java:35):
> {key1=[#document: null]}
> where I should get a valid map for the key "key1"
> The following code succeeds
> // success
> public Map> testDirectComplexMapResult();
> So my guess is Aegis doesn't handle the inheritance very well.
> Further more the following code succeeds
> // success
> public class SimpleMapResult extends HashMap {
> }
> // success
> public SimpleMapResult testSimpleMapResult();
> so that means it handles the extension when there is no nesting
> I will try to attach the eclipse project for this (~7k)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3491) can't refer to java.lang.Exception in gererated client/server main code
[ https://issues.apache.org/jira/browse/CXF-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039152#comment-13039152 ] Daniel Kulp commented on CXF-3491: -- Nabble is being very slow getting the message to the list In anycase, the Exception naming is per JAX-WS spec and not really anything we can do about it. You can use a JAX-WS binding file to customize the exception name. That should work. > can't refer to java.lang.Exception in gererated client/server main code > --- > > Key: CXF-3491 > URL: https://issues.apache.org/jira/browse/CXF-3491 > Project: CXF > Issue Type: Bug > Components: Tooling >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 2.4.1, 2.3.5 > > > This is related to CXF-3353, but problem exposed when pass in "all" flag > which will generate client and server main process class which should refer > java.lang.Exception also -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3529) Support for Map Interface in CXF Service and Beans
[
https://issues.apache.org/jira/browse/CXF-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Biju Nair updated CXF-3529:
---
Attachment: InjectionUtils_052511.patch
Patch for Map Support
> Support for Map Interface in CXF Service and Beans
> --
>
> Key: CXF-3529
> URL: https://issues.apache.org/jira/browse/CXF-3529
> Project: CXF
> Issue Type: New Feature
> Components: Core
>Affects Versions: 2.4.1
> Environment: All platforms
>Reporter: Biju Nair
> Labels: java.util.map, map
> Fix For: 2.4.1
>
> Attachments: InjectionUtils.java, InjectionUtils.java,
> InjectionUtils_052511.patch, JAXRSUtils.java, config, cxf-3529.diff
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> Apache CXF Rest Services doesn't support java.util.Map interface as their
> service arguments. They even do not support java.util.Map interface inside a
> bean.
> This fix is to support Map interface as arguments and fields inside a bean.
> > The code is tested with sample services like,
> > public String debug(@FormParam("")TestEmployeeTO
> > testObject1,@FormParam("map") Map map)
> >
> > public class TestEmployeeTO {
> >
> > private HashMap currencies;
> >
> > //getters/setters
> > }
> > Input Data
> > map.x=11&map.y=9¤cies.IND=INR¤cies.USA=DOLLAR
> > Output
> > TestEmployeeTO[currencies={IND=INR, USA=DOLLAR}]
> > map={y=9, x=11}
> >
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3539) NPE when sending packet to STS using default namespaces instead of namespace prefixes
[ https://issues.apache.org/jira/browse/CXF-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3539. -- Resolution: Fixed Fix Version/s: 2.3.5 2.4.1 Assignee: Daniel Kulp It looks like "" is the right thing to do so I've changed it to do that. > NPE when sending packet to STS using default namespaces instead of namespace > prefixes > - > > Key: CXF-3539 > URL: https://issues.apache.org/jira/browse/CXF-3539 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.4 >Reporter: Alistair Phipps >Assignee: Daniel Kulp > Labels: Exception, NPE > Fix For: 2.4.1, 2.3.5 > > > common/common/src/main/java/org/apache/cxf/staxutils/StaxSource#getAttributes() > sets the "localname" to null for default namespaces changes. However, when > this is set it causes JAXB binding to throw an NPE in > com.sun.xml.internal.bind.v2.util.QNameMap.hash(). This occurs when creating > an STS using the CXF STS provider framework and sending a RST packet which > uses default namespaces instead of namespace prefixes. > A workaround that seems to work for the STS is setting the localname to "" > instead of null, however I'm not sure what other effects that might have. > Example packet: > http://schemas.xmlsoap.org/soap/envelope/"; > xmlns:s="http://www.w3.org/2001/XMLSchema"; > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"; > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";> > xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > > wsu:Id="Timestamp">2011-05-19T20:25:45.197Z2011-05-19T20:30:45.197Z > EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"; > > ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"; > wsu:Id="SecurityToken">...snip... xmlns="http://www.w3.org/2000/09/xmldsig#";> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> URI="#Timestamp"> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>...snip..snip... > xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";> URI="#SecurityToken" > ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/> xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"; > xmlns:s="http://www.w3.org/2001/XMLSchema"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy";> xmlns="http://www.w3.org/2005/08/addressing";>...snip...http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey256 > Example stacktrace: > java.lang.NullPointerException > at com.sun.xml.internal.bind.v2.util.QNameMap.hash(QNameMap.java:201) > at > com.sun.xml.internal.bind.v2.util.QNameMap.getEntry(QNameMap.java:452 > ) > at com.sun.xml.internal.bind.v2.util.QNameMap.get(QNameMap.java:147) > [note: 2nd param(s1) = null] > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.StructureLoader.sta > rtElement(StructureLoader.java:187) > [note: s1 = attributes.getLocalName(i); . = null] > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.ProxyLoader.startEl > ement(ProxyLoader.java:44) > at > com.sun.xml.internal.bind.v2.runtime.ElementBeanInfoImpl$IntercepterL > oader.startElement(ElementBeanInfoImpl.java:226) > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContex > t._startElement(UnmarshallingContext.java:470) > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContex > t.startElement(UnmarshallingContext.java:448) > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.InterningXmlVisitor > .startElement(InterningXmlVisitor.java:60) > at > com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.startE > lement(SAXConnector.java:137) > at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:138) > at org.apache.cxf.staxutils.StaxSource.parse(StaxSource.java:270) > at > com
[jira] [Resolved] (CXF-3467) apache-cxf-2.4.0-src: minor issue when used with Eclipse 3.5.2: helloWorldSoapHttp created all llowercase in code, and M2_REPO classpath variable missing in Eclipse
[ https://issues.apache.org/jira/browse/CXF-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3467. -- Resolution: Fixed Assignee: Daniel Kulp Changed the package names for the xmlbeans and jibx generated stuff to not have them in the same package, just with different case. > apache-cxf-2.4.0-src: minor issue when used with Eclipse 3.5.2: > helloWorldSoapHttp created all llowercase in code, and M2_REPO classpath > variable missing in Eclipse > > > Key: CXF-3467 > URL: https://issues.apache.org/jira/browse/CXF-3467 > Project: CXF > Issue Type: Bug > Components: OSGi >Affects Versions: 2.4 > Environment: Windows XP > JDK 1.6.0_24 > apache-maven-2.2.1 > Eclipse 3.5.2 Galileo SR2 >Reporter: Runo Barrdahl >Assignee: Daniel Kulp >Priority: Minor > Fix For: 2.4 > > > The following procedure was followed when installing apache-cxf-2.4.0-src: > 1. Expansion of zip to C:\apache-cxf-2.4.0-src > 2. @mvn -Pfastinstall > 3. @mvn -Psetup.eclipse > -Declipse.workspace.dir=C:/eclipse-workspaces/3.5.2_Galileo-SR2/Eclipse_CXF > 4. Import into Eclipse of all projects in C:\apache-cxf-2.4.0-src > 5. Then 2 errors appear: a) class path variable M2_REPO is referred to but > not present in Eclipse, so it had to be manually added. b) inconsistency in > java code of Eclipse project cxf-systests-databinding, such that > helloWorldSoapHttp is in lowercase in references to imported packages. > Details of error: > C:\apache-cxf-2.4.0-src\systests\databinding\target\generated\src\test\java\jibx_bindings\hello_world.xml: > helloworldsoaphttp is all lowercase, while in Eclipse, created Java is > helloWorldSoapHttp - that causes errors in eclipse. See also: > C:\apache-cxf-2.4.0-src\systests\databinding\target\generated\src\test\java\org\apache, > and > C:\apache-cxf-2.4.0-src\systests\databinding\target\test-classes\schemaorg_apache_xmlbeans > For more information, don't hesistate to contact me by mail. > Best Regards, Runo Barrdahl -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3169) Duplicate declaration for namespace prefix 'tns'
[
https://issues.apache.org/jira/browse/CXF-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3169.
--
Resolution: Incomplete
Fix Version/s: (was: NeedMoreInfo)
Invalid
Assignee: Daniel Kulp
No response to query for more information in over a month. Marking resolved as
incomplete.
> Duplicate declaration for namespace prefix 'tns'
>
>
> Key: CXF-3169
> URL: https://issues.apache.org/jira/browse/CXF-3169
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP, Server 2003, 2008. WebSphere Portal, WebLogic
>Reporter: Mark Brewer
>Assignee: Daniel Kulp
> Fix For: Invalid
>
>
> Receiving the following error:
> [12/6/10 17:05:28:140 EST] 0068 PhaseIntercep I Interceptor has thrown
> exception, unwinding now Unmarshalling Error: Duplicate declaration for
> namespace prefix 'tns'.
> at [row,col {unknown-source}]: [1,506]
> [12/6/10 17:05:28:187 EST] 0068 DispatcherPor E
> org.springframework.web.portlet.FrameworkPortlet processRequest Could not
> complete request
> javax.xml.ws.WebServiceException:
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: Duplicate declaration
> for namespace prefix 'tns'.
> at [row,col {unknown-source}]: [1,506]
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:142)
> at $Proxy1218.retrieveRegionList(Unknown Source)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-2686) CXF on WAS 6.1
[ https://issues.apache.org/jira/browse/CXF-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-2686. -- Resolution: Incomplete Fix Version/s: (was: NeedMoreInfo) Invalid Assignee: Daniel Kulp Asked for stack traces and more information. No response in over a month. Closing. > CXF on WAS 6.1 > -- > > Key: CXF-2686 > URL: https://issues.apache.org/jira/browse/CXF-2686 > Project: CXF > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2.6 > Environment: Windows XP and AIX > WAS 6.1.0.27 (no WS feature pack) >Reporter: Stéphane Landelle >Assignee: Daniel Kulp > Fix For: Invalid > > > I don't know if creating an issue is the right thing to do or if I should > just post on the mailing list. > Sorry if I'm wrong. > I tried to deploy CXF 2.2.6 on WAS 6.1.0.27 (no WS feature pack) with the > configuration detailed in the user guide, but it wouldn't work and I still > got CNFE on javax.xml.transform.stax.StAXResult. > I finally managed to deploy successfully with the following configuration > (much simplier than the one in the user guide) : > 1) have jaxp-api and jaxp-ri inside the WAR (check you don't have any double, > such as jsr173_api, stax-api or geronimo-stax-api) > 2) create a shared lib with wsdl4j > 3) create a classloader on the server with this shared lib, set as PARENT_LAST > 4) configure the WAR classloader as PARENT_LAST > If this configuration is confirmed, the user guide should be updated. > Sincerely, > Stephane Landelle -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-2772) CLONE -OutOfMemoryError with many service endpoints
[
https://issues.apache.org/jira/browse/CXF-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2772.
--
Resolution: Fixed
Fix Version/s: (was: NeedMoreInfo)
2.4
Assignee: Daniel Kulp
Marking this resolved. I believe it's fixed, but a request for an updated
test run has gone unanswered for over a month.
> CLONE -OutOfMemoryError with many service endpoints
> ---
>
> Key: CXF-2772
> URL: https://issues.apache.org/jira/browse/CXF-2772
> Project: CXF
> Issue Type: Bug
>Affects Versions: 2.2.6
> Environment: Windows XP, Sun JDK 1.6, Tomcat 6.0.20
>Reporter: Aditya Gujrathi
>Assignee: Daniel Kulp
> Labels: TomcatWS
> Fix For: 2.4
>
> Attachments: VisualVM-ServerStartup1.jpg
>
>
> I am deploying 5 WAR files in my Tomcat server. They together expose multiple
> endpoints (60+), each of which publish a simple WSDL.
> When the server is started, performance with many concurrent service calls
> degrades and memory consumption increases steadily, ultimately leading to an
> OutOfMemoryException.
> In a simple test it showed that simply displaying the service endpoints
> exposed WSDL in the browser is sufficient to trigger the OutOfMemoryError.
> Earlier, our application was using JAXWS and it used to work fine.
> Screenshot using jVisualVM is attached. Following is the exception stacktrace:
> {code}
> WARNING: Application
> {http://schemas.xmlsoap.org/ws/2004/08/eventing}ws-eventing-service#{http://schemas.xmlsoap.org/ws/2004/08/eventing}SubscribeOp
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Java heap space
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:155)
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:85)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:121)
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:60)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:98)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:406)
> 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:637)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
> at java.la
[jira] [Commented] (CXF-3023) WSDL2Java with Xmlbeans, wrong classpath
[
https://issues.apache.org/jira/browse/CXF-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039292#comment-13039292
]
Daniel Kulp commented on CXF-3023:
--
Any chance to get a testcase? That error is caused by not being able to find
the schema type for a message part.I'm really not sure why that would
happen without a wsdl/test case.
> WSDL2Java with Xmlbeans, wrong classpath
>
>
> Key: CXF-3023
> URL: https://issues.apache.org/jira/browse/CXF-3023
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.2.10
>Reporter: Sébastien
> Fix For: NeedMoreInfo
>
> Attachments: Bank.wsdl, stack-trace-xbean.txt,
> stack-trace-xmlbeans-classpath.txt
>
>
> I'm trying to generate Java stubs from WSDL. With JAXB the created code is
> working fine. So, clients generated from WSDL files can connect to web
> services.
> The configuration of the JAXB generator is:
> {code}
>
> org.apache.cxf
> cxf-codegen-plugin
> ${cxf-version}
>
>
> generate-sources
> generate-sources
>
> ${basedir}/src/main/wsdl
>
> *.wsdl
>
>
>
> wsdl2java
>
>
>
>
> {code}
> When I use Xmlbeans instead of JAXB, the source generation succeed, but once
> unit tests are running I got the following exception:
> {code}
> Caused by: java.lang.ClassNotFoundException:
> schemaorg_apache_xmlbeans.system.s14C5C2D1E1AB170E2BDAA0B2E05EA32B.TypeSystemHolder
> {code}
> The plugin configuration is the same (I've also tried to remove the
> markup):
> {code}
>
> org.apache.cxf
> cxf-codegen-plugin
> ${cxf-version}
>
>
> generate-sources
> generate-sources
>
>
>
>
>
> -db
> xmlbeans
>
>
> ${basedir}/src/main/wsdl
>
> *.wsdl
>
>
>
> wsdl2java
>
>
>
>
> {code}
> If there is something wrong during the generation, the generation should say
> something?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3543) wsdl2js creates javascript that does not parse Arrays in Soap response
[
https://issues.apache.org/jira/browse/CXF-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13039295#comment-13039295
]
Daniel Kulp commented on CXF-3543:
--
Nothing in CXF is designed to support the ancient SOAP encoding stuff.Thus,
it doesn't really surprise me that this doesn't work. It's not really
supposed to.
> wsdl2js creates javascript that does not parse Arrays in Soap response
> --
>
> Key: CXF-3543
> URL: https://issues.apache.org/jira/browse/CXF-3543
> Project: CXF
> Issue Type: Bug
> Components: JavaScript Client
>Affects Versions: 2.3.4
> Environment: generic
>Reporter: Alamgir Farouk
> Attachments: AppointmentService.wsdl, AppointmentServiceService.js
>
>
>
>
>
> wsdl:arrayType="tns:ServiceProvider[]" />
>
>
>
> creates the following javascript code
> function urn_AppointmentService_ArrayOfServiceProviders_deserialize
> (cxfjsutils, element) {
> var newobject = new urn_AppointmentService_ArrayOfServiceProviders();
> cxfjsutils.trace('element: ' + cxfjsutils.traceElementName(element));
> var curElement = cxfjsutils.getFirstElementChild(element);
> var item;
> return newobject;
> }
> Note that this method is incomplete, it doesn't even try to parse the
> element, just returns the new object. Is this intentional? Are we supposed to
> fill in the blanks? or is this a but.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3543) wsdl2js creates javascript that does not parse Arrays in Soap response
[
https://issues.apache.org/jira/browse/CXF-3543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3543.
--
Resolution: Invalid
Fix Version/s: Invalid
Assignee: Daniel Kulp
Soap encoded types are not supported by CXF.
> wsdl2js creates javascript that does not parse Arrays in Soap response
> --
>
> Key: CXF-3543
> URL: https://issues.apache.org/jira/browse/CXF-3543
> Project: CXF
> Issue Type: Bug
> Components: JavaScript Client
>Affects Versions: 2.3.4
> Environment: generic
>Reporter: Alamgir Farouk
>Assignee: Daniel Kulp
> Fix For: Invalid
>
> Attachments: AppointmentService.wsdl, AppointmentServiceService.js
>
>
>
>
>
> wsdl:arrayType="tns:ServiceProvider[]" />
>
>
>
> creates the following javascript code
> function urn_AppointmentService_ArrayOfServiceProviders_deserialize
> (cxfjsutils, element) {
> var newobject = new urn_AppointmentService_ArrayOfServiceProviders();
> cxfjsutils.trace('element: ' + cxfjsutils.traceElementName(element));
> var curElement = cxfjsutils.getFirstElementChild(element);
> var item;
> return newobject;
> }
> Note that this method is incomplete, it doesn't even try to parse the
> element, just returns the new object. Is this intentional? Are we supposed to
> fill in the blanks? or is this a but.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-3514) Interaction of JAXWS Handler and WSS4JInInterceptor breaks SOAP Message
[ https://issues.apache.org/jira/browse/CXF-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp reassigned CXF-3514: Assignee: Daniel Kulp > Interaction of JAXWS Handler and WSS4JInInterceptor breaks SOAP Message > --- > > Key: CXF-3514 > URL: https://issues.apache.org/jira/browse/CXF-3514 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime, WS-* Components >Affects Versions: 2.4 > Environment: The java_first_spring_support example. >Reporter: Dirk Rudolph >Assignee: Daniel Kulp > Labels: security > Attachments: SOAPRequestHandler.java, UTPasswordCallback.java, > beans.xml, pom.xml > > > Adding a JAXWS Handler (SOAPHandler implementation) to an endpoint > configuration that uses the WSS4JInInterceptor breaks the recieved > SOAPMessage. This results in missing binding or parameter information while > invoking the webservice methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3514) Interaction of JAXWS Handler and WSS4JInInterceptor breaks SOAP Message
[ https://issues.apache.org/jira/browse/CXF-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-3514. -- Resolution: Fixed Fix Version/s: 2.4.1 I created a whole new phase for the JAX-WS handlers to live in. Thus, this should now be fixed, but if you could run your tests with tomorrows snapshots (or build from trunk), that would be great. > Interaction of JAXWS Handler and WSS4JInInterceptor breaks SOAP Message > --- > > Key: CXF-3514 > URL: https://issues.apache.org/jira/browse/CXF-3514 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime, WS-* Components >Affects Versions: 2.4 > Environment: The java_first_spring_support example. >Reporter: Dirk Rudolph >Assignee: Daniel Kulp > Labels: security > Fix For: 2.4.1 > > Attachments: SOAPRequestHandler.java, UTPasswordCallback.java, > beans.xml, pom.xml > > > Adding a JAXWS Handler (SOAPHandler implementation) to an endpoint > configuration that uses the WSS4JInInterceptor breaks the recieved > SOAPMessage. This results in missing binding or parameter information while > invoking the webservice methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
