[jira] Commented: (CXF-2605) Object argument is passed as null

[Ravi Sukheja (JIRA)]

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

Ravi Sukheja commented on CXF-2605:
---

I have attached the wsdl of our service, and here is the input and output 
message. As I mentioned earlier, the object that reaches the service is null.

-
2010-01-08 10:08:18 [btpool0-7] - Inbound Message

ID: 1
Address: /services/StatusService
Encoding: UTF-8
Content-Type: text/xml; charset=utf-8
Headers: {content-type=[text/xml; charset=utf-8], Host=[localhost:8099], 
Content-Length=[523], SOAPAction=[""], User-Agent=[Axis/1.1], 
Content-Type=[text/xml; charset=utf-8], Accept=[application/soap+xml, 
application/dime, multipart/related, text/*], Pragma=[no-cache], 
Cache-Control=[no-cache]}
Payload: 
http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
 
  http://status.service.corymbus.db.com";>
   
http://filter.corymbus.db.com";>2453263,
false

   
  
 

--

2010-01-08 10:08:19 [btpool0-7] - Outbound Message
---
ID: 1
Encoding: UTF-8
Content-Type: text/xml
Headers: {}
Payload: http://schemas.xmlsoap.org/soap/envelope/";>soap:ServerFault
 occurred while 
processing.
--



> Object argument is passed as null
> -
>
> Key: CXF-2605
> URL: https://issues.apache.org/jira/browse/CXF-2605
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Ravi Sukheja
> Attachments: StatusService.xml
>
>
> Hi,
> We are using CXF-2.1.1 for our webservices and rest services, recently I 
> upgraded it to 2.2.4 as there was bug 2ith 2.1.1 when you go to /services to 
> view the list of all webservices and rest services. Upgrading to 2.2.4 seems 
> to fix that problem, but one of our webservice has stopped working, client is 
> passing the right object argument, but the service is getting null. I don't 
> know what the problem is. Any help would be appreciated.

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

[jira] Commented: (CXF-2605) Object argument is passed as null

[Ravi Sukheja (JIRA)]

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

Ravi Sukheja commented on CXF-2605:
---

Another point to mention, when I updated the cxf jar (cxf-2.2.4.jar), I had to 
update jsr311-api-1.0.jar and XmlSchema-1.4.5.jar, previously we were using 
jsr311-api-0.6.jar and XmlSchema-1.4.2.jar. I did not update any other jar 
file. We are using jaxb-api-2.1.jar and jaxb-impl-2.1.6.jar

> Object argument is passed as null
> -
>
> Key: CXF-2605
> URL: https://issues.apache.org/jira/browse/CXF-2605
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Ravi Sukheja
> Attachments: StatusService.xml
>
>
> Hi,
> We are using CXF-2.1.1 for our webservices and rest services, recently I 
> upgraded it to 2.2.4 as there was bug 2ith 2.1.1 when you go to /services to 
> view the list of all webservices and rest services. Upgrading to 2.2.4 seems 
> to fix that problem, but one of our webservice has stopped working, client is 
> passing the right object argument, but the service is getting null. I don't 
> know what the problem is. Any help would be appreciated.

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

[jira] Updated: (CXF-2605) Object argument is passed as null

[Ravi Sukheja (JIRA)]

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

Ravi Sukheja updated CXF-2605:
--

Attachment: StatusService.xml

WSDL for the services

> Object argument is passed as null
> -
>
> Key: CXF-2605
> URL: https://issues.apache.org/jira/browse/CXF-2605
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Ravi Sukheja
> Attachments: StatusService.xml
>
>
> Hi,
> We are using CXF-2.1.1 for our webservices and rest services, recently I 
> upgraded it to 2.2.4 as there was bug 2ith 2.1.1 when you go to /services to 
> view the list of all webservices and rest services. Upgrading to 2.2.4 seems 
> to fix that problem, but one of our webservice has stopped working, client is 
> passing the right object argument, but the service is getting null. I don't 
> know what the problem is. Any help would be appreciated.

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

[jira] Commented: (CXF-2604) Issue with multiple REST methods having List arguments

[Sergey Beryozkin (JIRA)]

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

Sergey Beryozkin commented on CXF-2604:
---

Alan, how do you enable Aegis, by registering AegisElementProvider or using 
jaxrs:databinding ? 

> Issue with multiple REST methods having List arguments
> -
>
> Key: CXF-2604
> URL: https://issues.apache.org/jira/browse/CXF-2604
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding, JAX-RS
>Affects Versions: 2.2.5
> Environment: JBoss 4.3 Using CXF 2.2.5
>Reporter: Alan Hazelton
>
> I have a REST based service method that takes a List parameter.  The 
> method is annotated with @POST and I can verify that the XML body of the POST 
> request from the server expects the top level element to be  and 
> a second method that takes a List parameter.
> It is important to note that the Foo and Bar classes are in different 
> packages and therefore the namespaces are different.
> The service would look something like this:
> My resource is defined like this:
> @Path("/")
> public class SomeResource {
>   @POST
>   @Path("/foo/update")
>   void postFoo(List list) {}
>  
>   @POST
>   @Path("/bar/update")
>   void postBar(List list) {}
> } 
> When I stop the server in the debugger after posting to "/foo/update" I can 
> see that in the org.apache.cxf.aegis.type.TypeUtil class the 
> getReadTypeStandalone() method is invoked to get the top level type.  In this 
> case it will be ArrayOfFoo and the type is located and my method called with 
> the correct list object un-marshalled from XML.
> In the second case, when posting to "/bar/update", ArrayOfBar is not found in 
> the AegisContext and null is returned by the getReadTypeStandalone method.
> The part that really confuses me is that if at runtime (after restarting the 
> server) I invoke the postBar method before invoking the postFoo method, the 
> ArrayOfBar type is located but not the ArrayOfFoo type.
> Some important things to note:
> 1.  This seems to only affect the ArrayOf classes.   Other custom classes 
> from different namespaces are fine.
> 2.  This only happens when ArrayOfBar is in a different namespace from 
> ArrayOfFoo.

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

[jira] Commented: (CXF-2471) The HttpServletResponse statuses is lost after is set in a service implementation (where the response is injected through @Context).

[Sergey Beryozkin (JIRA)]

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

Sergey Beryozkin commented on CXF-2471:
---

Hi, I was just about to close this JIRA :-)
Can you reply to my last comment please ?

cheers, Sergey

> The HttpServletResponse statuses is lost after is set in a service 
> implementation (where the response is injected through @Context).
> 
>
> Key: CXF-2471
> URL: https://issues.apache.org/jira/browse/CXF-2471
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 2.2.4, 2.2.5
>Reporter: Vincenzo Vitale
>Assignee: Sergey Beryozkin
> Fix For: 2.2.5, 2.3
>
>
> After injecting the the HttpServletResponse with the @Context annotation:
> @POST
> @Path("/login")
> public Feed login(@FormParam("username") String username,
> @FormParam("password") String password,
> @Context HttpServletResponse httpServletResponse) 
> and than setting a status code (for example 401 if the user is not 
> authorized), the status code get lost.
> See here for workarounds and more detials:
> http://www.nabble.com/Setting-the-status-code-in-the-injected-(via-the-jax-...@context)--HttpServletResponse-td25883621.html

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

[jira] Created: (CXF-2607) Improve the Java documentation of CXF JAXRS

[Sergey Beryozkin (JIRA)]

Improve the Java documentation of CXF JAXRS 


 Key: CXF-2607
 URL: https://issues.apache.org/jira/browse/CXF-2607
 Project: CXF
  Issue Type: Improvement
  Components: JAX-RS
Reporter: Sergey Beryozkin
Assignee: Sergey Beryozkin
 Fix For: 2.3


The Java documentation of CXF JAXRS is poor, this needs to be fixed

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

[jira] Created: (CXF-2608) Typedefinition is not reflected in the SOAP-request

[Knut Ivar Skogland (JIRA)]

Typedefinition is not reflected in the SOAP-request
---

 Key: CXF-2608
 URL: https://issues.apache.org/jira/browse/CXF-2608
 Project: CXF
  Issue Type: Bug
  Components: Soap Binding
Affects Versions: 2.2.5
 Environment: 1.6.0_15
Reporter: Knut Ivar Skogland


I have a problem when invoking a webservice with SOAP. I use CXF to generate 
code from a wsdl, but the service does not validate this;

   
  
  actionFTW!!
  
   

The problem is the "item" tag. The server does not want the "item" object here, 
but wants an object that extends item; "CustomerOrderItemValue" (yes, the wsdl 
states that this type extends item).

However.., this works:
   
  
  actionFTW!!
  
   

This was originally posted to the CXF users mailinglist, but I've made a small 
testproject containing the wsdl and sample code.

The project should build with maven. Mock the service with the wsdl 
(resources/wsdl/test/) and alter the url in the TypeTest.java main method.
One soaprequest is stored in the request.xml (incase you want to se the request 
without mocking and running the application).

Note that the wsdl and all the XSD's are not "my doing" ..., but is from 
another system that I have to integrate with... lucky me. :)


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

[jira] Commented: (CXF-2604) Issue with multiple REST methods having List arguments

[Alan Hazelton (JIRA)]

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

Alan Hazelton commented on CXF-2604:


Using an AegisElementProvider via Spring:

  
  

  


   
   
   




I'll attach the provider but it is pretty much an empty class that extends 
AegisElementProvider and calls the superclass methods in everything overridden.
I didn't add this part so I'm not sure why its there.

> Issue with multiple REST methods having List arguments
> -
>
> Key: CXF-2604
> URL: https://issues.apache.org/jira/browse/CXF-2604
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding, JAX-RS
>Affects Versions: 2.2.5
> Environment: JBoss 4.3 Using CXF 2.2.5
>Reporter: Alan Hazelton
>
> I have a REST based service method that takes a List parameter.  The 
> method is annotated with @POST and I can verify that the XML body of the POST 
> request from the server expects the top level element to be  and 
> a second method that takes a List parameter.
> It is important to note that the Foo and Bar classes are in different 
> packages and therefore the namespaces are different.
> The service would look something like this:
> My resource is defined like this:
> @Path("/")
> public class SomeResource {
>   @POST
>   @Path("/foo/update")
>   void postFoo(List list) {}
>  
>   @POST
>   @Path("/bar/update")
>   void postBar(List list) {}
> } 
> When I stop the server in the debugger after posting to "/foo/update" I can 
> see that in the org.apache.cxf.aegis.type.TypeUtil class the 
> getReadTypeStandalone() method is invoked to get the top level type.  In this 
> case it will be ArrayOfFoo and the type is located and my method called with 
> the correct list object un-marshalled from XML.
> In the second case, when posting to "/bar/update", ArrayOfBar is not found in 
> the AegisContext and null is returned by the getReadTypeStandalone method.
> The part that really confuses me is that if at runtime (after restarting the 
> server) I invoke the postBar method before invoking the postFoo method, the 
> ArrayOfBar type is located but not the ArrayOfFoo type.
> Some important things to note:
> 1.  This seems to only affect the ArrayOf classes.   Other custom classes 
> from different namespaces are fine.
> 2.  This only happens when ArrayOfBar is in a different namespace from 
> ArrayOfFoo.

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

[jira] Updated: (CXF-2604) Issue with multiple REST methods having List arguments

[Alan Hazelton (JIRA)]

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

Alan Hazelton updated CXF-2604:
---

Attachment: CustomAegisElementProvider.java

> Issue with multiple REST methods having List arguments
> -
>
> Key: CXF-2604
> URL: https://issues.apache.org/jira/browse/CXF-2604
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding, JAX-RS
>Affects Versions: 2.2.5
> Environment: JBoss 4.3 Using CXF 2.2.5
>Reporter: Alan Hazelton
> Attachments: CustomAegisElementProvider.java
>
>
> I have a REST based service method that takes a List parameter.  The 
> method is annotated with @POST and I can verify that the XML body of the POST 
> request from the server expects the top level element to be  and 
> a second method that takes a List parameter.
> It is important to note that the Foo and Bar classes are in different 
> packages and therefore the namespaces are different.
> The service would look something like this:
> My resource is defined like this:
> @Path("/")
> public class SomeResource {
>   @POST
>   @Path("/foo/update")
>   void postFoo(List list) {}
>  
>   @POST
>   @Path("/bar/update")
>   void postBar(List list) {}
> } 
> When I stop the server in the debugger after posting to "/foo/update" I can 
> see that in the org.apache.cxf.aegis.type.TypeUtil class the 
> getReadTypeStandalone() method is invoked to get the top level type.  In this 
> case it will be ArrayOfFoo and the type is located and my method called with 
> the correct list object un-marshalled from XML.
> In the second case, when posting to "/bar/update", ArrayOfBar is not found in 
> the AegisContext and null is returned by the getReadTypeStandalone method.
> The part that really confuses me is that if at runtime (after restarting the 
> server) I invoke the postBar method before invoking the postFoo method, the 
> ArrayOfBar type is located but not the ArrayOfFoo type.
> Some important things to note:
> 1.  This seems to only affect the ArrayOf classes.   Other custom classes 
> from different namespaces are fine.
> 2.  This only happens when ArrayOfBar is in a different namespace from 
> ArrayOfFoo.

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

[jira] Updated: (CXF-2596) Default logging in interceptor chain may pollute the log with stacktrace from application exceptions that are a part of the normal flow (should not be logged).

[Daniel Kulp (JIRA)]

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

Daniel Kulp updated CXF-2596:
-

Fix Version/s: 2.1.9

> Default logging in interceptor chain may pollute the log with stacktrace from 
> application exceptions that are a part of the normal flow (should not be 
> logged).
> ---
>
> Key: CXF-2596
> URL: https://issues.apache.org/jira/browse/CXF-2596
> Project: CXF
>  Issue Type: New Feature
>  Components: Configuration
> Environment: All
>Reporter: Tomas Majak
>Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
> Attachments: custom_logging_in_interceptorchain.patch, 
> custom_logging_in_interceptorchain_ver2.patch
>
>
> A user of CXF may need custom handling for runtime errors produced by the 
> application, not catchable within the application, e.g. exceptions from 
> interceptors to the actual service.
> E.g. applications may produce Exceptions that are a normal part of the flow 
> in the application, in that case, it pollutes the log file to have it logged 
> as stacktrace. 
> background: http://www.mail-archive.com/us...@cxf.apache.org/msg10976.html
> Configure via setting property to Bus or Service:
>  
>
>
> MyFaultLogger must implement org.apache.cxf.logging.FaultLogger
> Programatically:
> Bus bean = (Bus) applicationContext.getBean("cxf");
> bean.setProperty("org.apache.cxf.logging.FaultLogger", myLogger);
> By endpoint:
>  address="/myServiceWS">
>   
> 
>   
> 
>   
> 

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

[jira] Updated: (CXF-2594) No SOAP fault XML elements when a Fault is thrown in the output chain after SAAJOutInterceptor

[Daniel Kulp (JIRA)]

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

Daniel Kulp updated CXF-2594:
-

Fix Version/s: 2.1.9

> No SOAP fault XML elements when a Fault is thrown in the output chain after 
> SAAJOutInterceptor
> --
>
> Key: CXF-2594
> URL: https://issues.apache.org/jira/browse/CXF-2594
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.4, 2.2.6
> Environment: java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Microsoft Windows [Version 6.0.6002]
> Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
> Java version: 1.6.0_16
> Java home: C:\Program Files\Java\jdk1.6.0_16\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "amd64" Family: "windows"
> Eclipse 3.6M4:
> Version: 3.6.0
> Build id: I20091210-1301
>Reporter: Gary Gregory
>Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
> Attachments: patch.txt
>
>
> The attached unit test runs on top of the 2.2.x SVN branch updated from SVN 
> as of now.
> This ticket originated with this thread:
> http://old.nabble.com/Inflexible-fault-interceptor-chain--td26840876.html
> Which I replicate here with comments used for each step:
> Hi All:
> I need to apply an XSL transformation to messages coming out of CXF (our 
> users configure what the XSL looks like.) For a normal (successful) message, 
> I have an interceptor (during Phase.PRE_MARSHAL) that uses the DOM aspect of 
> a message. That works great. BTW, I get to the DOM like this:
> Node node = (Node) message.getContent(List.class).get(0);
> That seems brittle, is there a safer way to get to an aspect of the message I 
> can feed to javax.xml.transform?
> The real issue comes with fault messages because the fault chain uses an 
> XMLStreamWriter.
>  The fault chain looks like this:
> Chain org.apache.cxf.phase.phaseinterceptorch...@3015b303. Current flow:
>   setup [ServerPolicyOutFaultInterceptor]
>   prepare-send [MessageSenderInterceptor, Soap11FaultOutInterceptor]
>   pre-stream [LoggingOutInterceptor, XmlDeclOutInterceptor*, 
> StaxOutInterceptor]
>   pre-protocol [WebFaultOutInterceptor, SOAPHandlerFaultOutInterceptor]
>   write [SoapOutInterceptor]
>   pre-marshal [LogicalHandlerFaultOutInterceptor]
>   marshal [Soap11FaultOutInterceptorInternal]
>   pre-stream-ending [StaxOutEndingInterceptor, TransformOutFaultInterceptor*]
>   prepare-send-ending [MessageSenderEndingInterceptor]
> FYI, the interceptors marked with * are our own:
> * XmlDeclOutInterceptor forces an XML declaration to be written.
> * TransformOutFaultInterceptor is where I thought I could transform 
> the fault XML message.
> The 
> XMLStreamWriter
>  looks like this:
> [StreamWriter: class com.ctc.wstx.sw.SimpleNsStreamWriter, underlying 
> outputter: 
> com.ctc.wstx.sw.isolatin1xmlwri...@1125cf44
> The com.ctc.wstx.sw.ISOLatin1XmlWriter wraps a 
> org.apache.cxf.io.CachedOutputStream, which in turns wraps:
> * currentStream - LoadingByteArrayOutputStream
> * flowThroughStream - AbstractHTTPDestination$WrappedOutputStream
> All of this to say that when the chain's interceptors are working with the 
> message's 
> XMLStreamWriter,
>  the bytes are cached and written to the wire. It is not possible to catch 
> the fault XML message and change it.
> The only thing I've come up with but not implemented yet would be to insert 
> an interceptor before the XML declaration is written and put the 
> XMLStreamWriter
>  into a temp spot in the message content map, then put a new 
> XMLStreamWriter
>  on a byte array in its place. A pre-stream-ending interceptor can take those 
> bytes, apply XSL to them and then write them to the original 
> XMLStreamWriter,
>  before putting the original 
> XMLStreamWriter
>  back in it original slot in the message content map.
> That seems like big old hack.
> Any ideas on a cleaner solution?
> Thank you,
> Gary Gregory
> Seagull Software
> ggreg...@seagullsoftware.com
> www.seagullsoftware.com

-- 
This message is automatically generated by JIRA.
-
You 

[jira] Resolved: (CXF-2606) ThreadGroup in the default workqueue gets prematurely destroyed

[Hadrian Zbarcea (JIRA)]

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

Hadrian Zbarcea resolved CXF-2606.
--

   Resolution: Fixed
Fix Version/s: 2.3
   2.2.6

Fixed by dkulp in r896888,896994. Thanks.

> ThreadGroup in the default workqueue gets prematurely destroyed
> ---
>
> Key: CXF-2606
> URL: https://issues.apache.org/jira/browse/CXF-2606
> Project: CXF
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2.2
> Environment: IBM JDK6
>Reporter: Hadrian Zbarcea
> Fix For: 2.2.6, 2.3
>
>
> An IllegalThreadStateException gets thrown as shown in the stack below when a 
> new Thread is added to the default workqueue. This does not happen with the 
> Sun JDK and it was not encountered with the IBM JDK5 either.
> The Exception gets thrown because the ThreadGroup is destroyed by the time we 
> add the new thread because the core pool size (low watermark) is 0, the 
> number of threads is 0 and is a daemon thread.
> {code}
> Throwable occurred: java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.checkNewThread(ThreadGroup.java:147)
> at java.lang.Thread.initialize(Thread.java:332)
> at java.lang.Thread.(Thread.java:267)
> at java.lang.Thread.(Thread.java:225)
> at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory.newThread(AutomaticWorkQueueImpl.java:162)
> at 
> java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672)
> at 
> java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697)
> at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652)
> at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl.execute(AutomaticWorkQueueImpl.java:249)
> at 
> org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:83)
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
> {code}
> A workaround is to set the lowWaterMark to something >=1 so that the 
> ThreadGroup never gets destroyed.

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

[jira] Created: (CXF-2609) Schema validation failure when null system ID passed to LSResourceResolver.resolveResource()

[Eoghan Glynn (JIRA)]

Schema validation failure when null system ID passed to 
LSResourceResolver.resolveResource()


 Key: CXF-2609
 URL: https://issues.apache.org/jira/browse/CXF-2609
 Project: CXF
  Issue Type: Bug
Affects Versions: 2.2.5
 Environment: $ java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
$ uname -a
Linux geodesic 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC 2009 
i686 GNU/Linux
Reporter: Eoghan Glynn
Assignee: Eoghan Glynn
 Fix For: 2.2.6


The re-working of the EndpointReferenceUtils schema caching logic in 2.2.5 can 
cause schema validation failures. This is triggered by a null system ID being 
passed to LSResourceResolver.resolveResource(), so that a direct key lookup in 
the schemas map fails. In order to locate the schema, a scan though the map 
searching for an endsWith match is required.

The problem manifests on the first schema resolution as:

{code}
SAXException for newSchema() on
org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 
'ns1:IllustrationSet' to a(n) 'type definition' component.
{code}

and thereafter as:

{code}
org.apache.cxf.interceptor.Fault: Unmarshalling Error: cvc-elt.1: Cannot find 
the declaration of element 'generateIllustration'.
{code}

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

[jira] Resolved: (CXF-2609) Schema validation failure when null system ID passed to LSResourceResolver.resolveResource()

[Eoghan Glynn (JIRA)]

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

Eoghan Glynn resolved CXF-2609.
---

Resolution: Fixed

Fix [committed|http://svn.apache.org/viewvc?rev=897217&view=rev] on trunk. 

> Schema validation failure when null system ID passed to 
> LSResourceResolver.resolveResource()
> 
>
> Key: CXF-2609
> URL: https://issues.apache.org/jira/browse/CXF-2609
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.5
> Environment: $ java -version
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
> $ uname -a
> Linux geodesic 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC 2009 
> i686 GNU/Linux
>Reporter: Eoghan Glynn
>Assignee: Eoghan Glynn
> Fix For: 2.2.6
>
>
> The re-working of the EndpointReferenceUtils schema caching logic in 2.2.5 
> can cause schema validation failures. This is triggered by a null system ID 
> being passed to LSResourceResolver.resolveResource(), so that a direct key 
> lookup in the schemas map fails. In order to locate the schema, a scan though 
> the map searching for an endsWith match is required.
> The problem manifests on the first schema resolution as:
> {code}
> SAXException for newSchema() on
> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 
> 'ns1:IllustrationSet' to a(n) 'type definition' component.
> {code}
> and thereafter as:
> {code}
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: cvc-elt.1: Cannot find 
> the declaration of element 'generateIllustration'.
> {code}

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

[jira] Resolved: (CXF-2591) MAPCodec : memory leak with an async client with network issues (connection timeout, read timeout etc)

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2591.
--

   Resolution: Fixed
Fix Version/s: 2.2.6
   2.1.9

> MAPCodec : memory leak with an async client with network issues (connection 
> timeout, read timeout etc)
> --
>
> Key: CXF-2591
> URL: https://issues.apache.org/jira/browse/CXF-2591
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 2.2.5
> Environment: CXF 2.2.2 & 2.2.5 / JDK 1.6 / Linux (Ubuntu 9.10)
>Reporter: Thomas Sauzedde
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 2.1.9, 2.2.6
>
>
> Context :
>  a JAX-WS asynchronous client, with WS-Adressing enabled
>  when there are network issues like connection timeout, read timeout etc,
> Observed facts :
> MAPCodec::uncorrelatedExchanges is not cleaned when the client is trying to 
> request the server and there is a network issue.
> In such a case, the InterceptorChain is by-passed, so MAPCodec::handleFault() 
> is NOT called and so the MAPCodec::uncorrelatedExchanges grows and grows 
> until OOM :-(
> Don't have any patch (yet) to provide because this is something more 
> architectural than technical :-(
> When a network issue occurs, this throws an ExecutionException in 
> JaxwsClientCallback::handleResponse(), the "normal" InterceptorChain is then 
> by-passed there IMHO ...

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

[jira] Resolved: (CXF-2545) WS Addressing asynchronous transport and NullPointerException with Apache tomcat (threading problem ?)

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2545.
--

   Resolution: Fixed
Fix Version/s: 2.2.6
   2.1.9

> WS Addressing asynchronous transport and NullPointerException with Apache 
> tomcat (threading problem ?) 
> ---
>
> Key: CXF-2545
> URL: https://issues.apache.org/jira/browse/CXF-2545
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
> Environment: System:
> 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
> Java:
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> Apache CXF 2.2.3 (not in version list) 
> ServiceMix 3.3.1 with pachted CXF-BC component
> Apache Tomcat 6.0.20 and 6.0.14
>Reporter: Christian Connert
>Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
>
> Hi,
> I've the problem, that for one of my services the following
> java.lang.NullPointerException occurs:
> WARNUNG: Interceptor has thrown exception, unwinding now
> java.lang.NullPointerException
>   at 
> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:735)
>   at 
> org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:781)
>   at 
> org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:708)
>   at org.apache.coyote.Request.doRead(Request.java:428)
>   at 
> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:304)
>   at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:405)
>   at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:327)
>   at 
> org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:162)
>   at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:365)
>   at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:110)
>   at com.ctc.wstx.io.MergedReader.read(MergedReader.java:101)
>   at com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:84)
>   at 
> com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:57)
>   at com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:992)
>   at 
> com.ctc.wstx.sr.BasicStreamReader.readTextSecondary(BasicStreamReader.java:4626)
>   at 
> com.ctc.wstx.sr.BasicStreamReader.readCoalescedText(BasicStreamReader.java:4124)
>   at 
> com.ctc.wstx.sr.BasicStreamReader.finishToken(BasicStreamReader.java:3699)
>   at 
> com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3647)
>   at com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:809)
>   at 
> org.apache.cxf.staxutils.DepthXMLStreamReader.getText(DepthXMLStreamReader.java:160)
>   at 
> org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:818)
>   at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
>   at 
> org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
>   at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
>   at 
> org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
>   at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
>   at 
> org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
>   at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
>   at 
> org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
>   at 
> org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.getBodyElement(JbiInWsdl1Interceptor.java:351)
>   at 
> org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.handleMessage(JbiInWsdl1Interceptor.java:96)
>   at 
> org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.handleMessage(JbiInWsdl1Interceptor.java:59)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:210)
>   at 
> org.apache.cxf.ws.addressing.ContextUtils$1.run(ContextUtils.java:414)
>   at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:243)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:619)
> It seems that Apache Tomcat recycles the InputStream of the request and thus 
> closes the underlying InputStream.
> I tested it with Tomcat 6.0.20 and 6.0.14 and have the sam

[jira] Updated: (CXF-2606) ThreadGroup in the default workqueue gets prematurely destroyed

[Daniel Kulp (JIRA)]

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

Daniel Kulp updated CXF-2606:
-

Fix Version/s: (was: 2.3)
   2.1.9
 Assignee: Daniel Kulp

> ThreadGroup in the default workqueue gets prematurely destroyed
> ---
>
> Key: CXF-2606
> URL: https://issues.apache.org/jira/browse/CXF-2606
> Project: CXF
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2.2
> Environment: IBM JDK6
>Reporter: Hadrian Zbarcea
>Assignee: Daniel Kulp
> Fix For: 2.1.9, 2.2.6
>
>
> An IllegalThreadStateException gets thrown as shown in the stack below when a 
> new Thread is added to the default workqueue. This does not happen with the 
> Sun JDK and it was not encountered with the IBM JDK5 either.
> The Exception gets thrown because the ThreadGroup is destroyed by the time we 
> add the new thread because the core pool size (low watermark) is 0, the 
> number of threads is 0 and is a daemon thread.
> {code}
> Throwable occurred: java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.checkNewThread(ThreadGroup.java:147)
> at java.lang.Thread.initialize(Thread.java:332)
> at java.lang.Thread.(Thread.java:267)
> at java.lang.Thread.(Thread.java:225)
> at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory.newThread(AutomaticWorkQueueImpl.java:162)
> at 
> java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672)
> at 
> java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697)
> at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652)
> at 
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl.execute(AutomaticWorkQueueImpl.java:249)
> at 
> org.apache.cxf.interceptor.OneWayProcessorInterceptor.handleMessage(OneWayProcessorInterceptor.java:83)
> at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
> {code}
> A workaround is to set the lowWaterMark to something >=1 so that the 
> ThreadGroup never gets destroyed.

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

[jira] Commented: (CXF-2471) The HttpServletResponse statuses is lost after is set in a service implementation (where the response is injected through @Context).

[Vincenzo Vitale (JIRA)]

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

Vincenzo Vitale commented on CXF-2471:
--

Just tried the last snapshot and indeed is fixed! Do you know the date for 
releasing 2.2.6?


Thanks a lot,
V.

> The HttpServletResponse statuses is lost after is set in a service 
> implementation (where the response is injected through @Context).
> 
>
> Key: CXF-2471
> URL: https://issues.apache.org/jira/browse/CXF-2471
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 2.2.4, 2.2.5
>Reporter: Vincenzo Vitale
>Assignee: Sergey Beryozkin
> Fix For: 2.2.5, 2.3
>
>
> After injecting the the HttpServletResponse with the @Context annotation:
> @POST
> @Path("/login")
> public Feed login(@FormParam("username") String username,
> @FormParam("password") String password,
> @Context HttpServletResponse httpServletResponse) 
> and than setting a status code (for example 401 if the user is not 
> authorized), the status code get lost.
> See here for workarounds and more detials:
> http://www.nabble.com/Setting-the-status-code-in-the-injected-(via-the-jax-...@context)--HttpServletResponse-td25883621.html

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

[jira] Commented: (CXF-2471) The HttpServletResponse statuses is lost after is set in a service implementation (where the response is injected through @Context).

[Sergey Beryozkin (JIRA)]

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

Sergey Beryozkin commented on CXF-2471:
---

great, thanks for the confirmation...
around 18 Jan

> The HttpServletResponse statuses is lost after is set in a service 
> implementation (where the response is injected through @Context).
> 
>
> Key: CXF-2471
> URL: https://issues.apache.org/jira/browse/CXF-2471
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 2.2.4, 2.2.5
>Reporter: Vincenzo Vitale
>Assignee: Sergey Beryozkin
> Fix For: 2.2.5, 2.3
>
>
> After injecting the the HttpServletResponse with the @Context annotation:
> @POST
> @Path("/login")
> public Feed login(@FormParam("username") String username,
> @FormParam("password") String password,
> @Context HttpServletResponse httpServletResponse) 
> and than setting a status code (for example 401 if the user is not 
> authorized), the status code get lost.
> See here for workarounds and more detials:
> http://www.nabble.com/Setting-the-status-code-in-the-injected-(via-the-jax-...@context)--HttpServletResponse-td25883621.html

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

[jira] Resolved: (CXF-2471) The HttpServletResponse statuses is lost after is set in a service implementation (where the response is injected through @Context).

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2471.
--

   Resolution: Fixed
Fix Version/s: (was: 2.2.5)
   (was: 2.3)
   2.2.6

> The HttpServletResponse statuses is lost after is set in a service 
> implementation (where the response is injected through @Context).
> 
>
> Key: CXF-2471
> URL: https://issues.apache.org/jira/browse/CXF-2471
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-RS
>Affects Versions: 2.2.4, 2.2.5
>Reporter: Vincenzo Vitale
>Assignee: Sergey Beryozkin
> Fix For: 2.2.6
>
>
> After injecting the the HttpServletResponse with the @Context annotation:
> @POST
> @Path("/login")
> public Feed login(@FormParam("username") String username,
> @FormParam("password") String password,
> @Context HttpServletResponse httpServletResponse) 
> and than setting a status code (for example 401 if the user is not 
> authorized), the status code get lost.
> See here for workarounds and more detials:
> http://www.nabble.com/Setting-the-status-code-in-the-injected-(via-the-jax-...@context)--HttpServletResponse-td25883621.html

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

[jira] Updated: (CXF-2609) Schema validation failure when null system ID passed to LSResourceResolver.resolveResource()

[Daniel Kulp (JIRA)]

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

Daniel Kulp updated CXF-2609:
-

Fix Version/s: 2.1.9

> Schema validation failure when null system ID passed to 
> LSResourceResolver.resolveResource()
> 
>
> Key: CXF-2609
> URL: https://issues.apache.org/jira/browse/CXF-2609
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.5
> Environment: $ java -version
> java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
> $ uname -a
> Linux geodesic 2.6.28-16-generic #55-Ubuntu SMP Tue Oct 20 19:48:24 UTC 2009 
> i686 GNU/Linux
>Reporter: Eoghan Glynn
>Assignee: Eoghan Glynn
> Fix For: 2.1.9, 2.2.6
>
>
> The re-working of the EndpointReferenceUtils schema caching logic in 2.2.5 
> can cause schema validation failures. This is triggered by a null system ID 
> being passed to LSResourceResolver.resolveResource(), so that a direct key 
> lookup in the schemas map fails. In order to locate the schema, a scan though 
> the map searching for an endsWith match is required.
> The problem manifests on the first schema resolution as:
> {code}
> SAXException for newSchema() on
> org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 
> 'ns1:IllustrationSet' to a(n) 'type definition' component.
> {code}
> and thereafter as:
> {code}
> org.apache.cxf.interceptor.Fault: Unmarshalling Error: cvc-elt.1: Cannot find 
> the declaration of element 'generateIllustration'.
> {code}

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

[jira] Resolved: (CXF-2581) Improper toString of Arrays during logging

[Bharath Ganesh (JIRA)]

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

Bharath Ganesh resolved CXF-2581.
-

Resolution: Fixed

Identified and fixed all such occurrences on the trunk. 

> Improper toString of Arrays during logging
> --
>
> Key: CXF-2581
> URL: https://issues.apache.org/jira/browse/CXF-2581
> Project: CXF
>  Issue Type: Bug
>Reporter: Bharath Ganesh
>Assignee: Bharath Ganesh
>Priority: Minor
>
> During logging, we invoke toString on an array, which will generate junk 
> result. This is happening at a number of places in the codebase.
> A possible fix could be invoking Arrays.toString to convert the array into a 
> readable String that gives the contents of the array.
> Some places identified are:
> org.apache.cxf.endpoint.ClientImpl Line 445
> org.apache.cxf.tools.corba.idlepreprocessor.DefaultIncludeResolver line 67
> org.apache.cxf.transport.http.HTTPConduit Line 410,411, 1381,1382

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

[jira] Commented: (CXF-2608) Typedefinition is not reflected in the SOAP-request

[Daniel Kulp (JIRA)]

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

Daniel Kulp commented on CXF-2608:
--

 
I'm failing to see anything wrong.  

There is not a "CustomerOrderItemValue" type defined anywhere.The only 
thing similar defined is "JrCustomerOrderItemValue".   Since the list of items 
is defined as:

and there are no subclasses or anything of JrCustomerOrderItemValue, there 
isn't a need for any xsi:type on the "item" element.   The type is properly and 
fully defined from the schema.   



> Typedefinition is not reflected in the SOAP-request
> ---
>
> Key: CXF-2608
> URL: https://issues.apache.org/jira/browse/CXF-2608
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 2.2.5
> Environment: 1.6.0_15
>Reporter: Knut Ivar Skogland
> Attachments: typeDefClient.zip
>
>
> I have a problem when invoking a webservice with SOAP. I use CXF to generate 
> code from a wsdl, but the service does not validate this;
>
>   
>   actionFTW!!
>   
>
> The problem is the "item" tag. The server does not want the "item" object 
> here, but wants an object that extends item; "CustomerOrderItemValue" (yes, 
> the wsdl states that this type extends item).
> However.., this works:
>
>   
>   actionFTW!!
>   
>
> This was originally posted to the CXF users mailinglist, but I've made a 
> small testproject containing the wsdl and sample code.
> The project should build with maven. Mock the service with the wsdl 
> (resources/wsdl/test/) and alter the url in the TypeTest.java main method.
> One soaprequest is stored in the request.xml (incase you want to se the 
> request without mocking and running the application).
> Note that the wsdl and all the XSD's are not "my doing" ..., but is from 
> another system that I have to integrate with... lucky me. :)

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

[jira] Commented: (CXF-2605) Object argument is passed as null

[Daniel Kulp (JIRA)]

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

Daniel Kulp commented on CXF-2605:
--


Couple thoughts:

1)  Definitely try with the newer jaxb-impl.That may throw a new error 
message/exception.   

2)  Make sure you have an asm jar on the classpath.  

3) It looks like you are doing java first on the server.  Is that wsdl from the 
2.1.1  service or from the 2.2.4 service? I'd like to see if there is a 
difference in the generated wsdls.

4) Do you have a package-info.java or similar thing in the package of the 
service that would have an jaxb annotations?




> Object argument is passed as null
> -
>
> Key: CXF-2605
> URL: https://issues.apache.org/jira/browse/CXF-2605
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.4
>Reporter: Ravi Sukheja
> Attachments: StatusService.xml
>
>
> Hi,
> We are using CXF-2.1.1 for our webservices and rest services, recently I 
> upgraded it to 2.2.4 as there was bug 2ith 2.1.1 when you go to /services to 
> view the list of all webservices and rest services. Upgrading to 2.2.4 seems 
> to fix that problem, but one of our webservice has stopped working, client is 
> passing the right object argument, but the service is getting null. I don't 
> know what the problem is. Any help would be appreciated.

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

[jira] Updated: (CXF-2581) Improper toString of Arrays during logging

[Daniel Kulp (JIRA)]

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

Daniel Kulp updated CXF-2581:
-

Fix Version/s: 2.2.6
   2.1.9

> Improper toString of Arrays during logging
> --
>
> Key: CXF-2581
> URL: https://issues.apache.org/jira/browse/CXF-2581
> Project: CXF
>  Issue Type: Bug
>Reporter: Bharath Ganesh
>Assignee: Bharath Ganesh
>Priority: Minor
> Fix For: 2.1.9, 2.2.6
>
>
> During logging, we invoke toString on an array, which will generate junk 
> result. This is happening at a number of places in the codebase.
> A possible fix could be invoking Arrays.toString to convert the array into a 
> readable String that gives the contents of the array.
> Some places identified are:
> org.apache.cxf.endpoint.ClientImpl Line 445
> org.apache.cxf.tools.corba.idlepreprocessor.DefaultIncludeResolver line 67
> org.apache.cxf.transport.http.HTTPConduit Line 410,411, 1381,1382

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

[jira] Commented: (CXF-2604) Issue with multiple REST methods having List arguments

[Daniel Kulp (JIRA)]

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

Daniel Kulp commented on CXF-2604:
--



Any chance you could test this with the 2.3 snapshots?This MAY be fixed 
there.   I think aegis on 2.2.x just know the root "class", in this case "List" 
and just kind of guesses on the internal stuff but I think Benson addes some 
support for the "generics" things on trunk to pick up the internal type.   Not 
100% sure though.

> Issue with multiple REST methods having List arguments
> -
>
> Key: CXF-2604
> URL: https://issues.apache.org/jira/browse/CXF-2604
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding, JAX-RS
>Affects Versions: 2.2.5
> Environment: JBoss 4.3 Using CXF 2.2.5
>Reporter: Alan Hazelton
> Attachments: CustomAegisElementProvider.java
>
>
> I have a REST based service method that takes a List parameter.  The 
> method is annotated with @POST and I can verify that the XML body of the POST 
> request from the server expects the top level element to be  and 
> a second method that takes a List parameter.
> It is important to note that the Foo and Bar classes are in different 
> packages and therefore the namespaces are different.
> The service would look something like this:
> My resource is defined like this:
> @Path("/")
> public class SomeResource {
>   @POST
>   @Path("/foo/update")
>   void postFoo(List list) {}
>  
>   @POST
>   @Path("/bar/update")
>   void postBar(List list) {}
> } 
> When I stop the server in the debugger after posting to "/foo/update" I can 
> see that in the org.apache.cxf.aegis.type.TypeUtil class the 
> getReadTypeStandalone() method is invoked to get the top level type.  In this 
> case it will be ArrayOfFoo and the type is located and my method called with 
> the correct list object un-marshalled from XML.
> In the second case, when posting to "/bar/update", ArrayOfBar is not found in 
> the AegisContext and null is returned by the getReadTypeStandalone method.
> The part that really confuses me is that if at runtime (after restarting the 
> server) I invoke the postBar method before invoking the postFoo method, the 
> ArrayOfBar type is located but not the ArrayOfFoo type.
> Some important things to note:
> 1.  This seems to only affect the ArrayOf classes.   Other custom classes 
> from different namespaces are fine.
> 2.  This only happens when ArrayOfBar is in a different namespace from 
> ArrayOfFoo.

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

[jira] Created: (CXF-2610) Trim white spaces in logger class name

[Cyrille Le Clerc (JIRA)]

Trim white spaces in logger class name
--

 Key: CXF-2610
 URL: https://issues.apache.org/jira/browse/CXF-2610
 Project: CXF
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.2.5
Reporter: Cyrille Le Clerc
Assignee: Cyrille Le Clerc


Unexpected leading and trailing white spaces in logger class name (1) can be 
very difficult to troubleshoot, particularly trailing ones.

Trim the leading and trailing with spaces of the logger class name (e.g. 
{{org.apache.cxf.common.logging.Log4jLogger}}). 

(1) defined with the system property {{org.apache.cxf.Logger}} or in the first 
line of the classpath resource {{META-INF/cxf/org.apache.cxf.Logger}}

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

[jira] Resolved: (CXF-2590) service implementator without @WebService still accepted

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2590.
--

   Resolution: Won't Fix
Fix Version/s: Invalid


Definitely not something we'll "fix" unless the JAX-WS tck starts complaining 
about it.

CXF DOES require the @WebService annotation on the impl "someplace".   For 
example, if you just do:


{code:java}
   public interface FooInterface {
int blah(int a);
}

public class FooTest implements FooInterface {
public int blah(int a) {
return a;
}
}


Endpoint.publish("http://localhost:9020/FooPort";, new FooTest());
{code}

You will get an exception of:
{code}
javax.xml.ws.WebServiceException: Cannot create Endpoint for implementor that 
does not have a WebService annotation and does not implement the Provider 
interface
{code}

What is different is that CXF allows the @WebService annotation to only be on 
the interface (stick it on FooInterface above) as long as the impl implements 
the interface.  (if it doesn't implement the interface, it would need the 
@WebService to define the endpointInterface attribute)

Anyway, we consider this a "feature" of CXF as it can simplify the impl 
creation. 





> service implementator without @WebService still accepted
> 
>
> Key: CXF-2590
> URL: https://issues.apache.org/jira/browse/CXF-2590
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.2.5
>Reporter: Kent Tong
> Fix For: Invalid
>
>
> CXF allows a service implementation class without the @WebService annotation. 
> This is against the JAX-WS spec.

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

[jira] Resolved: (CXF-2610) Trim white spaces in logger class name

[Cyrille Le Clerc (JIRA)]

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

Cyrille Le Clerc resolved CXF-2610.
---

   Resolution: Fixed
Fix Version/s: 2.3
   2.2.6

> Trim white spaces in logger class name
> --
>
> Key: CXF-2610
> URL: https://issues.apache.org/jira/browse/CXF-2610
> Project: CXF
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2.5
>Reporter: Cyrille Le Clerc
>Assignee: Cyrille Le Clerc
> Fix For: 2.2.6, 2.3
>
>
> Unexpected leading and trailing white spaces in logger class name (1) can be 
> very difficult to troubleshoot, particularly trailing ones.
> Trim the leading and trailing with spaces of the logger class name (e.g. 
> {{org.apache.cxf.common.logging.Log4jLogger}}). 
> (1) defined with the system property {{org.apache.cxf.Logger}} or in the 
> first line of the classpath resource {{META-INF/cxf/org.apache.cxf.Logger}}

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

[jira] Updated: (CXF-2527) SymmetricBindingHandler wrongly uses relative references to wsc:Identifiers

[Daniel Kulp (JIRA)]

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

Daniel Kulp updated CXF-2527:
-

Description: The SymmetricBindingHandler wrongly uses relative references 
to wsc:Identifiers, whereas the WS-SecureConversation spec states that they 
must be absolute URI's.   (was: 
The SymmetricBindingHandler wrongly uses relative references to 
wsc:Identifiers, whereas the WS-SecureConversation spec states that they must 
be absolute URI's. )
 CXF Fields: [Blocked on External]

> SymmetricBindingHandler wrongly uses relative references to wsc:Identifiers
> ---
>
> Key: CXF-2527
> URL: https://issues.apache.org/jira/browse/CXF-2527
> Project: CXF
>  Issue Type: Bug
>  Components: WS-* Components
>Affects Versions: 2.1.7, 2.2.4
>Reporter: Colm O hEigeartaigh
> Fix For: 2.1.9, 2.2.6
>
> Attachments: cxf-2527.patch
>
>
> The SymmetricBindingHandler wrongly uses relative references to 
> wsc:Identifiers, whereas the WS-SecureConversation spec states that they must 
> be absolute URI's. 

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

[jira] Closed: (CXF-2608) Typedefinition is not reflected in the SOAP-request

[Knut Ivar Skogland (JIRA)]

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

Knut Ivar Skogland closed CXF-2608.
---

Resolution: Not A Problem

> Typedefinition is not reflected in the SOAP-request
> ---
>
> Key: CXF-2608
> URL: https://issues.apache.org/jira/browse/CXF-2608
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 2.2.5
> Environment: 1.6.0_15
>Reporter: Knut Ivar Skogland
> Attachments: typeDefClient.zip
>
>
> I have a problem when invoking a webservice with SOAP. I use CXF to generate 
> code from a wsdl, but the service does not validate this;
>
>   
>   actionFTW!!
>   
>
> The problem is the "item" tag. The server does not want the "item" object 
> here, but wants an object that extends item; "CustomerOrderItemValue" (yes, 
> the wsdl states that this type extends item).
> However.., this works:
>
>   
>   actionFTW!!
>   
>
> This was originally posted to the CXF users mailinglist, but I've made a 
> small testproject containing the wsdl and sample code.
> The project should build with maven. Mock the service with the wsdl 
> (resources/wsdl/test/) and alter the url in the TypeTest.java main method.
> One soaprequest is stored in the request.xml (incase you want to se the 
> request without mocking and running the application).
> Note that the wsdl and all the XSD's are not "my doing" ..., but is from 
> another system that I have to integrate with... lucky me. :)

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

[jira] Commented: (CXF-2608) Typedefinition is not reflected in the SOAP-request

[Knut Ivar Skogland (JIRA)]

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

Knut Ivar Skogland commented on CXF-2608:
-

I just realized the small xml parts in the description was just an example I 
customized and not an exact copy from the generated request. 

. and because you think this isn't an error, I digged deeper and deeper 
and got confused..., but then I realized you were RIGHT!! :) 
Because of the requestValue is defined as JrCustomerOrderValue and etc etc etc, 
the "item" is correctly defined! 

 my problem is just that the server does not recognise it unless I specify 
the type... which then should not be necessary.

Thank you for your time. Sorry to bother you on a friday :)

> Typedefinition is not reflected in the SOAP-request
> ---
>
> Key: CXF-2608
> URL: https://issues.apache.org/jira/browse/CXF-2608
> Project: CXF
>  Issue Type: Bug
>  Components: Soap Binding
>Affects Versions: 2.2.5
> Environment: 1.6.0_15
>Reporter: Knut Ivar Skogland
> Attachments: typeDefClient.zip
>
>
> I have a problem when invoking a webservice with SOAP. I use CXF to generate 
> code from a wsdl, but the service does not validate this;
>
>   
>   actionFTW!!
>   
>
> The problem is the "item" tag. The server does not want the "item" object 
> here, but wants an object that extends item; "CustomerOrderItemValue" (yes, 
> the wsdl states that this type extends item).
> However.., this works:
>
>   
>   actionFTW!!
>   
>
> This was originally posted to the CXF users mailinglist, but I've made a 
> small testproject containing the wsdl and sample code.
> The project should build with maven. Mock the service with the wsdl 
> (resources/wsdl/test/) and alter the url in the TypeTest.java main method.
> One soaprequest is stored in the request.xml (incase you want to se the 
> request without mocking and running the application).
> Note that the wsdl and all the XSD's are not "my doing" ..., but is from 
> another system that I have to integrate with... lucky me. :)

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

[jira] Resolved: (CXF-2598) Can/t set minOccurs="1" with annotations

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2598.
--

   Resolution: Fixed
Fix Version/s: 2.2.6
 Assignee: Daniel Kulp

> Can/t set minOccurs="1" with annotations
> 
>
> Key: CXF-2598
> URL: https://issues.apache.org/jira/browse/CXF-2598
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding
>Affects Versions: 2.2.5
>Reporter: Alexey Moskvin
>Assignee: Daniel Kulp
>Priority: Minor
> Fix For: 2.2.6
>
>
> Hi, I use CXF & aegis binding for webservices.
> For such java method: 
> public Calendar getSysdate()
> I tried this annotations:
> @org.apache.cxf.aegis.type.java5.XmlElement(nillable=false, minOccurs="1")
> and
> @javax.xml.bind.annotation.XmlElement(required=true)
> but there is still 
> 
> 
> 
> 
> 
> is generated WSDL file.
> When we build .NET code based on this WSDL this function becomes void 
> (because of minOccurs="0").
> Is it possible to set minOccurs="1". Thanks.

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

[jira] Commented: (CXF-2590) service implementator without @WebService still accepted

[Kent Tong (JIRA)]

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

Kent Tong commented on CXF-2590:


Are you saying that even though this feature is incompatible with the spec, it 
is still to be kept? If so, fine (even though a warning would be better).

For reference, according to the JSR 181,  section 3.1 (Service Implementation 
Bean):

The implementation bean MUST include a @WebService class-level annotation, 
indicating that it implements a Web Service. 

OTOH, section 3.2 details the requirements for Service Endpoint Interface. As 
annotations applied to Java interfaces are not inherited by implementation 
classes, I don't see how @WebService can be "transferred" to the service 
implementation bean.


> service implementator without @WebService still accepted
> 
>
> Key: CXF-2590
> URL: https://issues.apache.org/jira/browse/CXF-2590
> Project: CXF
>  Issue Type: Bug
>  Components: JAX-WS Runtime
>Affects Versions: 2.2.5
>Reporter: Kent Tong
> Fix For: Invalid
>
>
> CXF allows a service implementation class without the @WebService annotation. 
> This is against the JAX-WS spec.

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