[jira] Closed: (CXF-1475) Dynamic client invocation places argument in soap header

2009-04-24 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1475.
-

Resolution: Fixed

> Dynamic client invocation places argument in soap header
> 
>
> Key: CXF-1475
> URL: https://issues.apache.org/jira/browse/CXF-1475
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 2.0.4
> Environment: Windows XP SP2, Java 1.6, generated web service from 
> http://www.xignite.com/xNews.asmx?WSDL
>Reporter: Robert Rapant
>Assignee: Sean O'Callaghan
>
>   DynamicClientFactory dcf = 
> DynamicClientFactory.newInstance();
>   Client client = 
> dcf.createClient("file:src/test/xNews.wsdl");
>   Object[] res = client.invoke("GetStockHeadlines", 
> "MSFT", 3);
> produces: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>   
>   http://www.w3.org/2001/XMLSchema";
>   
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xmlns="http://www.xignite.com/services/"; 
> xsi:type="ns3:int">3
>   
>   
>   
>  xmlns:ns1="http://www.xignite.com/services/";>
>xmlns="http://www.xignite.com/services/";>
>   MSFT
>   
>   
>   
>   
> exception:
> Server was unable to read request. --> There is an error in XML document (1, 
> 85). --> The specified type was not recognized: name='i
> nt', namespace='http://www.w3.org/2001/XMLSchema', at 
xmlns='http://www.xignite.com/services/'>. > In contrast, the direct manner of invocation below works fine: > XigniteNews newsService = new XigniteNews(); > XigniteNewsSoap soap = newsService.getXigniteNewsSoap(); > ArrayOfStockNews newsArray = > soap.getStockHeadlines("MSFT", 3); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.

[jira] Closed: (CXF-1698) WSDL operation null when getting from the SOAPMessageContext

2009-02-25 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1698.
-

Resolution: Fixed

> WSDL operation null when getting from the SOAPMessageContext
> 
>
> Key: CXF-1698
> URL: https://issues.apache.org/jira/browse/CXF-1698
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.1.1
>Reporter: Arulazi Dhesiaseelan
>Assignee: Sean O'Callaghan
>
> The following code on the SoapMessageContext returns null.
> javax.xml.namespace.QName operation = (javax.xml.namespace.QName) 
> smc.get(MessageContext.WSDL_OPERATION);
> I have annotated my web method with operationName tag.  But, still getting 
> null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1475) Dynamic client invocation places argument in soap header

2009-02-23 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675891#action_12675891
 ] 

Sean O'Callaghan commented on CXF-1475:
---

It seems that the Header tag is being mistaken as a SOAPHeader and the int is 
being added into the SOAPHeader. If you change the name from Header the problem 
no longer exists.

> Dynamic client invocation places argument in soap header
> 
>
> Key: CXF-1475
> URL: https://issues.apache.org/jira/browse/CXF-1475
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 2.0.4
> Environment: Windows XP SP2, Java 1.6, generated web service from 
> http://www.xignite.com/xNews.asmx?WSDL
>Reporter: Robert Rapant
>Assignee: Sean O'Callaghan
>
>   DynamicClientFactory dcf = 
> DynamicClientFactory.newInstance();
>   Client client = 
> dcf.createClient("file:src/test/xNews.wsdl");
>   Object[] res = client.invoke("GetStockHeadlines", 
> "MSFT", 3);
> produces: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>   
>   http://www.w3.org/2001/XMLSchema";
>   
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xmlns="http://www.xignite.com/services/"; 
> xsi:type="ns3:int">3
>   
>   
>   
>  xmlns:ns1="http://www.xignite.com/services/";>
>xmlns="http://www.xignite.com/services/";>
>   MSFT
>   
>   
>   
>   
> exception:
> Server was unable to read request. --> There is an error in XML document (1, 
> 85). --> The specified type was not recognized: name='i
> nt', namespace='http://www.w3.org/2001/XMLSchema', at 
xmlns='http://www.xignite.com/services/'>. > In contrast, the direct manner of invocation below works fine: > XigniteNews newsService = new XigniteNews(); > XigniteNewsSoap soap = newsService.getXigniteNewsSoap(); > ArrayOfStockNews newsArray = > soap.getStockHeadlines("MSFT", 3); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.

[jira] Resolved: (CXF-2048) ClassCastException occurs on HTTPS web service call made when Tibco EMS SSL Java client library is on classpath

2009-02-19 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-2048.
---

Resolution: Fixed

Fixed on 2.2, 2.1.x, 2.0.x branches

> ClassCastException occurs on HTTPS web service call made when Tibco EMS SSL 
> Java client library is on classpath
> ---
>
> Key: CXF-2048
> URL: https://issues.apache.org/jira/browse/CXF-2048
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 2.0.10
> Environment: JDK 6 with Tibco EMS 4 SSL library on classpath
>Reporter: Ron Gavlin
>Assignee: Sean O'Callaghan
>Priority: Critical
> Attachments: cxf-2048.patch
>
>
> My app is using CXF to make web service connections to external services that 
> require client PKI authentication. The app also uses Tibco Java client 
> libraries for JMS over SSL. The Tibco libs set the following Java system 
> property:
> java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
> This causes my CXF web service client to throw a class cast exception when it 
> attempts to make a secure connection. Let me explain why this occurs..
> The java.protocol.handler.pkgs system property is a list of package name 
> prefixes used by Java to resolve protocol names into actual handler class 
> names. As of v1.4, JSSE has been integrated into the J2SDK. Thus, the classes 
> formerly in com.sun.net.ssl have been promoted to the javax.net.ssl package 
> and are now a part of the standard JSSE API.
> For compatibility purposes the com.sun.net.ssl classes and interfaces still 
> exist, but have been deprecated. Applications written using them can run in 
> the J2SDK v1.4 and later without being recompiled. **Thus, setting the system 
> property causes Java to use the deprecated implementation.**
> The problem with CXF comes in because it assumes the newer handler package 
> structure when it attempts to decorate the underlying connection with your 
> TLSClientParameters.
> A workaround should be implemented to support common, divergent subtype https 
> implementations including com.sun.net.ssl.HttpsURLConnection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-2048) ClassCastException occurs on HTTPS web service call made when Tibco EMS SSL Java client library is on classpath

2009-02-18 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-2048:
-

Assignee: Sean O'Callaghan

> ClassCastException occurs on HTTPS web service call made when Tibco EMS SSL 
> Java client library is on classpath
> ---
>
> Key: CXF-2048
> URL: https://issues.apache.org/jira/browse/CXF-2048
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 2.0.10
> Environment: JDK 6 with Tibco EMS 4 SSL library on classpath
>Reporter: Ron Gavlin
>Assignee: Sean O'Callaghan
>Priority: Critical
> Attachments: cxf-2048.patch
>
>
> My app is using CXF to make web service connections to external services that 
> require client PKI authentication. The app also uses Tibco Java client 
> libraries for JMS over SSL. The Tibco libs set the following Java system 
> property:
> java.protocol.handler.pkgs=com.sun.net.ssl.internal.www.protocol
> This causes my CXF web service client to throw a class cast exception when it 
> attempts to make a secure connection. Let me explain why this occurs..
> The java.protocol.handler.pkgs system property is a list of package name 
> prefixes used by Java to resolve protocol names into actual handler class 
> names. As of v1.4, JSSE has been integrated into the J2SDK. Thus, the classes 
> formerly in com.sun.net.ssl have been promoted to the javax.net.ssl package 
> and are now a part of the standard JSSE API.
> For compatibility purposes the com.sun.net.ssl classes and interfaces still 
> exist, but have been deprecated. Applications written using them can run in 
> the J2SDK v1.4 and later without being recompiled. **Thus, setting the system 
> property causes Java to use the deprecated implementation.**
> The problem with CXF comes in because it assumes the newer handler package 
> structure when it attempts to decorate the underlying connection with your 
> TLSClientParameters.
> A workaround should be implemented to support common, divergent subtype https 
> implementations including com.sun.net.ssl.HttpsURLConnection.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-2022) NPE being thrown from JAXBEncoderDecoder

2009-02-05 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-2022.
-

Resolution: Fixed

> NPE being thrown from JAXBEncoderDecoder
> 
>
> Key: CXF-2022
> URL: https://issues.apache.org/jira/browse/CXF-2022
> Project: CXF
>  Issue Type: Bug
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
> Attachments: CXF-bug-2022.zip
>
>
> SchemaInfo sch is being accessed without a check if it is null, hence NPE:
> SchemaInfo sch =
> part.getMessageInfo().getOperation().getInterface()
> .getService().getSchema(namespace);
> if (!sch.isElementFormQualified()) { // <== NPE
> namespace = null;
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (CXF-2022) NPE being thrown from JAXBEncoderDecoder

2009-02-04 Thread Sean O'Callaghan (JIRA)
NPE being thrown from JAXBEncoderDecoder


 Key: CXF-2022
 URL: https://issues.apache.org/jira/browse/CXF-2022
 Project: CXF
  Issue Type: Bug
Reporter: Sean O'Callaghan




SchemaInfo sch is being accessed without a check if it is null, hence NPE:

SchemaInfo sch =
part.getMessageInfo().getOperation().getInterface()
.getService().getSchema(namespace);
if (!sch.isElementFormQualified()) { // <== NPE
namespace = null;
}



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-2022) NPE being thrown from JAXBEncoderDecoder

2009-02-04 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-2022:
-

Assignee: Sean O'Callaghan

> NPE being thrown from JAXBEncoderDecoder
> 
>
> Key: CXF-2022
> URL: https://issues.apache.org/jira/browse/CXF-2022
> Project: CXF
>  Issue Type: Bug
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
>
> SchemaInfo sch is being accessed without a check if it is null, hence NPE:
> SchemaInfo sch =
> part.getMessageInfo().getOperation().getInterface()
> .getService().getSchema(namespace);
> if (!sch.isElementFormQualified()) { // <== NPE
> namespace = null;
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1475) Dynamic client invocation places argument in soap header

2009-02-03 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669967#action_12669967
 ] 

Sean O'Callaghan commented on CXF-1475:
---

Have reproduced the problem, debugging into the code to see where the problem 
lies.

> Dynamic client invocation places argument in soap header
> 
>
> Key: CXF-1475
> URL: https://issues.apache.org/jira/browse/CXF-1475
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 2.0.4
> Environment: Windows XP SP2, Java 1.6, generated web service from 
> http://www.xignite.com/xNews.asmx?WSDL
>Reporter: Robert Rapant
>Assignee: Sean O'Callaghan
>
>   DynamicClientFactory dcf = 
> DynamicClientFactory.newInstance();
>   Client client = 
> dcf.createClient("file:src/test/xNews.wsdl");
>   Object[] res = client.invoke("GetStockHeadlines", 
> "MSFT", 3);
> produces: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>   
>   http://www.w3.org/2001/XMLSchema";
>   
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xmlns="http://www.xignite.com/services/"; 
> xsi:type="ns3:int">3
>   
>   
>   
>  xmlns:ns1="http://www.xignite.com/services/";>
>xmlns="http://www.xignite.com/services/";>
>   MSFT
>   
>   
>   
>   
> exception:
> Server was unable to read request. --> There is an error in XML document (1, 
> 85). --> The specified type was not recognized: name='i
> nt', namespace='http://www.w3.org/2001/XMLSchema', at 
xmlns='http://www.xignite.com/services/'>. > In contrast, the direct manner of invocation below works fine: > XigniteNews newsService = new XigniteNews(); > XigniteNewsSoap soap = newsService.getXigniteNewsSoap(); > ArrayOfStockNews newsArray = > soap.getStockHeadlines("MSFT", 3); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.

[jira] Closed: (CXF-1453) [WSDL2Java] Generated code warnings

2009-02-03 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1453.
-

Resolution: Fixed

> [WSDL2Java] Generated code warnings
> ---
>
> Key: CXF-1453
> URL: https://issues.apache.org/jira/browse/CXF-1453
> Project: CXF
>  Issue Type: Wish
> Environment: N/A
>Reporter: Scott Anderson
>Assignee: Sean O'Callaghan
>Priority: Trivial
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> My generated Java code has a few warnings:
> 1) Anonymous types are imported, despite being defined inside the class
> 2) The Port imports Mode and Style, but they are not used - this might be 
> tricky to fix; I'm not familiar with what their purpose is
> 3) The Service class's get??Port() method has an unnecessary cast, since 
> generics are implemented

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1475) Dynamic client invocation places argument in soap header

2009-01-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1475:
-

Assignee: Sean O'Callaghan

> Dynamic client invocation places argument in soap header
> 
>
> Key: CXF-1475
> URL: https://issues.apache.org/jira/browse/CXF-1475
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 2.0.4
> Environment: Windows XP SP2, Java 1.6, generated web service from 
> http://www.xignite.com/xNews.asmx?WSDL
>Reporter: Robert Rapant
>Assignee: Sean O'Callaghan
>
>   DynamicClientFactory dcf = 
> DynamicClientFactory.newInstance();
>   Client client = 
> dcf.createClient("file:src/test/xNews.wsdl");
>   Object[] res = client.invoke("GetStockHeadlines", 
> "MSFT", 3);
> produces: 
>  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>   
>   http://www.w3.org/2001/XMLSchema";
>   
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xmlns="http://www.xignite.com/services/"; 
> xsi:type="ns3:int">3
>   
>   
>   
>  xmlns:ns1="http://www.xignite.com/services/";>
>xmlns="http://www.xignite.com/services/";>
>   MSFT
>   
>   
>   
>   
> exception:
> Server was unable to read request. --> There is an error in XML document (1, 
> 85). --> The specified type was not recognized: name='i
> nt', namespace='http://www.w3.org/2001/XMLSchema', at 
xmlns='http://www.xignite.com/services/'>. > In contrast, the direct manner of invocation below works fine: > XigniteNews newsService = new XigniteNews(); > XigniteNewsSoap soap = newsService.getXigniteNewsSoap(); > ArrayOfStockNews newsArray = > soap.getStockHeadlines("MSFT", 3); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.

[jira] Assigned: (CXF-1453) [WSDL2Java] Generated code warnings

2009-01-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1453:
-

Assignee: Sean O'Callaghan

> [WSDL2Java] Generated code warnings
> ---
>
> Key: CXF-1453
> URL: https://issues.apache.org/jira/browse/CXF-1453
> Project: CXF
>  Issue Type: Wish
> Environment: N/A
>Reporter: Scott Anderson
>Assignee: Sean O'Callaghan
>Priority: Trivial
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> My generated Java code has a few warnings:
> 1) Anonymous types are imported, despite being defined inside the class
> 2) The Port imports Mode and Style, but they are not used - this might be 
> tricky to fix; I'm not familiar with what their purpose is
> 3) The Service class's get??Port() method has an unnecessary cast, since 
> generics are implemented

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-923) wsdl2java error message improvement

2009-01-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-923.


   Resolution: Fixed
Fix Version/s: 2.2

> wsdl2java error message improvement
> ---
>
> Key: CXF-923
> URL: https://issues.apache.org/jira/browse/CXF-923
> Project: CXF
>  Issue Type: Improvement
>Reporter: jimma
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
>
> WSDLToJava Error : java.lang.RuntimeException: Fail to create wsdl
> definition from :
> file:/home/fanf/tmp/test_cxf_liberty/liberty-idff-wsdl-v1.1.wsdl
> Caused by : null
> This error message should be improved . See the details in :
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-user/200708.mbox/ajax/%3c3500.10.0.0.1.1187430904.squir...@intranet.linagora.com%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-923) wsdl2java error message improvement

2009-01-26 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667250#action_12667250
 ] 

Sean O'Callaghan commented on CXF-923:
--

Have run against latest 2.2 trunk and see a specific error message:


C:\temp>wsdl2java http://www.projectliberty.org/liberty/content/download/1231/79
97/file/liberty-idff-wsdl-v1.1.wsdl

WSDLToJava Error:
 Summary:  Failures: 1, Warnings: 0

 <<< ERROR!
http://www.projectliberty.org/liberty/content/download/1231/7997/file/liberty-id
ff-wsdl-v1.1.wsdl:[89,5]
 Caused by {urn:liberty:md:IDFF:wsdl}[binding:IDPBinding] not exist.
 

> wsdl2java error message improvement
> ---
>
> Key: CXF-923
> URL: https://issues.apache.org/jira/browse/CXF-923
> Project: CXF
>  Issue Type: Improvement
>Reporter: jimma
>Assignee: Sean O'Callaghan
>
> WSDLToJava Error : java.lang.RuntimeException: Fail to create wsdl
> definition from :
> file:/home/fanf/tmp/test_cxf_liberty/liberty-idff-wsdl-v1.1.wsdl
> Caused by : null
> This error message should be improved . See the details in :
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-user/200708.mbox/ajax/%3c3500.10.0.0.1.1187430904.squir...@intranet.linagora.com%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-923) wsdl2java error message improvement

2009-01-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-923:


Assignee: Sean O'Callaghan

> wsdl2java error message improvement
> ---
>
> Key: CXF-923
> URL: https://issues.apache.org/jira/browse/CXF-923
> Project: CXF
>  Issue Type: Improvement
>Reporter: jimma
>Assignee: Sean O'Callaghan
>
> WSDLToJava Error : java.lang.RuntimeException: Fail to create wsdl
> definition from :
> file:/home/fanf/tmp/test_cxf_liberty/liberty-idff-wsdl-v1.1.wsdl
> Caused by : null
> This error message should be improved . See the details in :
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-user/200708.mbox/ajax/%3c3500.10.0.0.1.1187430904.squir...@intranet.linagora.com%3e

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-976) WebServiceProvider : Unable to create message factory for SOAP

2009-01-26 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667231#action_12667231
 ] 

Sean O'Callaghan commented on CXF-976:
--

Hi,

Using CXF 2.2 trunk, I've modified the jaxws_dispatch_provider sampleto try and 
reproduce the problem but this demo works fine. This is working as a standalone 
demo.



> WebServiceProvider : Unable to create message factory for SOAP
> --
>
> Key: CXF-976
> URL: https://issues.apache.org/jira/browse/CXF-976
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Jdk 1.5.0_06 or JRockit 90_150_10, BEA Weblogic 9.2
>Reporter: Giampaolo Tranchida
>Assignee: Sean O'Callaghan
>
> With CXF 2.0.1 the follow code generate an error, same code work correctly 
> with CXF 2.0 (only change cxf-2.0.1-incubator.jar to cxf-2.0-incubator.jar)
> No problem with @WebService annotation
> @WebServiceProvider
> @ServiceMode(value=Service.Mode.PAYLOAD)
> public class SwissDecService implements Provider {
>   
>   public Source invoke(Source request) {
>   try {
>   System.out.println(request.toString());
>   } catch (Exception e) {
>   e.printStackTrace();
>   }
>   return null;
>   }
> org.apache.cxf.interceptor.Fault: Unable to create message factory for SOAP: 
> weblogic.webservice.core.soap.MessageFactoryImpl
>   at 
> org.apache.cxf.jaxws.interceptors.DispatchInDatabindingInterceptor.handleMessage(DispatchInDatabindingInterceptor.java:147)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73)
>   at 
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:78)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:231)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:139)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.java:271)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.doPost(CXFServlet.java:249)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>   at 
> weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
>   at 
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
>   at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
>   at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
>   at 
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3231)
>   at 
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>   at 
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
>   at 
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2002)
>   at 
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1908)
>   at 
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1362)
>   at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
>   at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> Caused by: javax.xml.soap.SOAPException: Unable to create message factory for 
> SOAP: weblogic.webservice.core.soap.MessageFactoryImpl
>   at javax.xml.soap.MessageFactory.newInstance(Unknown Source)
>   at 
> org.apache.cxf.jaxws.interceptors.DispatchInDatabindingInterceptor.newSOAPMessage(DispatchInDatabindingInterceptor.java:158)
>   at 
> org.apache.cxf.jaxws.interceptors.DispatchInDatabindingInterceptor.handleMessage(DispatchInDatabindingInterceptor.java:113)
>   ... 21 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-976) WebServiceProvider : Unable to create message factory for SOAP

2009-01-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-976:


Assignee: Sean O'Callaghan

> WebServiceProvider : Unable to create message factory for SOAP
> --
>
> Key: CXF-976
> URL: https://issues.apache.org/jira/browse/CXF-976
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Jdk 1.5.0_06 or JRockit 90_150_10, BEA Weblogic 9.2
>Reporter: Giampaolo Tranchida
>Assignee: Sean O'Callaghan
>
> With CXF 2.0.1 the follow code generate an error, same code work correctly 
> with CXF 2.0 (only change cxf-2.0.1-incubator.jar to cxf-2.0-incubator.jar)
> No problem with @WebService annotation
> @WebServiceProvider
> @ServiceMode(value=Service.Mode.PAYLOAD)
> public class SwissDecService implements Provider {
>   
>   public Source invoke(Source request) {
>   try {
>   System.out.println(request.toString());
>   } catch (Exception e) {
>   e.printStackTrace();
>   }
>   return null;
>   }
> org.apache.cxf.interceptor.Fault: Unable to create message factory for SOAP: 
> weblogic.webservice.core.soap.MessageFactoryImpl
>   at 
> org.apache.cxf.jaxws.interceptors.DispatchInDatabindingInterceptor.handleMessage(DispatchInDatabindingInterceptor.java:147)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:73)
>   at 
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:78)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:231)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:139)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.java:271)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.doPost(CXFServlet.java:249)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
>   at 
> weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
>   at 
> weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
>   at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
>   at 
> weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:175)
>   at 
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3231)
>   at 
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>   at 
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
>   at 
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2002)
>   at 
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1908)
>   at 
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1362)
>   at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
>   at weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> Caused by: javax.xml.soap.SOAPException: Unable to create message factory for 
> SOAP: weblogic.webservice.core.soap.MessageFactoryImpl
>   at javax.xml.soap.MessageFactory.newInstance(Unknown Source)
>   at 
> org.apache.cxf.jaxws.interceptors.DispatchInDatabindingInterceptor.newSOAPMessage(DispatchInDatabindingInterceptor.java:158)
>   at 
> org.apache.cxf.jaxws.interceptors.DispatchInDatabindingInterceptor.handleMessage(DispatchInDatabindingInterceptor.java:113)
>   ... 21 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1513) NPE in JaxWsServiceConfiguration

2009-01-26 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667219#action_12667219
 ] 

Sean O'Callaghan commented on CXF-1513:
---

Is there an anonymous checkout? 

I have created an account on JBoss but when doing a checkout it doesn't seem to 
recognise my username and password?

Seán.



> NPE in JaxWsServiceConfiguration
> 
>
> Key: CXF-1513
> URL: https://issues.apache.org/jira/browse/CXF-1513
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.0.5
>Reporter: Thomas Diesler
>
> [tdies...@tddell trunk]$ ant -Dtest=jaxws/handlerscope test
> tests-run-internal:
> [junit] Running org.jboss.test.ws.jaxws.handlerscope.HandlerScopeTestCase
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 5.689 sec
> [junit] Test org.jboss.test.ws.jaxws.handlerscope.HandlerScopeTestCase 
> FAILED
> java.lang.NullPointerException
> at 
> org.apache.cxf.jaxws.support.JaxWsServiceConfiguration.getInParameterName(JaxWsServiceConfiguration.java:208)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.getInParameterName(ReflectionServiceFactoryBean.java:1719)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.getInPartName(ReflectionServiceFactoryBean.java:1699)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeParameter(ReflectionServiceFactoryBean.java:592)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeClassInfo(ReflectionServiceFactoryBean.java:569)
> at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOperation(JaxWsServiceFactoryBean.java:173)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeWSDLOperations(ReflectionServiceFactoryBean.java:482)
> at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOperations(JaxWsServiceFactoryBean.java:182)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:280)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:366)
> at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:162)
> at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:97)
> at org.apache.cxf.jaxws.ServiceImpl.createPort(ServiceImpl.java:353)
> at org.apache.cxf.jaxws.ServiceImpl.getPort(ServiceImpl.java:265)
> at javax.xml.ws.Service.getPort(Service.java:120)
> at 
> org.jboss.test.ws.jaxws.handlerscope.HandlerScopeTestCase.testClientAccess(HandlerScopeTestCase.java:54)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1955) WHICH_JARS text file does not mention commons-collections.jar

2009-01-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1955.
-

Resolution: Fixed

> WHICH_JARS text file does not mention commons-collections.jar
> -
>
> Key: CXF-1955
> URL: https://issues.apache.org/jira/browse/CXF-1955
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 2.1.3
> Environment: all
>Reporter: Steven Doolan
>Assignee: Sean O'Callaghan
>Priority: Minor
>   Original Estimate: 0.17h
>  Remaining Estimate: 0.17h
>
> The WHICH_JARS file in the lib directory lists the dependencies of various 
> parts of CXF. commons-collections is required for wsdl2java (and perhaps 
> other sections) but is not mentioned.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1981) Inconsistent use of logger delegation via LogUtils

2009-01-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1981.
-

Resolution: Fixed

Made the change Andy suggested.

> Inconsistent use of logger delegation via LogUtils
> --
>
> Key: CXF-1981
> URL: https://issues.apache.org/jira/browse/CXF-1981
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrzej Michalec
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> Even after installation of Log4jLogger delegate (via 
> META-INF/cxf/org.apache.cxf.Logger file) some messages still are logged by 
> java.util.logging -- example:
> 14 Jan 2009 14:09:05,358 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Refreshing 
> org.apache.cxf.bus.spring.busapplicationcont...@6c826c82: display name 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]; startup date [Wed 
> Jan 14 14:09:05 CET 2009]; parent: 
> org.springframework.web.context.support.xmlwebapplicationcont...@6abe6abe
> 14 Jan 2009 14:09:05,393 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Bean factory for 
> application context 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]: 
> org.springframework.beans.factory.support.defaultlistablebeanfact...@75d275d2
> ...
> Jan 14, 2009 2:10:03 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:148)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:114)
> ...
> Review of PhaseInterceptorChain class shows that some log messages are passed 
> via delegating logger and other via direct call to LogUtils:
> public class PhaseInterceptorChain implements InterceptorChain {
> private static final Logger LOG = 
> LogUtils.getL7dLogger(PhaseInterceptorChain.class); 
> ...
> public void add(Interceptor i, boolean force) {
> ...
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("Adding interceptor " + i + " to phase " + 
> phaseName);
> }
> ...
> }
> public synchronized boolean doIntercept(Message message) {
> ...
> if (LOG.isLoggable(Level.FINE)) { 
> LogUtils.log(LOG, Level.FINE,
>  "Application has thrown exception, 
> unwinding now", ex);
> } else if (LOG.isLoggable(Level.INFO)) {
> ...
> }
> }
> Workaround is to install SFL4J delegating JUL to Log4j however I guess it 
> would be better clean up the code. I think that use of LogUtils.log() should 
> be forbidden and enforcement could be done via checkstyle (marking this 
> method as depreciaded first) -or- introduction of AOP with aspect checking 
> calls to illegal method.
> cheers,
> andy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1955) WHICH_JARS text file does not mention commons-collections.jar

2009-01-23 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666551#action_12666551
 ] 

Sean O'Callaghan commented on CXF-1955:
---

Hi Benson,

It seems that it CXF is dependent on velocity and that it is dependent on 
commons-*.jars

> WHICH_JARS text file does not mention commons-collections.jar
> -
>
> Key: CXF-1955
> URL: https://issues.apache.org/jira/browse/CXF-1955
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 2.1.3
> Environment: all
>Reporter: Steven Doolan
>Assignee: Sean O'Callaghan
>Priority: Minor
>   Original Estimate: 0.17h
>  Remaining Estimate: 0.17h
>
> The WHICH_JARS file in the lib directory lists the dependencies of various 
> parts of CXF. commons-collections is required for wsdl2java (and perhaps 
> other sections) but is not mentioned.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1981) Inconsistent use of logger delegation via LogUtils

2009-01-22 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666114#action_12666114
 ] 

Sean O'Callaghan commented on CXF-1981:
---

Thanks for the feedback Andy.
I'll have another look at this.

> Inconsistent use of logger delegation via LogUtils
> --
>
> Key: CXF-1981
> URL: https://issues.apache.org/jira/browse/CXF-1981
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrzej Michalec
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> Even after installation of Log4jLogger delegate (via 
> META-INF/cxf/org.apache.cxf.Logger file) some messages still are logged by 
> java.util.logging -- example:
> 14 Jan 2009 14:09:05,358 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Refreshing 
> org.apache.cxf.bus.spring.busapplicationcont...@6c826c82: display name 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]; startup date [Wed 
> Jan 14 14:09:05 CET 2009]; parent: 
> org.springframework.web.context.support.xmlwebapplicationcont...@6abe6abe
> 14 Jan 2009 14:09:05,393 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Bean factory for 
> application context 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]: 
> org.springframework.beans.factory.support.defaultlistablebeanfact...@75d275d2
> ...
> Jan 14, 2009 2:10:03 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:148)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:114)
> ...
> Review of PhaseInterceptorChain class shows that some log messages are passed 
> via delegating logger and other via direct call to LogUtils:
> public class PhaseInterceptorChain implements InterceptorChain {
> private static final Logger LOG = 
> LogUtils.getL7dLogger(PhaseInterceptorChain.class); 
> ...
> public void add(Interceptor i, boolean force) {
> ...
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("Adding interceptor " + i + " to phase " + 
> phaseName);
> }
> ...
> }
> public synchronized boolean doIntercept(Message message) {
> ...
> if (LOG.isLoggable(Level.FINE)) { 
> LogUtils.log(LOG, Level.FINE,
>  "Application has thrown exception, 
> unwinding now", ex);
> } else if (LOG.isLoggable(Level.INFO)) {
> ...
> }
> }
> Workaround is to install SFL4J delegating JUL to Log4j however I guess it 
> would be better clean up the code. I think that use of LogUtils.log() should 
> be forbidden and enforcement could be done via checkstyle (marking this 
> method as depreciaded first) -or- introduction of AOP with aspect checking 
> calls to illegal method.
> cheers,
> andy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1955) WHICH_JARS text file does not mention commons-collections.jar

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1955:
-

Assignee: Sean O'Callaghan

> WHICH_JARS text file does not mention commons-collections.jar
> -
>
> Key: CXF-1955
> URL: https://issues.apache.org/jira/browse/CXF-1955
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 2.1.3
> Environment: all
>Reporter: Steven Doolan
>Assignee: Sean O'Callaghan
>Priority: Minor
>   Original Estimate: 0.17h
>  Remaining Estimate: 0.17h
>
> The WHICH_JARS file in the lib directory lists the dependencies of various 
> parts of CXF. commons-collections is required for wsdl2java (and perhaps 
> other sections) but is not mentioned.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1969) wsdl2java - NPE when wsdl has a missing attribute

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1969.
-

   Resolution: Fixed
Fix Version/s: 2.2

applied fix to trunk http://svn.apache.org/viewvc?rev=736352&view=rev

> wsdl2java - NPE when wsdl has a missing attribute
> -
>
> Key: CXF-1969
> URL: https://issues.apache.org/jira/browse/CXF-1969
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.1.3
> Environment: MaxOS X, CXF 2.13, Camel 1.5.0
>Reporter: Claus Ibsen
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> I was working on part-five to a longer tutorial using Camel and CXF
> http://activemq.apache.org/camel/tutorial-example-reportincident-part5.html
> I have a handcrafted .wsdl which I use the wsdl2java tool to generate source 
> code.
> I was getting this error reported from wsdl2java
> {code}
> Jan 11, 2009 3:43:10 PM 
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory createEndpoint
> WARNING: Could not find endpoint/port for 
> {http://reportincident.example.camel.apache.org}ReportIncidentEndpointPort in 
> wsdl. Using 
> {http://reportincident.example.camel.apache.org}ReportIncidentPort.
> {code}
> So I was messing a bit with the .wsdl to see what was wrong
> How to reproduce
> 1) Download the .zip from: 
> http://cwiki.apache.org/confluence/display/CAMEL/Tutorial-Example-ReportIncident-Part5
> 2) Unzip to a folder
> 3) Run: mvn test   it should run fine
> 4) Edit the file: src/main/resources/report_incident.wsdl 
> 5) Change from
> {code}
> 
> {code}
> to remove the type attribute (yes I was being a bit mean), so its
> {code}
> 
> {code}
> 6) Save
> 7) Run: mvn test again and see the error
> {code}
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] java.lang.NullPointerException
> {code}
> The problem is the NPE doesnt give you any hint what was wrong. What if the 
> .wsdl was very large and you didn't have a clue what was wrong with it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1969) wsdl2java - NPE when wsdl has a missing attribute

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1969:
-

Assignee: Sean O'Callaghan

> wsdl2java - NPE when wsdl has a missing attribute
> -
>
> Key: CXF-1969
> URL: https://issues.apache.org/jira/browse/CXF-1969
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.1.3
> Environment: MaxOS X, CXF 2.13, Camel 1.5.0
>Reporter: Claus Ibsen
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> I was working on part-five to a longer tutorial using Camel and CXF
> http://activemq.apache.org/camel/tutorial-example-reportincident-part5.html
> I have a handcrafted .wsdl which I use the wsdl2java tool to generate source 
> code.
> I was getting this error reported from wsdl2java
> {code}
> Jan 11, 2009 3:43:10 PM 
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory createEndpoint
> WARNING: Could not find endpoint/port for 
> {http://reportincident.example.camel.apache.org}ReportIncidentEndpointPort in 
> wsdl. Using 
> {http://reportincident.example.camel.apache.org}ReportIncidentPort.
> {code}
> So I was messing a bit with the .wsdl to see what was wrong
> How to reproduce
> 1) Download the .zip from: 
> http://cwiki.apache.org/confluence/display/CAMEL/Tutorial-Example-ReportIncident-Part5
> 2) Unzip to a folder
> 3) Run: mvn test   it should run fine
> 4) Edit the file: src/main/resources/report_incident.wsdl 
> 5) Change from
> {code}
> 
> {code}
> to remove the type attribute (yes I was being a bit mean), so its
> {code}
> 
> {code}
> 6) Save
> 7) Run: mvn test again and see the error
> {code}
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] java.lang.NullPointerException
> {code}
> The problem is the NPE doesnt give you any hint what was wrong. What if the 
> .wsdl was very large and you didn't have a clue what was wrong with it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1981) Inconsistent use of logger delegation via LogUtils

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1981.
-

Resolution: Fixed

Fixed http://svn.apache.org/viewvc?rev=736343&view=rev

> Inconsistent use of logger delegation via LogUtils
> --
>
> Key: CXF-1981
> URL: https://issues.apache.org/jira/browse/CXF-1981
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrzej Michalec
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> Even after installation of Log4jLogger delegate (via 
> META-INF/cxf/org.apache.cxf.Logger file) some messages still are logged by 
> java.util.logging -- example:
> 14 Jan 2009 14:09:05,358 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Refreshing 
> org.apache.cxf.bus.spring.busapplicationcont...@6c826c82: display name 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]; startup date [Wed 
> Jan 14 14:09:05 CET 2009]; parent: 
> org.springframework.web.context.support.xmlwebapplicationcont...@6abe6abe
> 14 Jan 2009 14:09:05,393 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Bean factory for 
> application context 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]: 
> org.springframework.beans.factory.support.defaultlistablebeanfact...@75d275d2
> ...
> Jan 14, 2009 2:10:03 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:148)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:114)
> ...
> Review of PhaseInterceptorChain class shows that some log messages are passed 
> via delegating logger and other via direct call to LogUtils:
> public class PhaseInterceptorChain implements InterceptorChain {
> private static final Logger LOG = 
> LogUtils.getL7dLogger(PhaseInterceptorChain.class); 
> ...
> public void add(Interceptor i, boolean force) {
> ...
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("Adding interceptor " + i + " to phase " + 
> phaseName);
> }
> ...
> }
> public synchronized boolean doIntercept(Message message) {
> ...
> if (LOG.isLoggable(Level.FINE)) { 
> LogUtils.log(LOG, Level.FINE,
>  "Application has thrown exception, 
> unwinding now", ex);
> } else if (LOG.isLoggable(Level.INFO)) {
> ...
> }
> }
> Workaround is to install SFL4J delegating JUL to Log4j however I guess it 
> would be better clean up the code. I think that use of LogUtils.log() should 
> be forbidden and enforcement could be done via checkstyle (marking this 
> method as depreciaded first) -or- introduction of AOP with aspect checking 
> calls to illegal method.
> cheers,
> andy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1981) Inconsistent use of logger delegation via LogUtils

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1981:
-

Assignee: Sean O'Callaghan

> Inconsistent use of logger delegation via LogUtils
> --
>
> Key: CXF-1981
> URL: https://issues.apache.org/jira/browse/CXF-1981
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrzej Michalec
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> Even after installation of Log4jLogger delegate (via 
> META-INF/cxf/org.apache.cxf.Logger file) some messages still are logged by 
> java.util.logging -- example:
> 14 Jan 2009 14:09:05,358 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Refreshing 
> org.apache.cxf.bus.spring.busapplicationcont...@6c826c82: display name 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]; startup date [Wed 
> Jan 14 14:09:05 CET 2009]; parent: 
> org.springframework.web.context.support.xmlwebapplicationcont...@6abe6abe
> 14 Jan 2009 14:09:05,393 
> [ContainerBackgroundProcessor[StandardEngine[Catalina]]] INFO  
> org.apache.cxf.bus.spring.BusApplicationContext - Bean factory for 
> application context 
> [org.apache.cxf.bus.spring.busapplicationcont...@6c826c82]: 
> org.springframework.beans.factory.support.defaultlistablebeanfact...@75d275d2
> ...
> Jan 14, 2009 2:10:03 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:148)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:114)
> ...
> Review of PhaseInterceptorChain class shows that some log messages are passed 
> via delegating logger and other via direct call to LogUtils:
> public class PhaseInterceptorChain implements InterceptorChain {
> private static final Logger LOG = 
> LogUtils.getL7dLogger(PhaseInterceptorChain.class); 
> ...
> public void add(Interceptor i, boolean force) {
> ...
> if (LOG.isLoggable(Level.FINE)) {
> LOG.fine("Adding interceptor " + i + " to phase " + 
> phaseName);
> }
> ...
> }
> public synchronized boolean doIntercept(Message message) {
> ...
> if (LOG.isLoggable(Level.FINE)) { 
> LogUtils.log(LOG, Level.FINE,
>  "Application has thrown exception, 
> unwinding now", ex);
> } else if (LOG.isLoggable(Level.INFO)) {
> ...
> }
> }
> Workaround is to install SFL4J delegating JUL to Log4j however I guess it 
> would be better clean up the code. I think that use of LogUtils.log() should 
> be forbidden and enforcement could be done via checkstyle (marking this 
> method as depreciaded first) -or- introduction of AOP with aspect checking 
> calls to illegal method.
> cheers,
> andy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1327) Logging Interceptor with pretty formatting

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1327.
-

Resolution: Fixed

Committed the PrettyLoggingOutInterceptor

> Logging Interceptor with pretty formatting
> --
>
> Key: CXF-1327
> URL: https://issues.apache.org/jira/browse/CXF-1327
> Project: CXF
>  Issue Type: Wish
>  Components: Tooling
>Reporter: Davide Gesino
>Assignee: Sean O'Callaghan
>Priority: Trivial
>
> LoggingInIterceptor and LoggingOutInterceptor are really useful, but 
> sometimes it is difficult to read the SOAP messages without having a "pretty" 
> identation, I would a LOG that  outputs a nice formatted string with XML 
> identation.
> Modifying the LoggingOutInterceptor something similar to the example I paste 
> in the following, obtained modifying the LoggingOutInterceptor.
> I hav not included the length limit and used the jdom api instead of stax.
>  :
> public class PrettyLoggingOutInterceptor extends AbstractPhaseInterceptor {
>   private final Log LOG = LogFactory
>   .getLog(PrettyLoggingOutInterceptor.class);
>   private SAXBuilder saxBuilder = new SAXBuilder();
>   private XMLOutputter xmlOutputter = new XMLOutputter();
>   public PrettyLoggingOutInterceptor() {
>   super(Phase.PRE_STREAM);
>   addBefore(StaxOutInterceptor.class.getName());
>   }
>   public void handleMessage(Message message) throws Fault {
>   final OutputStream os = message.getContent(OutputStream.class);
>   if (os == null) {
>   return;
>   }
>   if (!LOG.isInfoEnabled()) {
>   return;
>   }
>   // Write the output while caching it for the log message
>   final CacheAndWriteOutputStream newOut = new 
> CacheAndWriteOutputStream( os);
>   message.setContent(OutputStream.class, newOut);
>   newOut.registerCallback(new LoggingCallback());
>   }
>   class LoggingCallback implements CachedOutputStreamCallback {
>   public void onFlush(CachedOutputStream cos) {
>   }
>   public void onClose(CachedOutputStream cos) {
>   try {
>   Document jdoCument = 
> saxBuilder.build(cos.getInputStream());
>   
> xmlOutputter.setFormat(Format.getPrettyFormat());
>   StringWriter writer = new StringWriter();
>   xmlOutputter.output(jdoCument, writer);
>   LOG.info(writer.getBuffer().toString());
>   } catch (Exception e) {
>   LOG.error("fatal parsing the SOAP message");
>   LOG.error(e);
>   }
>   }
>   }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1327) Logging Interceptor with pretty formatting

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1327:
-

Assignee: Sean O'Callaghan

> Logging Interceptor with pretty formatting
> --
>
> Key: CXF-1327
> URL: https://issues.apache.org/jira/browse/CXF-1327
> Project: CXF
>  Issue Type: Wish
>  Components: Tooling
>Reporter: Davide Gesino
>Assignee: Sean O'Callaghan
>Priority: Trivial
>
> LoggingInIterceptor and LoggingOutInterceptor are really useful, but 
> sometimes it is difficult to read the SOAP messages without having a "pretty" 
> identation, I would a LOG that  outputs a nice formatted string with XML 
> identation.
> Modifying the LoggingOutInterceptor something similar to the example I paste 
> in the following, obtained modifying the LoggingOutInterceptor.
> I hav not included the length limit and used the jdom api instead of stax.
>  :
> public class PrettyLoggingOutInterceptor extends AbstractPhaseInterceptor {
>   private final Log LOG = LogFactory
>   .getLog(PrettyLoggingOutInterceptor.class);
>   private SAXBuilder saxBuilder = new SAXBuilder();
>   private XMLOutputter xmlOutputter = new XMLOutputter();
>   public PrettyLoggingOutInterceptor() {
>   super(Phase.PRE_STREAM);
>   addBefore(StaxOutInterceptor.class.getName());
>   }
>   public void handleMessage(Message message) throws Fault {
>   final OutputStream os = message.getContent(OutputStream.class);
>   if (os == null) {
>   return;
>   }
>   if (!LOG.isInfoEnabled()) {
>   return;
>   }
>   // Write the output while caching it for the log message
>   final CacheAndWriteOutputStream newOut = new 
> CacheAndWriteOutputStream( os);
>   message.setContent(OutputStream.class, newOut);
>   newOut.registerCallback(new LoggingCallback());
>   }
>   class LoggingCallback implements CachedOutputStreamCallback {
>   public void onFlush(CachedOutputStream cos) {
>   }
>   public void onClose(CachedOutputStream cos) {
>   try {
>   Document jdoCument = 
> saxBuilder.build(cos.getInputStream());
>   
> xmlOutputter.setFormat(Format.getPrettyFormat());
>   StringWriter writer = new StringWriter();
>   xmlOutputter.output(jdoCument, writer);
>   LOG.info(writer.getBuffer().toString());
>   } catch (Exception e) {
>   LOG.error("fatal parsing the SOAP message");
>   LOG.error(e);
>   }
>   }
>   }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1031) CXF servlet badly exposes the wsdl's

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1031.
-

Resolution: Fixed

Have tested simple wsdl_first demo and 
http://localhost:8080/helloworld/services/hello_world?wsdl works as expected. 
as does http://localhost:8080/helloworld/services/ or 
http://localhost:8080/helloworld/services

> CXF servlet badly exposes the wsdl's
> 
>
> Key: CXF-1031
> URL: https://issues.apache.org/jira/browse/CXF-1031
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: any
>Reporter: Jakub Janczak
>Assignee: Sean O'Callaghan
>Priority: Trivial
>
> When you approach an URL http:/// you get badly formed 
> URL's to the WSDL's. 
> When you use http: everything is all right, so the 
> code for generating that page needs a little correction (checking if the last 
> character in base URL is really '/')

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1031) CXF servlet badly exposes the wsdl's

2009-01-21 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1031:
-

Assignee: Sean O'Callaghan

> CXF servlet badly exposes the wsdl's
> 
>
> Key: CXF-1031
> URL: https://issues.apache.org/jira/browse/CXF-1031
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: any
>Reporter: Jakub Janczak
>Assignee: Sean O'Callaghan
>Priority: Trivial
>
> When you approach an URL http:/// you get badly formed 
> URL's to the WSDL's. 
> When you use http: everything is all right, so the 
> code for generating that page needs a little correction (checking if the last 
> character in base URL is really '/')

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1453) [WSDL2Java] Generated code warnings

2009-01-21 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665794#action_12665794
 ] 

Sean O'Callaghan commented on CXF-1453:
---

Hi Scott,

Can you send me on your wsdl so I can test to see if there are still issues 
with the latest snapshot

Seán.



> [WSDL2Java] Generated code warnings
> ---
>
> Key: CXF-1453
> URL: https://issues.apache.org/jira/browse/CXF-1453
> Project: CXF
>  Issue Type: Wish
> Environment: N/A
>Reporter: Scott Anderson
>Priority: Trivial
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> My generated Java code has a few warnings:
> 1) Anonymous types are imported, despite being defined inside the class
> 2) The Port imports Mode and Style, but they are not used - this might be 
> tricky to fix; I'm not familiar with what their purpose is
> 3) The Service class's get??Port() method has an unnecessary cast, since 
> generics are implemented

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1470) js_provider demo fails using jdk1.6.0_04

2009-01-20 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665453#action_12665453
 ] 

Sean O'Callaghan commented on CXF-1470:
---

Workaround provided on XMLBeans issue but does not seem to be used by Xalan, so 
error still occurs.

> js_provider demo fails using jdk1.6.0_04
> 
>
> Key: CXF-1470
> URL: https://issues.apache.org/jira/browse/CXF-1470
> Project: CXF
>  Issue Type: Sub-task
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
> Attachments: CXF-1470.zip
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1973) Dynamic Client Factory classes should take URL objects as well as Strings

2009-01-20 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1973.
-


> Dynamic Client Factory classes should take URL objects as well as Strings
> -
>
> Key: CXF-1973
> URL: https://issues.apache.org/jira/browse/CXF-1973
> Project: CXF
>  Issue Type: Bug
>  Components: Dynamic Languages
>Affects Versions: 2.1.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> The JAX-WS API's (e.g. Endpoint) take URL objects. The more-or-less 
> corresponding DynamicClientFactory and JaxWsDynamicClientFactory objects only 
> take Strings. Consistency here would be a good thing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1973) Dynamic Client Factory classes should take URL objects as well as Strings

2009-01-19 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1973.
---

   Resolution: Fixed
Fix Version/s: 2.2

Added in new API's which take a URL.

> Dynamic Client Factory classes should take URL objects as well as Strings
> -
>
> Key: CXF-1973
> URL: https://issues.apache.org/jira/browse/CXF-1973
> Project: CXF
>  Issue Type: Bug
>  Components: Dynamic Languages
>Affects Versions: 2.1.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> The JAX-WS API's (e.g. Endpoint) take URL objects. The more-or-less 
> corresponding DynamicClientFactory and JaxWsDynamicClientFactory objects only 
> take Strings. Consistency here would be a good thing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1973) Dynamic Client Factory classes should take URL objects as well as Strings

2009-01-19 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1973:
-

Assignee: Sean O'Callaghan

> Dynamic Client Factory classes should take URL objects as well as Strings
> -
>
> Key: CXF-1973
> URL: https://issues.apache.org/jira/browse/CXF-1973
> Project: CXF
>  Issue Type: Bug
>  Components: Dynamic Languages
>Affects Versions: 2.1.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> The JAX-WS API's (e.g. Endpoint) take URL objects. The more-or-less 
> corresponding DynamicClientFactory and JaxWsDynamicClientFactory objects only 
> take Strings. Consistency here would be a good thing.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1161) Javadoc for classes generated XSD with WSDL is defective

2009-01-19 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665098#action_12665098
 ] 

Sean O'Callaghan commented on CXF-1161:
---

According to https://jaxb.dev.java.net/issues/show_bug.cgi?id=575 fixed on jaxb 
trunk as of the 08 jan 2009.

> Javadoc for classes generated XSD with WSDL is defective
> 
>
> Key: CXF-1161
> URL: https://issues.apache.org/jira/browse/CXF-1161
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> I've added a 'form_test.xsd' file to the test resources for 
> rt/databinding/jaxb. This contains:
> 
> 
> 
> 
> 
> 
> The javadoc in the generated class lacks the form attribute.
> 
>
>  http://www.w3.org/2001/XMLSchema}anyType";>
>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>
>  
>
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1698) WSDL operation null when getting from the SOAPMessageContext

2009-01-16 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664541#action_12664541
 ] 

Sean O'Callaghan commented on CXF-1698:
---

I've reproduced the problem using the jaxws_handler sample calling 

operation = (javax.xml.namespace.QName) smc.get(MessageContext.WSDL_OPERATION); 

from within handleMessage(SOAPMessageContext smc) in the samples LoggingHandler.

Debugging into it it appears that the MessageContext has not been fully 
populated in that the exchange variable in WrappedMessageContext is null and so 
the get() cannot call out to determine the operation name.

> WSDL operation null when getting from the SOAPMessageContext
> 
>
> Key: CXF-1698
> URL: https://issues.apache.org/jira/browse/CXF-1698
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.1.1
>Reporter: Arulazi Dhesiaseelan
>Assignee: Sean O'Callaghan
>
> The following code on the SoapMessageContext returns null.
> javax.xml.namespace.QName operation = (javax.xml.namespace.QName) 
> smc.get(MessageContext.WSDL_OPERATION);
> I have annotated my web method with operationName tag.  But, still getting 
> null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1974) Missing names in sample POMs

2009-01-15 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1974.
-


URL: http://svn.apache.org/viewvc?rev=734762&view=rev
Log:
CXF-1974 Missing names tag in sample POMs.

Modified:
cxf/trunk/distribution/src/main/release/samples/aegis/pom.xml
cxf/trunk/distribution/src/main/release/samples/aegis_standalone/pom.xml
cxf/trunk/distribution/src/main/release/samples/callback/pom.xml

cxf/trunk/distribution/src/main/release/samples/configuration_interceptor/pom.xml
cxf/trunk/distribution/src/main/release/samples/in_jvm_transport/pom.xml
cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/pom.xml

cxf/trunk/distribution/src/main/release/samples/java_first_jaxws_factory_bean/pom.xml
cxf/trunk/distribution/src/main/release/samples/java_first_pojo/pom.xml

cxf/trunk/distribution/src/main/release/samples/java_first_spring_support/pom.xml
cxf/trunk/distribution/src/main/release/samples/jax_rs/basic/pom.xml
cxf/trunk/distribution/src/main/release/samples/jax_rs/basic_https/pom.xml

cxf/trunk/distribution/src/main/release/samples/jax_rs/content_negotiation/pom.xml

cxf/trunk/distribution/src/main/release/samples/jax_server_aegis_client/pom.xml
cxf/trunk/distribution/src/main/release/samples/jaxws_async/pom.xml

cxf/trunk/distribution/src/main/release/samples/jaxws_dispatch_provider/pom.xml
cxf/trunk/distribution/src/main/release/samples/jaxws_handlers/pom.xml
cxf/trunk/distribution/src/main/release/samples/jms_pubsub/pom.xml
cxf/trunk/distribution/src/main/release/samples/jms_queue/pom.xml

cxf/trunk/distribution/src/main/release/samples/js_browser_client_java_first/pom.xml

cxf/trunk/distribution/src/main/release/samples/js_browser_client_simple/pom.xml
cxf/trunk/distribution/src/main/release/samples/js_client/pom.xml
cxf/trunk/distribution/src/main/release/samples/mtom/pom.xml
cxf/trunk/distribution/src/main/release/samples/restful_dispatch/pom.xml
cxf/trunk/distribution/src/main/release/samples/restful_http_binding/pom.xml
cxf/trunk/distribution/src/main/release/samples/soap_header/pom.xml
cxf/trunk/distribution/src/main/release/samples/ws_addressing/pom.xml
cxf/trunk/distribution/src/main/release/samples/ws_policy/pom.xml
cxf/trunk/distribution/src/main/release/samples/ws_rm/pom.xml
cxf/trunk/distribution/src/main/release/samples/wsdl_first/pom.xml
cxf/trunk/distribution/src/main/release/samples/wsdl_first_https/pom.xml
cxf/trunk/distribution/src/main/release/samples/wsdl_first_pure_xml/pom.xml
cxf/trunk/distribution/src/main/release/samples/wsdl_first_rpclit/pom.xml
cxf/trunk/distribution/src/main/release/samples/wsdl_first_soap12/pom.xml

cxf/trunk/distribution/src/main/release/samples/wsdl_first_xml_wrapped/pom.xml


> Missing names in sample POMs
> 
>
> Key: CXF-1974
> URL: https://issues.apache.org/jira/browse/CXF-1974
> Project: CXF
>  Issue Type: Bug
>  Components: Samples
>Affects Versions: 2.1.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> Some, if not all, of the sample pom.xml files are missing the  element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1974) Missing names in sample POMs

2009-01-15 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1974.
---

   Resolution: Fixed
Fix Version/s: 2.2

> Missing names in sample POMs
> 
>
> Key: CXF-1974
> URL: https://issues.apache.org/jira/browse/CXF-1974
> Project: CXF
>  Issue Type: Bug
>  Components: Samples
>Affects Versions: 2.1.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>Priority: Minor
> Fix For: 2.2
>
>
> Some, if not all, of the sample pom.xml files are missing the  element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1963) W3CDOMStreamReader can't read text in the root element.

2009-01-15 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1963.
-


> W3CDOMStreamReader can't read text in the root element.
> ---
>
> Key: CXF-1963
> URL: https://issues.apache.org/jira/browse/CXF-1963
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.2
>Reporter: Benson Margulies
> Fix For: 2.2
>
>
> src/test/java/org/apache/cxf/staxutils/W3CDOMStreamReaderTest.java
> Comment in the commented-out test and it will fail. This blocks work in 
> disentangling JDOM from Aegis.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1962) Create directory if does not exist for WSDL to javascript

2009-01-15 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1962.
-


> Create directory if does not exist for WSDL to javascript
> -
>
> Key: CXF-1962
> URL: https://issues.apache.org/jira/browse/CXF-1962
> Project: CXF
>  Issue Type: New Feature
>  Components: Tooling
>Affects Versions: 2.2
>Reporter: kombi
>Assignee: Benson Margulies
>Priority: Minor
> Fix For: 2.2
>
> Attachments: JavaScriptContainer.java.diff, Messages.properties, 
> tools.diff, WSDLToJavaContainer.java.diff
>
>
> In the description of the arguments for wsdl2js  
> -dSpecifies the directory into which the generated code is written.
> Wouldn't be nice to create it, if the directory did not exist?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1974) Missing names in sample POMs

2009-01-15 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664144#action_12664144
 ] 

Sean O'Callaghan commented on CXF-1974:
---

artifactId not good enough for ya? ;-)

I'll drop the name tag in.

> Missing names in sample POMs
> 
>
> Key: CXF-1974
> URL: https://issues.apache.org/jira/browse/CXF-1974
> Project: CXF
>  Issue Type: Bug
>  Components: Samples
>Affects Versions: 2.1.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> Some, if not all, of the sample pom.xml files are missing the  element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1974) Missing names in sample POMs

2009-01-15 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1974:
-

Assignee: Sean O'Callaghan

> Missing names in sample POMs
> 
>
> Key: CXF-1974
> URL: https://issues.apache.org/jira/browse/CXF-1974
> Project: CXF
>  Issue Type: Bug
>  Components: Samples
>Affects Versions: 2.1.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> Some, if not all, of the sample pom.xml files are missing the  element.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (CXF-1698) WSDL operation null when getting from the SOAPMessageContext

2009-01-15 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664142#action_12664142
 ] 

seanoc edited comment on CXF-1698 at 1/15/09 7:42 AM:


Hi Arulazi,

I've had a look through the code and within the RPCInInterceptor class you can 
see  that the operation name is being correctly set  in the MessageContext.

Are you correctly using the SOAP Binding?

If you get back to me with more detail I will investigate further, otherwise I 
will close this JIRA.

Regards,

Seán.



  was (Author: seanoc):
Hi Arulazi,

I've had a look through the code and within the RPCInInterceptor class that the 
operation name is being correctly set  in the MessageContext.

Are you correctly using the SOAP Binding?

If you get back to me with more detail I will investigate further, otherwise I 
will close this JIRA.

Regards,

Seán.


  
> WSDL operation null when getting from the SOAPMessageContext
> 
>
> Key: CXF-1698
> URL: https://issues.apache.org/jira/browse/CXF-1698
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.1.1
>Reporter: Arulazi Dhesiaseelan
>Assignee: Sean O'Callaghan
>
> The following code on the SoapMessageContext returns null.
> javax.xml.namespace.QName operation = (javax.xml.namespace.QName) 
> smc.get(MessageContext.WSDL_OPERATION);
> I have annotated my web method with operationName tag.  But, still getting 
> null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1698) WSDL operation null when getting from the SOAPMessageContext

2009-01-15 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664142#action_12664142
 ] 

Sean O'Callaghan commented on CXF-1698:
---

Hi Arulazi,

I've had a look through the code and within the RPCInInterceptor class that the 
operation name is being correctly set  in the MessageContext.

Are you correctly using the SOAP Binding?

If you get back to me with more detail I will investigate further, otherwise I 
will close this JIRA.

Regards,

Seán.



> WSDL operation null when getting from the SOAPMessageContext
> 
>
> Key: CXF-1698
> URL: https://issues.apache.org/jira/browse/CXF-1698
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.1.1
>Reporter: Arulazi Dhesiaseelan
>Assignee: Sean O'Callaghan
>
> The following code on the SoapMessageContext returns null.
> javax.xml.namespace.QName operation = (javax.xml.namespace.QName) 
> smc.get(MessageContext.WSDL_OPERATION);
> I have annotated my web method with operationName tag.  But, still getting 
> null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1698) WSDL operation null when getting from the SOAPMessageContext

2009-01-14 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663809#action_12663809
 ] 

Sean O'Callaghan commented on CXF-1698:
---

Hi Arulazi,
Can you give more details so the error can be reproduced. A test case perhaps.
thanks,
Seán.


> WSDL operation null when getting from the SOAPMessageContext
> 
>
> Key: CXF-1698
> URL: https://issues.apache.org/jira/browse/CXF-1698
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.1.1
>Reporter: Arulazi Dhesiaseelan
>Assignee: Sean O'Callaghan
>
> The following code on the SoapMessageContext returns null.
> javax.xml.namespace.QName operation = (javax.xml.namespace.QName) 
> smc.get(MessageContext.WSDL_OPERATION);
> I have annotated my web method with operationName tag.  But, still getting 
> null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1698) WSDL operation null when getting from the SOAPMessageContext

2009-01-14 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1698:
-

Assignee: Sean O'Callaghan

> WSDL operation null when getting from the SOAPMessageContext
> 
>
> Key: CXF-1698
> URL: https://issues.apache.org/jira/browse/CXF-1698
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.1.1
>Reporter: Arulazi Dhesiaseelan
>Assignee: Sean O'Callaghan
>
> The following code on the SoapMessageContext returns null.
> javax.xml.namespace.QName operation = (javax.xml.namespace.QName) 
> smc.get(MessageContext.WSDL_OPERATION);
> I have annotated my web method with operationName tag.  But, still getting 
> null.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1829) xmlbean binding can not handle Exception

2009-01-08 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12662030#action_12662030
 ] 

Sean O'Callaghan commented on CXF-1829:
---

Recieved testcase from customer on similar issue so investigating this.

> xmlbean binding can not handle Exception
> 
>
> Key: CXF-1829
> URL: https://issues.apache.org/jira/browse/CXF-1829
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.1.1
>Reporter: quzhe
>Assignee: Sean O'Callaghan
> Attachments: my-app.zip, my-app2.zip
>
>
> hi,All:
> my webservice using xmlbean binding, when service have not throw a exception, 
> it is working fine, but when I add a throw exception, my webservice can not 
> start.
> here is my code:
> service:
> public InsertFmdeclarationResponse 
> insert(InsertFmdeclarationParamDocument.InsertFmdeclarationParam body) throws 
> TestException
> // when I add TestException, it can not working
> exception:
> @WebFault(name="TestException")
> public class TestException extends Exception{
> ...
> }
> the error trace is"
> Caused by: java.lang.NullPointerException
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.mapClass(XmlBeansSc
> hemaInitializer.java:165)
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.checkForExistence(X
> mlBeansSchemaInitializer.java:217)
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.begin(XmlBeansSchem
> aInitializer.java:142)
> at 
> org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceMode
> lVisitor.java:120)
> at 
> org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.j
> ava:74)
> at 
> org.apache.cxf.xmlbeans.XmlBeansDataBinding.initialize(XmlBeansDataBi
> nding.java:102)
> thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2009-01-08 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1952.
-


> Remove NodeLists from souirce as they are thread unsafe.
> 
>
> Key: CXF-1952
> URL: https://issues.apache.org/jira/browse/CXF-1952
> Project: CXF
>  Issue Type: Improvement
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2009-01-08 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1952.
---

   Resolution: Fixed
Fix Version/s: 2.2

> Remove NodeLists from souirce as they are thread unsafe.
> 
>
> Key: CXF-1952
> URL: https://issues.apache.org/jira/browse/CXF-1952
> Project: CXF
>  Issue Type: Improvement
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2009-01-08 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661983#action_12661983
 ] 

Sean O'Callaghan commented on CXF-1952:
---

Modified:

cxf/trunk/common/common/src/main/java/org/apache/cxf/helpers/DOMUtils.java
cxf/trunk/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/ReadHeadersInterceptor.java
cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/spring/JMSConduitBeanDefinitionParser.java
cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/spring/JMSDestinationBeanDefinitionParser.java
cxf/trunk/tools/wsdlto/frontend/jaxws/src/main/java/org/apache/cxf/tools/wsdlto/frontend/jaxws/customization/CustomizationParser.java


> Remove NodeLists from souirce as they are thread unsafe.
> 
>
> Key: CXF-1952
> URL: https://issues.apache.org/jira/browse/CXF-1952
> Project: CXF
>  Issue Type: Improvement
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2009-01-08 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661981#action_12661981
 ] 

Sean O'Callaghan commented on CXF-1952:
---

Modified:

cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/common/toolspec/parser/Form.java

cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/common/toolspec/parser/Option.java

cxf/trunk/tools/common/src/main/java/org/apache/cxf/tools/common/toolspec/parser/OptionGroup.java


> Remove NodeLists from souirce as they are thread unsafe.
> 
>
> Key: CXF-1952
> URL: https://issues.apache.org/jira/browse/CXF-1952
> Project: CXF
>  Issue Type: Improvement
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2009-01-07 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661560#action_12661560
 ] 

Sean O'Callaghan commented on CXF-1952:
---

Files affected:

distribution/src/main/release/samples/jaxws_dispatch_provider/src/demo/hwDispatch/client/Client.java

rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/spring/JettyHTTPServerEngineBeanDefinitionParser.java
rt/ws/addr/src/main/java/org/apache/cxf/ws/addressing/soap/MAPCodec.java
rt/ws/addr/src/test/java/org/apache/cxf/ws/addressing/soap/MAPCodecTest.java
rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/spring/PolicyFeatureBeanDefinitionParser.java


> Remove NodeLists from souirce as they are thread unsafe.
> 
>
> Key: CXF-1952
> URL: https://issues.apache.org/jira/browse/CXF-1952
> Project: CXF
>  Issue Type: Improvement
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1945) NullPointerException in W3CDOMStreamReader

2009-01-05 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1945.
-

Resolution: Fixed

Dan has made changes to make this thread safe.

> NullPointerException in W3CDOMStreamReader
> --
>
> Key: CXF-1945
> URL: https://issues.apache.org/jira/browse/CXF-1945
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.1
> Environment: Resin 3.1.7, Java 1.5
>Reporter: Harald Walker
>Assignee: Sean O'Callaghan
>
> The throw statement 'throw new IllegalStateException("Found type: " + 
> content.getClass().getName());' in the W3CDOMStreamReader class sometimes 
> fails with a null pointer exception. I am not able to reproduce it yet.
> [2008/12/13 13:34:15.647] java.lang.NullPointerException
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.W3CDOMStreamReader.moveToChild(W3CDOMStreamReader.java:167)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.AbstractDOMStreamReader.next(AbstractDOMStreamReader.java:144)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:351)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:313)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:299)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:121)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:279)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:161)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:174)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:152)
> [2008/12/13 13:34:15.647] at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
> [2008/12/13 13:34:15.647] at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:162)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:435)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.port.TcpConnection.run(TcpConnection.java:678)
> [2008/12/13 13:34:15.647] at 
> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
> [2008/12/13 13:34:15.647] at 
> com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
> [2008/12/13 13:34:15.647] at java.lang.Thread.run(Thread.java:595)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2009-01-05 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660798#action_12660798
 ] 

Sean O'Callaghan commented on CXF-1952:
---

also:

ReadHeaderInterceptorTest.java
and 
CustomizationParser.java


> Remove NodeLists from souirce as they are thread unsafe.
> 
>
> Key: CXF-1952
> URL: https://issues.apache.org/jira/browse/CXF-1952
> Project: CXF
>  Issue Type: Improvement
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2009-01-05 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660772#action_12660772
 ] 

Sean O'Callaghan commented on CXF-1952:
---

Removed another reference to NodeList from JsSimpleDomNode.java

> Remove NodeLists from souirce as they are thread unsafe.
> 
>
> Key: CXF-1952
> URL: https://issues.apache.org/jira/browse/CXF-1952
> Project: CXF
>  Issue Type: Improvement
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (CXF-1952) Remove NodeLists from souirce as they are thread unsafe.

2008-12-19 Thread Sean O'Callaghan (JIRA)
Remove NodeLists from souirce as they are thread unsafe.


 Key: CXF-1952
 URL: https://issues.apache.org/jira/browse/CXF-1952
 Project: CXF
  Issue Type: Improvement
Reporter: Sean O'Callaghan
Assignee: Sean O'Callaghan




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1945) NullPointerException in W3CDOMStreamReader

2008-12-17 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1945:
-

Assignee: Sean O'Callaghan

> NullPointerException in W3CDOMStreamReader
> --
>
> Key: CXF-1945
> URL: https://issues.apache.org/jira/browse/CXF-1945
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.1
> Environment: Resin 3.1.7, Java 1.5
>Reporter: Harald Walker
>Assignee: Sean O'Callaghan
>
> The throw statement 'throw new IllegalStateException("Found type: " + 
> content.getClass().getName());' in the W3CDOMStreamReader class sometimes 
> fails with a null pointer exception. I am not able to reproduce it yet.
> [2008/12/13 13:34:15.647] java.lang.NullPointerException
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.W3CDOMStreamReader.moveToChild(W3CDOMStreamReader.java:167)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.AbstractDOMStreamReader.next(AbstractDOMStreamReader.java:144)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:351)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:313)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:299)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:121)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:96)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:74)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:279)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:161)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:174)
> [2008/12/13 13:34:15.647] at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:152)
> [2008/12/13 13:34:15.647] at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
> [2008/12/13 13:34:15.647] at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.cache.CacheFilterChain.doFilter(CacheFilterChain.java:162)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:266)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.hmux.HmuxRequest.handleRequest(HmuxRequest.java:435)
> [2008/12/13 13:34:15.647] at 
> com.caucho.server.port.TcpConnection.run(TcpConnection.java:678)
> [2008/12/13 13:34:15.647] at 
> com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721)
> [2008/12/13 13:34:15.647] at 
> com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643)
> [2008/12/13 13:34:15.647] at java.lang.Thread.run(Thread.java:595)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-1937) certs out of date in jax_rs/basic_https sample

2008-12-11 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1937.
-

   Resolution: Fixed
Fix Version/s: 2.2

> certs out of date in jax_rs/basic_https sample
> --
>
> Key: CXF-1937
> URL: https://issues.apache.org/jira/browse/CXF-1937
> Project: CXF
>  Issue Type: Bug
>  Components: Samples
>Affects Versions: 2.2
>Reporter: Sean O'Callaghan
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (CXF-748) sample configuration files should all use a consistent extension

2008-12-10 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-748.



> sample configuration files should all use a consistent extension
> 
>
> Key: CXF-748
> URL: https://issues.apache.org/jira/browse/CXF-748
> Project: CXF
>  Issue Type: Task
>  Components: Configuration, Documentation
>Affects Versions: 2.0-M1
>Reporter: Eric Johnson
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
>
> There are several  samples that use configuration files that use a .cxf 
> extension. There are also a few tests that do the following. It would be 
> clearer if all of the configuration files used the same extension.
> My sugestion is that the extension should be .xml.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-748) sample configuration files should all use a consistent extension

2008-12-10 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-748.
--

   Resolution: Fixed
Fix Version/s: 2.2

> sample configuration files should all use a consistent extension
> 
>
> Key: CXF-748
> URL: https://issues.apache.org/jira/browse/CXF-748
> Project: CXF
>  Issue Type: Task
>  Components: Configuration, Documentation
>Affects Versions: 2.0-M1
>Reporter: Eric Johnson
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
>
> There are several  samples that use configuration files that use a .cxf 
> extension. There are also a few tests that do the following. It would be 
> clearer if all of the configuration files used the same extension.
> My sugestion is that the extension should be .xml.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (CXF-1937) certs out of date in jax_rs/basic_https sample

2008-12-09 Thread Sean O'Callaghan (JIRA)
certs out of date in jax_rs/basic_https sample
--

 Key: CXF-1937
 URL: https://issues.apache.org/jira/browse/CXF-1937
 Project: CXF
  Issue Type: Bug
  Components: Samples
Affects Versions: 2.2
Reporter: Sean O'Callaghan
Assignee: Sean O'Callaghan




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-748) sample configuration files should all use a consistent extension

2008-12-09 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-748:


Assignee: Sean O'Callaghan

> sample configuration files should all use a consistent extension
> 
>
> Key: CXF-748
> URL: https://issues.apache.org/jira/browse/CXF-748
> Project: CXF
>  Issue Type: Task
>  Components: Configuration, Documentation
>Affects Versions: 2.0-M1
>Reporter: Eric Johnson
>Assignee: Sean O'Callaghan
>
> There are several  samples that use configuration files that use a .cxf 
> extension. There are also a few tests that do the following. It would be 
> clearer if all of the configuration files used the same extension.
> My sugestion is that the extension should be .xml.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1888) Need to document the "jaxws:endpoint" attribute "createdFromAPI"

2008-12-09 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1888.
---

Resolution: Fixed

Added:

createdFromAPI  : This indicates that the endpoint bean was already created 
using jaxws API's thus at runtime when parsing the bean spring can use these 
values rather than the default ones. 

> Need to document the "jaxws:endpoint" attribute "createdFromAPI"
> 
>
> Key: CXF-1888
> URL: https://issues.apache.org/jira/browse/CXF-1888
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Joe Luo
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> The attribute "createdFromAPI" of the "jaxws:endpoint" element is not 
> documented (http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html).
> We need to document the attribute "createdFromAPI" of the "jaxws:endpoint".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1888) Need to document the "jaxws:endpoint" attribute "createdFromAPI"

2008-12-09 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1888:
-

Assignee: Sean O'Callaghan

> Need to document the "jaxws:endpoint" attribute "createdFromAPI"
> 
>
> Key: CXF-1888
> URL: https://issues.apache.org/jira/browse/CXF-1888
> Project: CXF
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Joe Luo
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> The attribute "createdFromAPI" of the "jaxws:endpoint" element is not 
> documented (http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html).
> We need to document the attribute "createdFromAPI" of the "jaxws:endpoint".

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-914) output jaxb stacktrace when log to FINE level in running hello_world sample.

2008-12-08 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-914:


Assignee: Sean O'Callaghan

> output jaxb stacktrace when log to FINE level in running hello_world sample.
> 
>
> Key: CXF-914
> URL: https://issues.apache.org/jira/browse/CXF-914
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.1
> Environment: Windows
>Reporter: Jeff Yu
>Assignee: Sean O'Callaghan
>Priority: Trivial
> Fix For: 2.2
>
>
> By setting the Log Level to FINE level, and then run the samples/hello_world 
> sample
> You would see this error stack in the server-side log.
> 
> FINE: Unable to inject 
> org/apache/hello_world_soap_http/types/GreetMe$JaxbAccessorF_requestType
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:125)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:48)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:51)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:128)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:204)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.(TransducedAccessor.java:195)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:137)
>   at 
> com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.(SingleElementLeafProperty.java:47)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
>   at 
> com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:88)
>   at 
> com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.(ClassBeanInfoImpl.java:135)
>   at 
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:432)
>   at 
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:265)
>   at 
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:76)
>   at 
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:55)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
>   at javax.xml.bind.ContextFinder.find(ContextFinder.java:366)
>   at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContext(JAXBDataBinding.java:370)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:180)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:214)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:262)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:143)
>   at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:89)
>   at 
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(AbstractEndpointFactory.java:82)
>   at 
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:107)
>   at 
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:146)
>   at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:285)
>   at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:226)
>   at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:178)
>   at 
> org.apache.cxf.jaxws.spi.ProviderImp

[jira] Resolved: (CXF-914) output jaxb stacktrace when log to FINE level in running hello_world sample.

2008-12-08 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-914.
--

   Resolution: Fixed
Fix Version/s: 2.2

tested against latest 2.2 snapshot and the problem no longer exists.

> output jaxb stacktrace when log to FINE level in running hello_world sample.
> 
>
> Key: CXF-914
> URL: https://issues.apache.org/jira/browse/CXF-914
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.1
> Environment: Windows
>Reporter: Jeff Yu
>Assignee: Sean O'Callaghan
>Priority: Trivial
> Fix For: 2.2
>
>
> By setting the Log Level to FINE level, and then run the samples/hello_world 
> sample
> You would see this error stack in the server-side log.
> 
> FINE: Unable to inject 
> org/apache/hello_world_soap_http/types/GreetMe$JaxbAccessorF_requestType
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:125)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:48)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:51)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:128)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:204)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.(TransducedAccessor.java:195)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:137)
>   at 
> com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.(SingleElementLeafProperty.java:47)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
>   at 
> com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:88)
>   at 
> com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.(ClassBeanInfoImpl.java:135)
>   at 
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:432)
>   at 
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:265)
>   at 
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:76)
>   at 
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:55)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
>   at javax.xml.bind.ContextFinder.find(ContextFinder.java:366)
>   at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContext(JAXBDataBinding.java:370)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:180)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:214)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:262)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:143)
>   at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:89)
>   at 
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(AbstractEndpointFactory.java:82)
>   at 
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:107)
>   at 
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:146)
>   at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:285)
>   at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:226)
>   at org.apache.cxf.jaxws.EndpointImp

[jira] Closed: (CXF-914) output jaxb stacktrace when log to FINE level in running hello_world sample.

2008-12-08 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-914.



> output jaxb stacktrace when log to FINE level in running hello_world sample.
> 
>
> Key: CXF-914
> URL: https://issues.apache.org/jira/browse/CXF-914
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.1
> Environment: Windows
>Reporter: Jeff Yu
>Assignee: Sean O'Callaghan
>Priority: Trivial
> Fix For: 2.2
>
>
> By setting the Log Level to FINE level, and then run the samples/hello_world 
> sample
> You would see this error stack in the server-side log.
> 
> FINE: Unable to inject 
> org/apache/hello_world_soap_http/types/GreetMe$JaxbAccessorF_requestType
> java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:125)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.Injector.inject(Injector.java:48)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.AccessorInjector.prepare(AccessorInjector.java:51)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.opt.OptimizedAccessorFactory.get(OptimizedAccessorFactory.java:128)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.Accessor$FieldReflection.optimize(Accessor.java:204)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.(TransducedAccessor.java:195)
>   at 
> com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor.get(TransducedAccessor.java:137)
>   at 
> com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.(SingleElementLeafProperty.java:47)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
>   at 
> com.sun.xml.bind.v2.runtime.property.PropertyFactory.create(PropertyFactory.java:88)
>   at 
> com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.(ClassBeanInfoImpl.java:135)
>   at 
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.getOrCreate(JAXBContextImpl.java:432)
>   at 
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:265)
>   at 
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:76)
>   at 
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:55)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:210)
>   at javax.xml.bind.ContextFinder.find(ContextFinder.java:366)
>   at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContext(JAXBDataBinding.java:370)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:180)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:214)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:262)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:143)
>   at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:89)
>   at 
> org.apache.cxf.frontend.AbstractEndpointFactory.createEndpoint(AbstractEndpointFactory.java:82)
>   at 
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:107)
>   at 
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:146)
>   at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:285)
>   at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:226)
>   at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:178)
>   at 
> org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl

[jira] Commented: (CXF-1161) Javadoc for classes generated XSD with WSDL is defective

2008-12-08 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654452#action_12654452
 ] 

Sean O'Callaghan commented on CXF-1161:
---

Have raised this as an issue with the jaxb RI project: 
https://jaxb.dev.java.net/issues/show_bug.cgi?id=575

> Javadoc for classes generated XSD with WSDL is defective
> 
>
> Key: CXF-1161
> URL: https://issues.apache.org/jira/browse/CXF-1161
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> I've added a 'form_test.xsd' file to the test resources for 
> rt/databinding/jaxb. This contains:
> 
> 
> 
> 
> 
> 
> The javadoc in the generated class lacks the form attribute.
> 
>
>  http://www.w3.org/2001/XMLSchema}anyType";>
>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>
>  
>
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1161) Javadoc for classes generated XSD with WSDL is defective

2008-12-08 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654442#action_12654442
 ] 

Sean O'Callaghan commented on CXF-1161:
---

Yyeah will do Benson.

> Javadoc for classes generated XSD with WSDL is defective
> 
>
> Key: CXF-1161
> URL: https://issues.apache.org/jira/browse/CXF-1161
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> I've added a 'form_test.xsd' file to the test resources for 
> rt/databinding/jaxb. This contains:
> 
> 
> 
> 
> 
> 
> The javadoc in the generated class lacks the form attribute.
> 
>
>  http://www.w3.org/2001/XMLSchema}anyType";>
>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>
>  
>
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1161) Javadoc for classes generated XSD with WSDL is defective

2008-12-08 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654441#action_12654441
 ] 

Sean O'Callaghan commented on CXF-1161:
---

Still an issue with the latest snapshot, however these files are generated by 
the JAXB reference implementation and not CXF code. 

> Javadoc for classes generated XSD with WSDL is defective
> 
>
> Key: CXF-1161
> URL: https://issues.apache.org/jira/browse/CXF-1161
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> I've added a 'form_test.xsd' file to the test resources for 
> rt/databinding/jaxb. This contains:
> 
> 
> 
> 
> 
> 
> The javadoc in the generated class lacks the form attribute.
> 
>
>  http://www.w3.org/2001/XMLSchema}anyType";>
>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>
>  
>
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1161) Javadoc for classes generated XSD with WSDL is defective

2008-12-08 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1161:
-

Assignee: Sean O'Callaghan

> Javadoc for classes generated XSD with WSDL is defective
> 
>
> Key: CXF-1161
> URL: https://issues.apache.org/jira/browse/CXF-1161
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.0.3
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> I've added a 'form_test.xsd' file to the test resources for 
> rt/databinding/jaxb. This contains:
> 
> 
> 
> 
> 
> 
> The javadoc in the generated class lacks the form attribute.
> 
>
>  http://www.w3.org/2001/XMLSchema}anyType";>
>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>   type="{http://www.w3.org/2001/XMLSchema}string"/>
>
>  
>
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1924) Infinite loop in FileUtils.getDefaultTempDir() when "java.io.tmpdir" directory does not exist

2008-12-05 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1924.
---

Resolution: Fixed

added check to code and a unit test

> Infinite loop in FileUtils.getDefaultTempDir() when "java.io.tmpdir" 
> directory does not exist
> -
>
> Key: CXF-1924
> URL: https://issues.apache.org/jira/browse/CXF-1924
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.4, 2.2
>Reporter: Jarek Gawor
>Assignee: Sean O'Callaghan
>
> FileUtils.getDefaultTempDir() can go into a infinite loop when the 
> "java.io.tmpdir" system property is set to an non-existent directory. Here's 
> the code that causes the problem:
> s = System.getProperty("java.io.tmpdir");
> File f = new File(s, "cxf-tmp-" + x);
> while (!f.mkdir()) {
> x = (int)(Math.random() * 100);
> f = new File(s, "cxf-tmp-" + x);
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1924) Infinite loop in FileUtils.getDefaultTempDir() when "java.io.tmpdir" directory does not exist

2008-12-05 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1924:
-

Assignee: Sean O'Callaghan

> Infinite loop in FileUtils.getDefaultTempDir() when "java.io.tmpdir" 
> directory does not exist
> -
>
> Key: CXF-1924
> URL: https://issues.apache.org/jira/browse/CXF-1924
> Project: CXF
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.1.4, 2.2
>Reporter: Jarek Gawor
>Assignee: Sean O'Callaghan
>
> FileUtils.getDefaultTempDir() can go into a infinite loop when the 
> "java.io.tmpdir" system property is set to an non-existent directory. Here's 
> the code that causes the problem:
> s = System.getProperty("java.io.tmpdir");
> File f = new File(s, "cxf-tmp-" + x);
> while (!f.mkdir()) {
> x = (int)(Math.random() * 100);
> f = new File(s, "cxf-tmp-" + x);
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-05 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1828.
---

   Resolution: Fixed
Fix Version/s: (was: 2.1.4)
   2.2

Fixed the original configuration_interceptor demo as it was not picking up the  
configuration files client.xml and server.xml correctly .

Using the provided files from Dimtry, the demo runs as expected:

server output:

[INFO] Executing operation pingMe, throwing PingMeFault exception
[INFO]
[INFO] INFO: Executing operation pingMe, throwing PingMeFault exception
[INFO] 05-Dec-2008 14:32:48 org.apache.cxf.phase.PhaseInterceptorChain 
doIntercept
[INFO] INFO: Application has thrown exception, unwinding now: 
org.apache.hello_world_soap_http.PingMeFault: PingMeFault raised by server

> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.crea

[jira] Closed: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-05 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-1828.
-


> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.2
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:81)
>  [java]   ... 14 more
>  [java] Caused by: java.io.CharConversionException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:302)
>  [java]   at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:188)
>  [java]   at 
> com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:245)
>  [java]   at 
> com.ctc

[jira] Updated: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-04 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan updated CXF-1828:
--

Comment: was deleted

> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.1.4
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:81)
>  [java]   ... 14 more
>  [java] Caused by: java.io.CharConversionException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:302)
>  [java]   at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:188)
>  [java]   at 
> com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:245)

[jira] Issue Comment Edited: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-04 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653332#action_12653332
 ] 

seanoc edited comment on CXF-1828 at 12/4/08 7:41 AM:


The problem can be reproduced using the standard configuration_interceptor 
demo, on the trunk.

However there is some behaviour which is a little bizzare:

It seems that if the server is run within eclipse the demo will run fine but if 
run from the command line it will fail. This is irrespective of whether the 
client is tun in eclipse or command line.

This indicates some resource or environmental factor in the problem, perhaps 
classpath but I haven't been able to figure out  what exactly yet.



  was (Author: seanoc):
Some behaviour which is a little bizzare.

It seems that if the server is run within eclipse the demo will run fine but if 
run from the command line it will fail.
This indicates some resource or environmental factor in the problem, perhaps 
classpath but I haven't been able to figure out  what exactly yet.


  
> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.1.4
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b 

[jira] Commented: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-04 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12653332#action_12653332
 ] 

Sean O'Callaghan commented on CXF-1828:
---

Some behaviour which is a little bizzare.

It seems that if the server is run within eclipse the demo will run fine but if 
run from the command line it will fail.
This indicates some resource or environmental factor in the problem, perhaps 
classpath but I haven't been able to figure out  what exactly yet.



> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.1.4
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:81)
>  [java]   ... 14 more
>  [java] Caused by: java.io.

[jira] Updated: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-04 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan updated CXF-1828:
--

Comment: was deleted

> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.1.4
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:81)
>  [java]   ... 14 more
>  [java] Caused by: java.io.CharConversionException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:302)
>  [java]   at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:188)
>  [java]   at 
> com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:245)

[jira] Commented: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-02 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652424#action_12652424
 ] 

Sean O'Callaghan commented on CXF-1828:
---

Hi Dmitry,

I've just begun looking at this and can reproduce the issue with the 
configuration_interceptor as is(without your modifications). 

(Note, I'm working off trunk 2.2-SNAPSHOT).

I then modified the client so that instead of having the WSDL passed into it, 
it was read in as a resource:

wsdlURL = Client.class.getResource("hello_world.wsdl");

You will need to modify the pom.xml in order for the Client.class to be able to 
access the wsdl;

 
   
   
add this line
 


I haven't figured out why the difference in behaviour but am curious as to what 
behaviour you see after such changes?

Seán.




> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.1.4
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.creat

[jira] Assigned: (CXF-1828) inFaultInterceptors doesn't work as expected

2008-12-02 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1828:
-

Assignee: Sean O'Callaghan

> inFaultInterceptors doesn't work as expected
> 
>
> Key: CXF-1828
> URL: https://issues.apache.org/jira/browse/CXF-1828
> Project: CXF
>  Issue Type: Bug
>  Components: Bus, Samples
>Affects Versions: 2.1.1, 2.1.2, 2.1.3
> Environment: java 1.6
>Reporter: Dmitry
>Assignee: Sean O'Callaghan
> Fix For: 2.1.4
>
> Attachments: Client.java, client.xml, server.xml
>
>
> I'm trying to zip FAULT response from server. 
> Server properly zip response , so server's [outFaultInterceptors] work fine
> But, It looks like client couldn't properly process it in 
> [inFaultInterceptors]
> Step to reproduce:
> 1. Upade sample code from standart distributive 
>  apache-cxf-2.1.2/samples/configuration_interceptor 
> client.xml:
> 
> 
> 
> 
> 
> 
> 
> 
> server:xml:
> 
> 
> 
> 
> 
>
>  
> 
> 
> Client.java:
> add next code and uncomment //import lines:
> import org.apache.hello_world_soap_http.PingMeFault;
> import org.apache.hello_world_soap_http.types.FaultDetail;
> ...
> try {
> System.out.println("Invoking pingMe, expecting exception...");
> port.pingMe();
> } catch (PingMeFault ex) {
> System.out.println("Expected exception: PingMeFault has occurred: 
> " + ex.getMessage());
> FaultDetail detail = ex.getFaultInfo();
> System.out.println("FaultDetail major:" + detail.getMajor());
> System.out.println("FaultDetail minor:" + detail.getMinor()); 
>
> }  
> System.exit(0); 
> }
> Result: 
>  [java] Invoking pingMe, expecting exception...
>  [java] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: 
> Could not create XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:199)
>  [java]   at $Proxy41.pingMe(Unknown Source)
>  [java]   at demo.stream.client.Client.main(Client.java:67)
>  [java] Caused by: org.apache.cxf.interceptor.Fault: Could not create 
> XMLStreamReader (input was of encoding UTF-8).
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:449)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1996)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1832)
>  [java]   at 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at 
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:591)
>  [java]   at 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>  [java]   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:296)
>  [java]   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:242)
>  [java]   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>  [java]   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:178)
>  [java]   ... 2 more
>  [java] Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
>  [java]   at 
> com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
>  [java]   at 
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:81)
>  [java]   ... 14 more
>  [java] Caused by: java.io.CharConversionException: Invalid UTF-8 start 
> byte 0x8b (at char #2, byte #-1)
>  [java]   at 
> com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:302)
>  [java]   at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:188)
>  [java]   at 
> com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrappe

[jira] Commented: (CXF-1829) xmlbean binding can not handle Exception

2008-09-30 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635716#action_12635716
 ] 

Sean O'Callaghan commented on CXF-1829:
---

Do you have  a testcase that would allow me to reproduce this?


> xmlbean binding can not handle Exception
> 
>
> Key: CXF-1829
> URL: https://issues.apache.org/jira/browse/CXF-1829
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.1.1
>Reporter: quzhe
>Assignee: Sean O'Callaghan
>
> hi,All:
> my webservice using xmlbean binding, when service have not throw a exception, 
> it is working fine, but when I add a throw exception, my webservice can not 
> start.
> here is my code:
> service:
> public InsertFmdeclarationResponse 
> insert(InsertFmdeclarationParamDocument.InsertFmdeclarationParam body) throws 
> TestException
> // when I add TestException, it can not working
> exception:
> @WebFault(name="TestException")
> public class TestException extends Exception{
> ...
> }
> the error trace is"
> Caused by: java.lang.NullPointerException
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.mapClass(XmlBeansSc
> hemaInitializer.java:165)
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.checkForExistence(X
> mlBeansSchemaInitializer.java:217)
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.begin(XmlBeansSchem
> aInitializer.java:142)
> at 
> org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceMode
> lVisitor.java:120)
> at 
> org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.j
> ava:74)
> at 
> org.apache.cxf.xmlbeans.XmlBeansDataBinding.initialize(XmlBeansDataBi
> nding.java:102)
> thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1829) xmlbean binding can not handle Exception

2008-09-30 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1829:
-

Assignee: Sean O'Callaghan

> xmlbean binding can not handle Exception
> 
>
> Key: CXF-1829
> URL: https://issues.apache.org/jira/browse/CXF-1829
> Project: CXF
>  Issue Type: Bug
>  Components: JAXB Databinding
>Affects Versions: 2.1.1
>Reporter: quzhe
>Assignee: Sean O'Callaghan
>
> hi,All:
> my webservice using xmlbean binding, when service have not throw a exception, 
> it is working fine, but when I add a throw exception, my webservice can not 
> start.
> here is my code:
> service:
> public InsertFmdeclarationResponse 
> insert(InsertFmdeclarationParamDocument.InsertFmdeclarationParam body) throws 
> TestException
> // when I add TestException, it can not working
> exception:
> @WebFault(name="TestException")
> public class TestException extends Exception{
> ...
> }
> the error trace is"
> Caused by: java.lang.NullPointerException
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.mapClass(XmlBeansSc
> hemaInitializer.java:165)
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.checkForExistence(X
> mlBeansSchemaInitializer.java:217)
> at 
> org.apache.cxf.xmlbeans.XmlBeansSchemaInitializer.begin(XmlBeansSchem
> aInitializer.java:142)
> at 
> org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceMode
> lVisitor.java:120)
> at 
> org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.j
> ava:74)
> at 
> org.apache.cxf.xmlbeans.XmlBeansDataBinding.initialize(XmlBeansDataBi
> nding.java:102)
> thank you!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1785) wsdlLocation attribute and XmlBeans: Getting NullPointerException/UNMARSHALL_ERROR

2008-09-24 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634167#action_12634167
 ] 

Sean O'Callaghan commented on CXF-1785:
---

Hi Juan,

Do you have a simple testcase which I could use to recreate this problem?

Regards,

Seán.

> wsdlLocation attribute and XmlBeans: Getting 
> NullPointerException/UNMARSHALL_ERROR
> --
>
> Key: CXF-1785
> URL: https://issues.apache.org/jira/browse/CXF-1785
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: WinXP Pro SP3, Java 1.6, Spring 2.5, XmlBeans 2.3.0, CXF 
> 2.1
>Reporter: Juan Velez
>Assignee: Sean O'Callaghan
> Attachments: MMI CXF.zip
>
>
> I have created my own WSDL and its corresponding service and implementation 
> classes (annotated of course). When I do not use the wsdlLocation attribute 
> on jaxws:endpoint, the request I send to the service works fine, but when I 
> specify the wsdlLocation attribute, I get a 
> NullPointerException/UNMARSHAL_ERROR from the XmlBeans databinding used by 
> CXF. Any ideas where I am not doing it correctly?
> Error
> java.lang.NullPointerException
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:73)
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:43)
> at 
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:183)
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> at 
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:214)
> at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:151)
> at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
> at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> com.arevatd.mmi.pjm.filters.CLUProgramContextFilter.doFilter(CLUProgramContextFilter.java:56)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 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:175)
> 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:286)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> Sep 4, 2008 12:35:49 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: UNMARSHAL_ERROR
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:81)
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:43)
> at 
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:183)
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> at 
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:214)
> at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:151)
>  

[jira] Assigned: (CXF-1785) wsdlLocation attribute and XmlBeans: Getting NullPointerException/UNMARSHALL_ERROR

2008-09-08 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1785:
-

Assignee: Sean O'Callaghan

> wsdlLocation attribute and XmlBeans: Getting 
> NullPointerException/UNMARSHALL_ERROR
> --
>
> Key: CXF-1785
> URL: https://issues.apache.org/jira/browse/CXF-1785
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.1
> Environment: WinXP Pro SP3, Java 1.6, Spring 2.5, XmlBeans 2.3.0, CXF 
> 2.1
>Reporter: Juan Velez
>Assignee: Sean O'Callaghan
> Attachments: MMI CXF.zip
>
>
> I have created my own WSDL and its corresponding service and implementation 
> classes (annotated of course). When I do not use the wsdlLocation attribute 
> on jaxws:endpoint, the request I send to the service works fine, but when I 
> specify the wsdlLocation attribute, I get a 
> NullPointerException/UNMARSHAL_ERROR from the XmlBeans databinding used by 
> CXF. Any ideas where I am not doing it correctly?
> Error
> java.lang.NullPointerException
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:73)
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:43)
> at 
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:183)
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> at 
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:214)
> at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:151)
> at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
> at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:148)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> com.arevatd.mmi.pjm.filters.CLUProgramContextFilter.doFilter(CLUProgramContextFilter.java:56)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 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:175)
> 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:286)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> at java.lang.Thread.run(Thread.java:595)
> Sep 4, 2008 12:35:49 PM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: UNMARSHAL_ERROR
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:81)
> at org.apache.cxf.xmlbeans.DataReaderImpl.read(DataReaderImpl.java:43)
> at 
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:183)
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:78)
> at 
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:92)
> at 
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:214)
> at 
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:151)
> at 
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:170)
> at 
> org

[jira] Closed: (CXF-924) Java2wsdl tool could use better error message

2008-09-04 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan closed CXF-924.


Resolution: Fixed

Using 2.2-SNAPSHOT Unable to reproduce the problem

> Java2wsdl tool could use better error message
> -
>
> Key: CXF-924
> URL: https://issues.apache.org/jira/browse/CXF-924
> Project: CXF
>  Issue Type: Bug
>Reporter: Bozhong Lin
>Assignee: Sean O'Callaghan
>
> Please see the mailing list discussion for the problem:
> http://www.nabble.com/Java2Wsdl-Error-%3A-ClassCastException-tf4293141.html#a12221320

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-924) Java2wsdl tool could use better error message

2008-09-04 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-924:


Assignee: Sean O'Callaghan

> Java2wsdl tool could use better error message
> -
>
> Key: CXF-924
> URL: https://issues.apache.org/jira/browse/CXF-924
> Project: CXF
>  Issue Type: Bug
>Reporter: Bozhong Lin
>Assignee: Sean O'Callaghan
>
> Please see the mailing list discussion for the problem:
> http://www.nabble.com/Java2Wsdl-Error-%3A-ClassCastException-tf4293141.html#a12221320

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (CXF-1365) Too much error message for missing class in java2 tools

2008-09-03 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628032#action_12628032
 ] 

seanoc edited comment on CXF-1365 at 9/3/08 9:55 AM:
---

http://svn.apache.org/viewvc?view=rev&revision=691646

JavaToWS now catches Throwable rather than Exception.

  was (Author: seanoc):
http://svn.apache.org/viewvc?view=rev&revision=691646
  
> Too much error message for missing class in java2 tools
> ---
>
> Key: CXF-1365
> URL: https://issues.apache.org/jira/browse/CXF-1365
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> i respectfully submit that this is Too Much Information. When the java2 
> process gets a class not found, it should 
> result in a simple error message and no backtrace.
> bim-1330% $CXF_HOME/bin/java2js  -cp 
> ~/x/tip/crosslang/source/ws/demo1/bin:/home/benson/x/tip/rlp/lib_g/ia32-glibc25-gcc42/btutil.jar/home/benson/x/tip/rlp/lib_g/ia32-glibc25-gcc42/btrlpnc.jar
>  com.basistech.searchtools.demo1.CrossLangDemo1
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> Lcom/basistech/util/LanguageCode;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
> at java.lang.Class.getDeclaredFields(Class.java:1715)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.walkReferences(JAXBContextInitializer.java:190)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.addClass(JAXBContextInitializer.java:165)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.addType(JAXBContextInitializer.java:129)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.begin(JAXBContextInitializer.java:89)
> at 
> org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceModelVisitor.java:85)
> at 
> org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.ja

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1365) Too much error message for missing class in java2 tools

2008-09-03 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1365.
---

Resolution: Fixed

http://svn.apache.org/viewvc?view=rev&revision=691646

> Too much error message for missing class in java2 tools
> ---
>
> Key: CXF-1365
> URL: https://issues.apache.org/jira/browse/CXF-1365
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> i respectfully submit that this is Too Much Information. When the java2 
> process gets a class not found, it should 
> result in a simple error message and no backtrace.
> bim-1330% $CXF_HOME/bin/java2js  -cp 
> ~/x/tip/crosslang/source/ws/demo1/bin:/home/benson/x/tip/rlp/lib_g/ia32-glibc25-gcc42/btutil.jar/home/benson/x/tip/rlp/lib_g/ia32-glibc25-gcc42/btrlpnc.jar
>  com.basistech.searchtools.demo1.CrossLangDemo1
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> Lcom/basistech/util/LanguageCode;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
> at java.lang.Class.getDeclaredFields(Class.java:1715)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.walkReferences(JAXBContextInitializer.java:190)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.addClass(JAXBContextInitializer.java:165)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.addType(JAXBContextInitializer.java:129)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.begin(JAXBContextInitializer.java:89)
> at 
> org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceModelVisitor.java:85)
> at 
> org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.ja

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1340) wsdl2java overwrites objectFactory methods if multiple service classes are in the same package, causes value type inheritance problems

2008-09-02 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1340.
---

Resolution: Fixed

Have commited a fix for CXF-1662 which also applies to this. 
http://svn.apache.org/viewvc?view=rev&revision=691237



> wsdl2java overwrites objectFactory methods if multiple service classes are in 
> the same package, causes value type inheritance problems
> --
>
> Key: CXF-1340
> URL: https://issues.apache.org/jira/browse/CXF-1340
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.0.3, 2.1
> Environment: Windows XP, eclipse
>Reporter: Incognito
>Assignee: Sean O'Callaghan
> Attachments: cxf-issue-objectFactory.zip
>
>
> If you have two wsdl-based services, who's wsdl2java output is in the same 
> package, the outputted objectFactory retains only the most recent service's 
> methods. 
> For example:
> Given two wsdl files, CarService.wsdl and UserService.wsdl; if one executes 
> the wsdl2java binary with both services; with CarService first and 
> UserService second, and with both service classes being output in package 
> org.example.api, then only one objectFactory.java class will be created. 
> First, objectFactory will be created with the objects for CarService.wsdl, 
> and then it will be overwritten with UserService.wsdl's objects. 
> It just so happens that in this scenario, if the former service contains an 
> object that is abstract, that is, that it contains types that inherit via 
> wsdl's extension keyword, AND methods for creating instances of 
> CarService.wsdl's outputted java are NOT present in objectFactory.java, then 
> CXF does not include type information in the SOAP messages. 
> For example: 
> given an alternate CarService.wsdl with the following types:
>   
> ...
>   
>   
> 
>  ...
> 
>   
> If CarService.wsdl also had a method called getCarById, and wsdl2java output 
> 2 java classes: getCarById.java and getCarByIdResponse.java, AND wsdl2java on 
> UserService.wsdl was executed AFTER it was executed on CarService (resulting 
> in an objectFactory without create methods for getCar*), then CXF will send 
> SOAP messages like the following
> 
> 
>...
>   
> 
> The ultimate result is that if a project has more than 1 service being output 
> in the same package AND if more than 1 type in those two services use type 
> extension, then CXF will have problems marshalling those classes because it 
> will end up leaving out the type information for all classes not included in 
> the ObjectFactory. One alternative would be to have the wsdl2java classes be 
> output to multiple packages. If the different services shared types, this 
> would result in duplicated code in each service.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1340) wsdl2java overwrites objectFactory methods if multiple service classes are in the same package, causes value type inheritance problems

2008-09-02 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1340:
-

Assignee: Sean O'Callaghan

> wsdl2java overwrites objectFactory methods if multiple service classes are in 
> the same package, causes value type inheritance problems
> --
>
> Key: CXF-1340
> URL: https://issues.apache.org/jira/browse/CXF-1340
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.0.3, 2.1
> Environment: Windows XP, eclipse
>Reporter: Incognito
>Assignee: Sean O'Callaghan
> Attachments: cxf-issue-objectFactory.zip
>
>
> If you have two wsdl-based services, who's wsdl2java output is in the same 
> package, the outputted objectFactory retains only the most recent service's 
> methods. 
> For example:
> Given two wsdl files, CarService.wsdl and UserService.wsdl; if one executes 
> the wsdl2java binary with both services; with CarService first and 
> UserService second, and with both service classes being output in package 
> org.example.api, then only one objectFactory.java class will be created. 
> First, objectFactory will be created with the objects for CarService.wsdl, 
> and then it will be overwritten with UserService.wsdl's objects. 
> It just so happens that in this scenario, if the former service contains an 
> object that is abstract, that is, that it contains types that inherit via 
> wsdl's extension keyword, AND methods for creating instances of 
> CarService.wsdl's outputted java are NOT present in objectFactory.java, then 
> CXF does not include type information in the SOAP messages. 
> For example: 
> given an alternate CarService.wsdl with the following types:
>   
> ...
>   
>   
> 
>  ...
> 
>   
> If CarService.wsdl also had a method called getCarById, and wsdl2java output 
> 2 java classes: getCarById.java and getCarByIdResponse.java, AND wsdl2java on 
> UserService.wsdl was executed AFTER it was executed on CarService (resulting 
> in an objectFactory without create methods for getCar*), then CXF will send 
> SOAP messages like the following
> 
> 
>...
>   
> 
> The ultimate result is that if a project has more than 1 service being output 
> in the same package AND if more than 1 type in those two services use type 
> extension, then CXF will have problems marshalling those classes because it 
> will end up leaving out the type information for all classes not included in 
> the ObjectFactory. One alternative would be to have the wsdl2java classes be 
> output to multiple packages. If the different services shared types, this 
> would result in duplicated code in each service.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1662) wsdl2java should check if using -p is safe to use

2008-09-02 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1662.
---

Resolution: Fixed

http://svn.apache.org/viewvc?rev=691237&view=rev

> wsdl2java should check if using -p is safe to use
> -
>
> Key: CXF-1662
> URL: https://issues.apache.org/jira/browse/CXF-1662
> Project: CXF
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Daniel Kulp
>Assignee: Sean O'Callaghan
>
> If a wsdl has schemas in multiple namespaces and you use "-p package" to map 
> everything to one package, the result won't work with jaxb.   We need to 
> detect that and output a bunch of warnings about it.   Each schema needs it's 
> own package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1365) Too much error message for missing class in java2 tools

2008-08-26 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1365:
-

Assignee: Sean O'Callaghan

> Too much error message for missing class in java2 tools
> ---
>
> Key: CXF-1365
> URL: https://issues.apache.org/jira/browse/CXF-1365
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Sean O'Callaghan
>
> i respectfully submit that this is Too Much Information. When the java2 
> process gets a class not found, it should 
> result in a simple error message and no backtrace.
> bim-1330% $CXF_HOME/bin/java2js  -cp 
> ~/x/tip/crosslang/source/ws/demo1/bin:/home/benson/x/tip/rlp/lib_g/ia32-glibc25-gcc42/btutil.jar/home/benson/x/tip/rlp/lib_g/ia32-glibc25-gcc42/btrlpnc.jar
>  com.basistech.searchtools.demo1.CrossLangDemo1
> Exception in thread "main" java.lang.NoClassDefFoundError: 
> Lcom/basistech/util/LanguageCode;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2259)
> at java.lang.Class.getDeclaredFields(Class.java:1715)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.walkReferences(JAXBContextInitializer.java:190)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.addClass(JAXBContextInitializer.java:165)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.addType(JAXBContextInitializer.java:129)
> at 
> org.apache.cxf.jaxb.JAXBContextInitializer.begin(JAXBContextInitializer.java:89)
> at 
> org.apache.cxf.service.ServiceModelVisitor.visitOperation(ServiceModelVisitor.java:85)
> at 
> org.apache.cxf.service.ServiceModelVisitor.walk(ServiceModelVisitor.ja

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (CXF-1662) wsdl2java should check if using -p is safe to use

2008-08-26 Thread Sean O'Callaghan (JIRA)

[ 
https://issues.apache.org/jira/browse/CXF-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625729#action_12625729
 ] 

Sean O'Callaghan commented on CXF-1662:
---

I tested this and it appears that a warning is being issued:

C:\CXFISSUES\CXF1662>wsdl2java -p test.sean hello_world.wsdl

WSDLToJava Error: Thrown by JAXB : A class/interface with the same name "test.se
an.FaultDetail" is already in use. Use a class customization to resolve this con
flict.



> wsdl2java should check if using -p is safe to use
> -
>
> Key: CXF-1662
> URL: https://issues.apache.org/jira/browse/CXF-1662
> Project: CXF
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Daniel Kulp
>Assignee: Sean O'Callaghan
>
> If a wsdl has schemas in multiple namespaces and you use "-p package" to map 
> everything to one package, the result won't work with jaxb.   We need to 
> detect that and output a bunch of warnings about it.   Each schema needs it's 
> own package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (CXF-1662) wsdl2java should check if using -p is safe to use

2008-08-25 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1662:
-

Assignee: Sean O'Callaghan

> wsdl2java should check if using -p is safe to use
> -
>
> Key: CXF-1662
> URL: https://issues.apache.org/jira/browse/CXF-1662
> Project: CXF
>  Issue Type: Improvement
>  Components: Tooling
>Reporter: Daniel Kulp
>Assignee: Sean O'Callaghan
>
> If a wsdl has schemas in multiple namespaces and you use "-p package" to map 
> everything to one package, the result won't work with jaxb.   We need to 
> detect that and output a bunch of warnings about it.   Each schema needs it's 
> own package.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (CXF-1694) NPE with invalid wsld:import

2008-08-25 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1694.
---

Resolution: Fixed

Fixed: http://svn.apache.org/viewvc?rev=688735&view=rev

> NPE with invalid wsld:import
> 
>
> Key: CXF-1694
> URL: https://issues.apache.org/jira/browse/CXF-1694
> Project: CXF
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: 2.1.1
> Environment: Windows XP, JDK 1.6.0 r6
>Reporter: Dan Retzlaff
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> When a WSDL specifies an incorrect namespace for a imported WSDL, code 
> generation throws a nondescript NPE. The call stack and a test case follow.
> org.apache.maven.lifecycle.LifecycleExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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: 
> java.lang.NullPointerException
> at 
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:348)
> at 
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:223)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.cxf.tools.common.ToolException: 
> java.lang.NullPointerException
> at 
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:240)
> at 
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
> at 
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:344)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.getXNode(WSDLRefValidator.java:305)
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.collectValidationPointsForBindings(WSDLRefValidator.java:398)
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.collectValidationPoints(WSDLRefValidator.java:383)
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.isValid(WSDLRefValidator.java:214)
> at 
> org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11Validator.java:126)
> at 
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:200)
> at 
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:62)
> at 
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:132)
> at 
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:232)
> ... 22 more
> http://schemas.xmlsoap.org/wsdl/"; name="Parent">
> http://incorrect-namespace"; location="child.wsdl" 
> />
> 
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
>   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
>   xmlns:xs="http://www.w3.org/2001/XMLSchema";
>   xmlns:tns="http://child/";
>   xmlns:xsd="http://child/xsd"

[jira] Assigned: (CXF-1694) NPE with invalid wsld:import

2008-08-22 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan reassigned CXF-1694:
-

Assignee: Sean O'Callaghan

> NPE with invalid wsld:import
> 
>
> Key: CXF-1694
> URL: https://issues.apache.org/jira/browse/CXF-1694
> Project: CXF
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: 2.1.1
> Environment: Windows XP, JDK 1.6.0 r6
>Reporter: Dan Retzlaff
>Assignee: Sean O'Callaghan
>Priority: Minor
>
> When a WSDL specifies an incorrect namespace for a imported WSDL, code 
> generation throws a nondescript NPE. The call stack and a test case follow.
> org.apache.maven.lifecycle.LifecycleExecutionException: 
> java.lang.NullPointerException
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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: 
> java.lang.NullPointerException
> at 
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:348)
> at 
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:223)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.cxf.tools.common.ToolException: 
> java.lang.NullPointerException
> at 
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:240)
> at 
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
> at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
> at 
> org.apache.cxf.maven_plugin.WSDL2JavaMojo.processWsdl(WSDL2JavaMojo.java:344)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.getXNode(WSDLRefValidator.java:305)
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.collectValidationPointsForBindings(WSDLRefValidator.java:398)
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.collectValidationPoints(WSDLRefValidator.java:383)
> at 
> org.apache.cxf.tools.validator.internal.WSDLRefValidator.isValid(WSDLRefValidator.java:214)
> at 
> org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11Validator.java:126)
> at 
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:200)
> at 
> org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:62)
> at 
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:132)
> at 
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:232)
> ... 22 more
> http://schemas.xmlsoap.org/wsdl/"; name="Parent">
> http://incorrect-namespace"; location="child.wsdl" 
> />
> 
>xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
>   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
>   xmlns:xs="http://www.w3.org/2001/XMLSchema";
>   xmlns:tns="http://child/";
>   xmlns:xsd="http://child/xsd";
>   targetNamespace="http://child/";>
>   

[jira] Resolved: (CXF-1076) Wsdl2Java out of memory if the wsdl has tons of imports

2008-08-22 Thread Sean O'Callaghan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CXF-1076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean O'Callaghan resolved CXF-1076.
---

Resolution: Fixed

http://svn.apache.org/viewvc?view=rev&revision=688102

> Wsdl2Java out of memory if the wsdl has tons of imports
> ---
>
> Key: CXF-1076
> URL: https://issues.apache.org/jira/browse/CXF-1076
> Project: CXF
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: 2.0.2
>Reporter: maomaode
>Assignee: Sean O'Callaghan
>
> we should add something like -Xmx128M into the scripts

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



  1   2   >