[jira] Commented: (DOSGI-13) The CXF DOSGi implementation needs to be updated to support the latest OSGi Remote Services Admin spec.

[David Bosschaert (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797565#action_12797565
 ] 

David Bosschaert commented on DOSGI-13:
---

Patch discovery_startup__rsa_intents_and_property_overwrites.patch applied with 
many thanks.

> The CXF DOSGi implementation needs to be updated to support the latest OSGi 
> Remote Services Admin spec.
> ---
>
> Key: DOSGI-13
> URL: https://issues.apache.org/jira/browse/DOSGI-13
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: cxf-dosgi-rsa-merge.patch, 
> discovery_startup__rsa_intents_and_property_overwrites.patch, disoveryPatch, 
> rsa_testCasesAndFixes.patch
>
>
> The API for Distributed OSGi has changed quite significantly between the text 
> in the RFC and the ultimate spec text. The DOSGi implementation in CXF needs 
> to be updated to support the new APIs as described in the (proposed) spec.

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

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

[Alan Hazelton (JIRA)]

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: (DOSGI-13) The CXF DOSGi implementation needs to be updated to support the latest OSGi Remote Services Admin spec.

[Marc Schaaf (JIRA)]

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

Marc Schaaf updated DOSGI-13:
-

Attachment: new_rsa_interfaces.patch

This patch integrates the current  org.osgi.service.remoteserviceadmin 
interfaces (from the 07.01.10)

> The CXF DOSGi implementation needs to be updated to support the latest OSGi 
> Remote Services Admin spec.
> ---
>
> Key: DOSGI-13
> URL: https://issues.apache.org/jira/browse/DOSGI-13
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: cxf-dosgi-rsa-merge.patch, 
> discovery_startup__rsa_intents_and_property_overwrites.patch, disoveryPatch, 
> new_rsa_interfaces.patch, rsa_testCasesAndFixes.patch
>
>
> The API for Distributed OSGi has changed quite significantly between the text 
> in the RFC and the ultimate spec text. The DOSGi implementation in CXF needs 
> to be updated to support the new APIs as described in the (proposed) spec.

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

[jira] Resolved: (DOSGI-54) RemoteServiceAdmin interfaces/classes out of sync with official version

[JIRA]

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

Holger Hoffstätte resolved DOSGI-54.


Resolution: Duplicate

Apparently this is being fixed as part of DOSGI-13.


> RemoteServiceAdmin interfaces/classes out of sync with official version
> ---
>
> Key: DOSGI-54
> URL: https://issues.apache.org/jira/browse/DOSGI-54
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>  Components: Discovery
>Affects Versions: 1.1
> Environment: tested with Java6 in eclipse
>Reporter: Holger Hoffstätte
>Priority: Critical
> Fix For: 1.2
>
> Attachments: EndpointDescriptions.patch
>
>
> The interfaces/classes in the cxf-dosgi-remote-service-admin-interfaces 
> module are out of sync with the official spec code from the OSGi alliance svn 
> repo. With those classes on the classpath two tests fail (both for the same 
> reason) in LocalDiscoveryUtilsTest.testAllEndpoints1/testAllEndpoints2:
> --snip--
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryUtilsTest
> testAllEndpoints1(org.apache.cxf.dosgi.discovery.local.LocalDiscoveryUtilsTest)
> java.lang.IllegalArgumentException: service.imported.configs property must be 
> set and non-empty
>   at 
> org.osgi.service.remoteserviceadmin.EndpointDescription.(EndpointDescription.java:121)
>   at 
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryUtils.getEndpointDescription(LocalDiscoveryUtils.java:160)
>   at 
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryUtils.getAllEndpointDescriptions(LocalDiscoveryUtils.java:113)
>   at 
> org.apache.cxf.dosgi.discovery.local.LocalDiscoveryUtilsTest.testAllEndpoints1(LocalDiscoveryUtilsTest.java:184)
> --snip--
> This can be easily reproduced in eclipse by running LocalDiscoveryUtils with 
> the current RSA classes in front of  the classpath.

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

[jira] Commented: (DOSGI-13) The CXF DOSGi implementation needs to be updated to support the latest OSGi Remote Services Admin spec.

[David Bosschaert (JIRA)]

[ 
https://issues.apache.org/jira/browse/DOSGI-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797650#action_12797650
 ] 

David Bosschaert commented on DOSGI-13:
---

Patch new_rsa_interfaces.patch applied with many thanks!

> The CXF DOSGi implementation needs to be updated to support the latest OSGi 
> Remote Services Admin spec.
> ---
>
> Key: DOSGI-13
> URL: https://issues.apache.org/jira/browse/DOSGI-13
> Project: CXF Distributed OSGi
>  Issue Type: Bug
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Attachments: cxf-dosgi-rsa-merge.patch, 
> discovery_startup__rsa_intents_and_property_overwrites.patch, disoveryPatch, 
> new_rsa_interfaces.patch, rsa_testCasesAndFixes.patch
>
>
> The API for Distributed OSGi has changed quite significantly between the text 
> in the RFC and the ultimate spec text. The DOSGi implementation in CXF needs 
> to be updated to support the new APIs as described in the (proposed) spec.

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

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

[Ravi Sukheja (JIRA)]

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


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-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:all-tabpanel
 ]

Vincenzo Vitale updated CXF-2471:
-

Affects Version/s: 2.2.5

> 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-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=12797729#action_12797729
 ] 

Daniel Kulp commented on CXF-2605:
--



We'd definitely need to have more information provided.   Preferably a testcase.

At a minimum, I'd need to see the wsdl/schema and the soap message to make sure 
the message that is being received/generated is proper compared to the schema.  
  The updated version of JAXB as part of the latest 2.2.x versions is a bit 
more strict about matching the schema.



> 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
>
> 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] Resolved: (CXF-2548) Aegis component attempts to assign new schema objects with an existing namespace URI to ServiceInfo if consecutive Clients are created for the same WSDL causing XmlSchemaEx

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2548.
--

   Resolution: Cannot Reproduce
Fix Version/s: Invalid


Could not reproduce this at all in our tests.   Request for more information is 
unanswered after almost a month.   

> Aegis component attempts to assign new schema objects with an existing 
> namespace URI to ServiceInfo if consecutive Clients are created for the same 
> WSDL causing XmlSchemaException: Schema name conflict in collection
> ---
>
> Key: CXF-2548
> URL: https://issues.apache.org/jira/browse/CXF-2548
> Project: CXF
>  Issue Type: Bug
>  Components: Aegis Databinding
>Affects Versions: 2.2.5, 2.2.6
> Environment: BEA JRockit 1.6.0 + WebLogic 10.3, Sun JDK 1.6.0
>Reporter: Antal Varga
>Priority: Critical
> Fix For: Invalid
>
>
> Revision 826052 changed the behaviour of 
> org.apache.cxf.frontend.ClientFactoryBean.create() so that subsequent calls 
> will create new Client objects.
> The ServiceInfos are cached between the creation of these objects so that the 
> SchemaCollection objects assigned to them also remain the same.
> However when an endpoint is created (it is called for both of the Clients) 
> and org.apache.cxf.aegis.databinding.AegisDatabinding.createSchemas()
> is run then (line 457) a new SchemaInfo is attempted to be added to the 
> schema collection with a namespace URI already in the collection
> (see API component 
> org.apache.cxf.service.model.ServiceInfo.addNewSchema(String)) because it was 
> already added
> during the creation of the previous Client object.
> I think prior to adding the new SchemaInfo it should be checked if an entry 
> with the given namespace URI already exists.

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

[jira] Commented: (CXF-2554) JaxWsDynamicClientFactory.createClient(URL) and o.a.cxf.endpoint.Client.invoke(String operationName, Object... params) generates illegal XML, WstxParsingException on serve

[Daniel Kulp (JIRA)]

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

Daniel Kulp commented on CXF-2554:
--

Mark, for you, do you have schema validation turned on?  I found a similar 
duplicate namespace issue on Monday when schema validation was turned on.   
That is now fixed on trunk/2.2.x.   Turning off schema validation may fix it 
for you if that is the case.

> JaxWsDynamicClientFactory.createClient(URL) and 
> o.a.cxf.endpoint.Client.invoke(String operationName, Object... params) 
> generates illegal XML, WstxParsingException on server.
> -
>
> Key: CXF-2554
> URL: https://issues.apache.org/jira/browse/CXF-2554
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.2.5, 2.2.6
> Environment: Microsoft Windows [Version 6.0.6002] (Vista Buisiness N 
> 64 bits)
> 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)
>Reporter: Gary Gregory
>Assignee: Daniel Kulp
> Fix For: 2.2.6
>
> Attachments: Apache CXF-2554.zip, Jre16_xml-Capture.JPG, 
> TestBackEndWss.wsdl
>
>
> Creating a client with:
> JaxWsDynamicClientFactory.newInstance().createClient(URL) 
> and calling it with:
> org.apache.cxf.endpoint.Client.invoke(String operationName, Object... params) 
> throws the Exception 
> com.ctc.wstx.exc.WstxParsingException: Duplicate declaration for namespace 
> prefix 'wsu'.
> on in server built with CXF
> Attaching WSDL.
> Logging output:
> Nov 20, 2009 11:31:12 AM org.apache.cxf.endpoint.dynamic.DynamicClientFactory 
> outputDebug
> INFO: Created classes: 
> appinterface.seagullsw.com.appinterfaceserver.ObjectFactory, 
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssAll, 
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssAllInResponse,
>  
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssAllInResponseResponse,
>  
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssAllResponse, 
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssEncrypt, 
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssEncryptResponse,
>  appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssSignature, 
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssSignatureResponse,
>  appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssTimestamp, 
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssTimestampResponse,
>  
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssUsernameToken,
>  
> appinterface.seagullsw.com.appinterfaceserver.TestOneStringArgWssUsernameTokenResponse
> Nov 20, 2009 11:31:18 AM org.apache.cxf.interceptor.LoggingInInterceptor 
> logging
> INFO: Inbound Message
> 
> ID: 15
> Address: /AppInterfaceServer
> Encoding: UTF-8
> Content-Type: text/xml; charset=UTF-8
> Headers: {content-type=[text/xml; charset=UTF-8], connection=[keep-alive], 
> transfer-encoding=[chunked], Host=[localhost:8070], 
> SOAPAction=["test.oneStringArgWssAll"], User-Agent=[Apache CXF 2.2.5], 
> Content-Type=[text/xml; charset=UTF-8], Accept=[*/*], Pragma=[no-cache], 
> Cache-Control=[no-cache]}
> Payload:  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
>  soap:mustUnderstand="1"> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
>  
> wsu:Id="Timestamp-5">2009-11-20T19:31:18.544Z2009-11-20T19:31:28.544Z  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"; 
> Id="EncKeyId-07EB048258FAA1C61812587454784635"> Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"; /> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
>  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>
> 
> CN=serverKeys
> 1205178067
> 
> 
> RL7Dc35cwFOyIjqrPbFrbTuQUjRrn4l4Xr5KGBhZlbyFCAnI/CO6oNdgk10kKajImSpFa+zw0LmrCZYhYE2k0VYs3fexwdmM6UpeIWqdEOVmpMiruqgY+39pd8AKJOqT9IQCnG9zQ3IP4TJKrdugBcYgLhsSnUvmh//mXEV96mE=  URI="#EncDataId-4" /> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; Id="Signature-2">
> 
>  Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"; />
> http://www.w3.org/2000/09/xmldsig#rsa-sha1"; />
> 
> 
> http://www.w3.org/2001/10/xml-exc-c14n#"; />
> 
> http://www.w3.org/2000/09/xmldsig#sha1"; />
> yVtODoPiC9+aUxFYj19IRxHI5fo=
> 
> 
> 
> RDIY/X+KWeofWR0aN5ErYSxs0AOJF9DE+8K+xFZb8VPMSRFO6UBZW/x59KtzvBeUR7nlLk+QGI3G
> 6O/tz7AAKG9m7Jwkxr/dWZBWXuZNaxid9+Lh7

[jira] Resolved: (CXF-2512) Faults while writing cause problems

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2512.
--

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


I'm going to resolve this as won't fix for the above reason.

However, with the changes for CXF-2596, a  fault listener can be setup to do 
custom things to not log when various semi-expected cases pop up.

> Faults while writing cause problems
> ---
>
> Key: CXF-2512
> URL: https://issues.apache.org/jira/browse/CXF-2512
> Project: CXF
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Benson Margulies
>Priority: Minor
> Fix For: Invalid
>
>
> This backtrace shows that someone is trying to create a fault after the 
> process of writing the response has started. This cannot be good. I'll attach 
> more as I debug more.
> Nov 1, 2009 6:37:13 AM 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean 
> buildServiceFromClass
> INFO: Creating Service 
> {http://fortest.javascript.cxf.apache.org/}AegisService from class 
> org.apache.cxf.javascript.fortest.AegisService
> Nov 1, 2009 6:37:14 AM org.apache.cxf.endpoint.ServerImpl initDestination
> INFO: Setting the server's publish address to be http://localhost:8808/aegis
> Nov 1, 2009 6:37:14 AM org.mortbay.log.Slf4jLog info
> INFO: Logging to org.slf4j.impl.JDK14LoggerAdapter(org.mortbay.log) via 
> org.mortbay.log.Slf4jLog
> Nov 1, 2009 6:37:14 AM org.mortbay.log.Slf4jLog info
> INFO: jetty-6.1.21
> Nov 1, 2009 6:37:14 AM org.mortbay.log.Slf4jLog info
> INFO: Started selectchannelconnec...@localhost:8808
> Nov 1, 2009 6:37:21 AM org.apache.cxf.javascript.AegisTest acceptAny
> INFO: About to call acceptAny with Raw XMLhttp://localhost:8808/aegis
> Nov 1, 2009 6:37:28 AM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> WARNING: Interceptor has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: Error writing to XMLStreamWriter.
>   at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:282)
>   at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:1)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>   at 
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(OutgoingChainInterceptor.java:76)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:109)
>   at 
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:312)
>   at 
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:276)
>   at 
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>   at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:326)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405)
>   at 
> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
>   at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> Caused by: com.ctc.wstx.exc.WstxIOException: null
>   at 
> com.ctc.wstx.sw.BaseStreamWriter._finishDocument(BaseStreamWriter.java:1431)
>   at 
> com.ctc.wstx.sw.BaseStreamWriter.writeEndDocument(BaseStreamWriter.java:553)
>   at 
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor.handleMessage(SoapOutInterceptor.java:277)
>   ... 19 more
> Caused by: org.mortbay.jetty.EofException
>   at 
> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:631)
>   at 
> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:579)
>   at 
> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:46)
>   at com.ctc.wstx.io.UTF8Writer.flush(UTF8Writer.java:100)
>   at com.ctc.wstx.sw.BufferingXmlWriter.flush(BufferingXmlWriter.java:225)
>   at com.ctc.wstx.sw.BufferingXmlWriter.close(Buffer

[jira] Resolved: (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 resolved CXF-2594.
--

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


Needed some extra cleanup in the SAAJOut handleFault method.

> 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.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
> g

[jira] Commented: (CXF-2595) Facilitate multi-branch development in Eclipse

[Daniel Kulp (JIRA)]

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

Daniel Kulp commented on CXF-2595:
--


I personally prefer NOT having the versions there as I have separate workspaces 
for the various branches I need.

Question:   could you use the eclipse.addVersionToProjectName flag to the 
eclipse plugin?

You should be able to do:

mvn  -Psetup.eclipse  -Declipse.addVersionToProjectName=true

You could also add something to your .m2/settings.xml like:

{code:xml}

extra



extra


/home/dkulp/working/workspace
true

/home/dkulp/working/workspace

true


 
{code}
to make it always do that.

> Facilitate multi-branch development in Eclipse
> --
>
> Key: CXF-2595
> URL: https://issues.apache.org/jira/browse/CXF-2595
> Project: CXF
>  Issue Type: Improvement
>Reporter: Gary Gregory
>
> It looks like CXF uses the Maven POM project/artifactId to name Eclipse 
> projects when the CXF maven tool is used:
> bq. mvn -Psetup.eclipse 
> This is great until you want to use the same Eclipse workspace to work on 
> multiple branches. 
> For example, I want to be able to compare debug runs in CXF 2.2.x and 2.3.x. 
> Switching workspaces is a pain and does not allow having two debug sessions 
> running at the same time.
> What about having the CXF {{setup.eclipse}} tool generate the Eclipse project 
> name to include the branch name? 
> For example, instead of {{cxf-api}}, use {{cxf-api-2.2.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-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 reassigned CXF-2591:


Assignee: Daniel Kulp

> 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
>
> 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] Assigned: (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 reassigned CXF-2545:


Assignee: Daniel Kulp

> 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
>
> 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 same problem.
> The strange thing is that it only occurs with one of my services and e

[jira] Resolved: (CXF-2586) SOAP over JMS 1.0 support is broken

[Daniel Kulp (JIRA)]

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

Daniel Kulp resolved CXF-2586.
--

   Resolution: Fixed
Fix Version/s: 2.3

> SOAP over JMS 1.0 support is broken
> ---
>
> Key: CXF-2586
> URL: https://issues.apache.org/jira/browse/CXF-2586
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 2.2.5
> Environment: Ubuntu 9.10
>Reporter: Kent Tong
>Assignee: Daniel Kulp
> Fix For: 2.3
>
>
> 1) Run WSDLToJava on the WSDL example at 
> http://cwiki.apache.org/CXF20DOC/soap-over-jms-10-support.html
> 2) Run the JMSGreeterPortType_GreeterPort_Server class generated.
> 3) It will throw an exception (see below).
> Starting Server
> Dec 19, 2009 10:50:57 PM 
> org.springframework.context.support.AbstractApplicationContext prepareRefresh
> INFO: Refreshing org.apache.cxf.bus.spring.busapplicationcont...@d6c16c: 
> display name [org.apache.cxf.bus.spring.busapplicationcont...@d6c16c]; 
> startup date [Sat Dec 19 22:50:57 HKT 2009]; root of context hierarchy
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-corba.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-jaxws.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-soap.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-xml.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-addr.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-javascript-client.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-local.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-http.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-management.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-http-jetty.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader 
> loadBeanDefinitions
> INFO: Loading XML bean definitions from class path resource 
> [META-INF/cxf/cxf-extension-http.xml]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.support.DefaultListableBeanFactory 
> registerBeanDefinition
> INFO: Overriding bean definition for bean 
> 'org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder': replacing 
> [Generic bean: class 
> [org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder]; 
> scope=singleton; abstract=false; lazyInit=false; autowireMode=0; 
> dependencyCheck=0; autowireCandidate=true; primary=false; 
> factoryBeanName=null; factoryMethodName=null; initMethodName=null; 
> destroyMethodName=null; defined in class path resource 
> [META-INF/cxf/cxf-extension-http.xml]] with [Generic bean: class 
> [org.apache.cxf.transport.http.policy.HTTPClientAssertionBuilder]; 
> scope=singleton; abstract=false; lazyInit=false; autowireMode=0; 
> dependencyCheck=0; autowireCandidate=true; primary=false; 
> factoryBeanName=null; factoryMethodName=null; initMethodName=null; 
> destroyMethodName=null; defined in class path resource 
> [META-INF/cxf/cxf-extension-http.xml]]
> Dec 19, 2009 10:50:58 PM 
> org.springframework.beans.factory.support.DefaultListableBeanFac

[jira] Commented: (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:comment-tabpanel&focusedCommentId=12797818#action_12797818
 ] 

Daniel Kulp commented on CXF-2581:
--

Bharath,  is with your commits and such, is this now considered resolved?



> 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-2595) Facilitate multi-branch development in Eclipse

[Gary Gregory (JIRA)]

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

Gary Gregory commented on CXF-2595:
---

I did not know about {{eclipse.addVersionToProjectName}}, thank you for the tip.

I do not think I want the trunk projects to carry a version number though. I do 
like having it all versions in one workspace to able to easily compare and port 
code around. I am thinking about a set up like this:
- I'll close all CXF 2.2.x projects in Eclipse.
- Run {{mvn -Psetup.eclipse -Declipse.addVersionToProjectName=true}} for 
branches I want (just 2.2.x really), my first run was just {{mvn 
-Psetup.eclipse}}
- Import all 2.2.x branch projects which will have the version numbers.
- Run {{mvn -Psetup.eclipse}} for trunk.
- Import all 2.3.x trunk projects which will not have the version numbers.

Presumably when 2.3.x is released, it will be branched and I can get the 2.3.x 
branch and run {{mvn -Psetup.eclipse -Declipse.addVersionToProjectName=true}} 
and keep trunk as is.

> Facilitate multi-branch development in Eclipse
> --
>
> Key: CXF-2595
> URL: https://issues.apache.org/jira/browse/CXF-2595
> Project: CXF
>  Issue Type: Improvement
>Reporter: Gary Gregory
>
> It looks like CXF uses the Maven POM project/artifactId to name Eclipse 
> projects when the CXF maven tool is used:
> bq. mvn -Psetup.eclipse 
> This is great until you want to use the same Eclipse workspace to work on 
> multiple branches. 
> For example, I want to be able to compare debug runs in CXF 2.2.x and 2.3.x. 
> Switching workspaces is a pain and does not allow having two debug sessions 
> running at the same time.
> What about having the CXF {{setup.eclipse}} tool generate the Eclipse project 
> name to include the branch name? 
> For example, instead of {{cxf-api}}, use {{cxf-api-2.2.x}}

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

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

[Hadrian Zbarcea (JIRA)]

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


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.