[jira] [Updated] (CXF-6956) One of the application hosted on Apache CXF, is sporadically giving the following exception
[
https://issues.apache.org/jira/browse/CXF-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maninder Singh updated CXF-6956:
Affects Version/s: (was: 2.7.18)
2.7.14
Environment: JRE version 1.7.0_80-b35
> One of the application hosted on Apache CXF, is sporadically giving the
> following exception
> ---
>
> Key: CXF-6956
> URL: https://issues.apache.org/jira/browse/CXF-6956
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 2.7.14
> Environment: JRE version 1.7.0_80-b35
>Reporter: Maninder Singh
>
> Jun 01, 2016 2:47:34 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromWSDL
> INFO: Creating Service
> {http://www.something.com/oss/CertificateService}CertificateService from
> WSDL:
> jar:https://har2lb.rc103400.vodafone.in/mpfwsc/nbm/com-something-oss-mpfwsc-wscwrp_com-something-oss-csi-cert-gen-service-interface-10.25.493.3.jar!/META-INF/wsdl/CertificateService.wsdl
> Jun 01, 2016 2:47:36 PM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://www.something.com/oss/CertificateService}CertificateService#{http://www.something.com/oss/CertificateService}createCertificate
> has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Response was of unexpected text/html
> ContentType. Incoming portion of HTML stream: "-//IETF//DTD HTML 2.0//EN">
>
> 500 Internal Server Error
>
> Internal Server Error
> The server encountered an internal error or
> misconfiguration and was unable to complete
> your request.
> Please contact the server administrator,
> you@your.address and inform them of the time the error occurred,
> and anything you might have done that may have
> caused the error.
> More information about this error may be available
> in the server error log.
>
>
> at
> org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:95)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:849)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1642)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1520)
> at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1317)
> at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
> at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:632)
> at
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:572)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:481)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)
> at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:136)
> at com.sun.proxy.$Proxy31.createCertificate(Unknown Source)
> at
> com.something.oss.mpfcertgen.service.client.CertificateClient.createCertificate(CertificateClient.java:89)
> at
> com.something.oss.j2ee.client.library.UserCertificatesServiceClient.connect(UserCertificatesServiceClient.java:63)
> at
> com.something.oss.j2ee.client.library.UserCertificatesServiceClient.getLongTermKeyStore(UserCertificatesServiceClient.java:33)
> at
> com.something.oss.j2ee.client.library.ibm.initializations.JWSInitializationStrategy.createContextConfigurations(JWSInitializationStrategy.java:114)
> at
> com.something.oss.j2ee.client.library.ibm.initializations.JWSInitializationStrategy.execute(JWSInitializationStrategy.java:49)
> at
> com.something.oss.j2ee.client.library.ibm.IBMThinClient.initialize(IBMThinClient.java:23)
> at
> com.something.oss.j2ee.client.library.HTTPConnection.initializeImpl(HTTPConnection.java:36)
> at
> com.something.oss.j2ee.client.library.HTTPConnection.initialize(HTTPConnection.java:89)
> at
> com.something.oss.j2ee.client.library.HTTPConnection.getDefaultURL(HTTPConnection.java:48)
> at
> com.something.oss.descor.corzea.ZeroadminServletConnection.init(ZeroadminServletConnection.java:41)
> at
> org.netbeans.modules.zeroadmin.ZeroAdminInstall.load(ZeroAdminInstall.java:177)
> at
> org.netbeans.modules.zeroadmin.ZeroAdminInstall.restored(Ze
[jira] [Created] (CXF-6957) JAX-RS: ExceptionMapper not called for Fault
Philipp Förmer created CXF-6957: --- Summary: JAX-RS: ExceptionMapper not called for Fault Key: CXF-6957 URL: https://issues.apache.org/jira/browse/CXF-6957 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.1.6 Reporter: Philipp Förmer Hi, let service be a cxf jax-rs based service which uses a cxf based soap proxy client to communicate with a soap service. If the cxf soap proxy client throws a org.apache.cxf.binding.soap.SoapFault, then the SoapFault is not delegated to the jax-rs ExceptionMapper chain, which is for me an unexpected behaviour. As far as I can see this is caused by: org.apache.cxf.service.invoker.AbstractInvoker.invoke(...), L: 123 * Rethrows exception directly without wrapping it into a fault, if exception is of type org.apache.cxf.interceptor.Fault. SoapFault is a subclass of Fault. org.apache.cxf.jaxrs.JAXRSInvoker.handleFault, L:329 * Passes the cause of the fault to ExceptionUtils.convertFaultToResponse. The cause of the cxf SoapFault is null! org.apache.cxf.jaxrs.utils.ExceptionUtils.convertFaultToResponse, L.65: * Is called with null "ex" parameter and immediatley returns with null, so no exception mapper gets involved. Thank you for your support and great project, Philipp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358743#comment-15358743
]
Sergey Beryozkin commented on CXF-6869:
---
Hi Vedran, FYI, I've added an option to scan JAX-RS resources without them
having to be marked with @Component or returned from @Bean methods:
http://git-wip-us.apache.org/repos/asf/cxf/commit/7cd6ca06
It can help with auto-discovering 3rd party providers like Jackson which won't
be marked as Components or when modifying the own resources with Component is
not really needed.
I've added "jaxrs.classes-scan" property. It is mutually exclusive with
"jaxrs.component-scan"
Thanks
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6957) JAX-RS: ExceptionMapper not called for Fault
[ https://issues.apache.org/jira/browse/CXF-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358822#comment-15358822 ] Sergey Beryozkin commented on CXF-6957: --- Hi, in most cases we can't force users write ExceptionMappers for CXF-specific Fault in order for them to handle application specific exceptions thrown from their code but wrapped by CXF invokers into Fault. However, if the cause is null then indeed the actual Fault should be used Thanks > JAX-RS: ExceptionMapper not called for Fault > > > Key: CXF-6957 > URL: https://issues.apache.org/jira/browse/CXF-6957 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6 >Reporter: Philipp Förmer > > Hi, > let service be a cxf jax-rs based service which uses a cxf based soap proxy > client to communicate with a soap service. If the cxf soap proxy client > throws a org.apache.cxf.binding.soap.SoapFault, then the SoapFault is not > delegated to the jax-rs ExceptionMapper chain, which is for me an unexpected > behaviour. > As far as I can see this is caused by: > org.apache.cxf.service.invoker.AbstractInvoker.invoke(...), L: 123 > * Rethrows exception directly without wrapping it into a fault, if exception > is of type org.apache.cxf.interceptor.Fault. SoapFault is a subclass of Fault. > org.apache.cxf.jaxrs.JAXRSInvoker.handleFault, L:329 > * Passes the cause of the fault to ExceptionUtils.convertFaultToResponse. The > cause of the cxf SoapFault is null! > org.apache.cxf.jaxrs.utils.ExceptionUtils.convertFaultToResponse, L.65: > * Is called with null "ex" parameter and immediatley returns with null, so no > exception mapper gets involved. > Thank you for your support and great project, > Philipp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6957) JAX-RS: ExceptionMapper not called for Fault
[ https://issues.apache.org/jira/browse/CXF-6957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6957. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.2.0 3.1.7 3.0.10 > JAX-RS: ExceptionMapper not called for Fault > > > Key: CXF-6957 > URL: https://issues.apache.org/jira/browse/CXF-6957 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.6 >Reporter: Philipp Förmer >Assignee: Sergey Beryozkin > Fix For: 3.0.10, 3.1.7, 3.2.0 > > > Hi, > let service be a cxf jax-rs based service which uses a cxf based soap proxy > client to communicate with a soap service. If the cxf soap proxy client > throws a org.apache.cxf.binding.soap.SoapFault, then the SoapFault is not > delegated to the jax-rs ExceptionMapper chain, which is for me an unexpected > behaviour. > As far as I can see this is caused by: > org.apache.cxf.service.invoker.AbstractInvoker.invoke(...), L: 123 > * Rethrows exception directly without wrapping it into a fault, if exception > is of type org.apache.cxf.interceptor.Fault. SoapFault is a subclass of Fault. > org.apache.cxf.jaxrs.JAXRSInvoker.handleFault, L:329 > * Passes the cause of the fault to ExceptionUtils.convertFaultToResponse. The > cause of the cxf SoapFault is null! > org.apache.cxf.jaxrs.utils.ExceptionUtils.convertFaultToResponse, L.65: > * Is called with null "ex" parameter and immediatley returns with null, so no > exception mapper gets involved. > Thank you for your support and great project, > Philipp -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOSGI-242) Refactor provider to prepare for split
Christian Schneider created DOSGI-242: - Summary: Refactor provider to prepare for split Key: DOSGI-242 URL: https://issues.apache.org/jira/browse/DOSGI-242 Project: CXF Distributed OSGi Issue Type: Bug Components: DSW Affects Versions: 1.8.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 1.9.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DOSGI-241) Simplify examples
[ https://issues.apache.org/jira/browse/DOSGI-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved DOSGI-241. --- Resolution: Fixed > Simplify examples > - > > Key: DOSGI-241 > URL: https://issues.apache.org/jira/browse/DOSGI-241 > Project: CXF Distributed OSGi > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 1.9.0 > > > We have examples for spring, ds and OSGi APIs. The DS examples use > handwritten DS xml. The Greeter examples use a Swing UI and a quite > complicated interaction. > This does not really make it easy for the user to understand how to use CXF > DOSGi. > So I will first move all examples to annoation based DS which is the simplest > way of exposing OSGi services. I am sure the users can translate those simple > examples to other DI frameworks. > As a second step I would like to replace the greeter examples with something > simpler. > I think we really need 2 examples as a base: > 1. SOAP example using DS > 2. REST example using DS > The examples should be able to show local discovery as well as zookeeper > based discovery. > This shows the main usages of CXF-DOSGi. Later we also need to show > how to use additional CXF features and security. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358972#comment-15358972
]
Vedran Pavic commented on CXF-6869:
---
Hi Sergey,
{quote}
I'm OK with keeping cxf.path as is but if you happen to warm up a bit to a
"cxf.servlet.path" idea, then let me know
{quote}
I'm personally in favor of {{cxf.path}} over {{cxf.servlet.path}}. IMO it's a
good thing to be consistent with similar configuration properties in the Spring
Boot itself.
Regarding the argument for modeling configuration properties this way, consider
the {{web.xml}} itself - {{init-param}} and {{load-on-startup}} are attributes
of the Servlet whereas the {{servlet-mapping}} is completely external to the
Servlet.
Good to see you've added some support for more JAX-RS use cases.
With the latest change in mind I've got one suggestion for you to make the
configuration more concise - you could merge {{jaxrs.classes-scan}} and
{{jaxrs.component-scan}} properties into a single {{jaxrs.scan}} which is an
enum consisting of {{NONE}} (default), {{CLASSES}} and {{COMPONENTS}}. IMO it
makes sense since the options are mutually exclusive.
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6869) Consider adding Spring Boot starter
[
https://issues.apache.org/jira/browse/CXF-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358984#comment-15358984
]
Sergey Beryozkin commented on CXF-6869:
---
Hi Vedran
I'm not sure
"jaxrs.scan = CLASSES"
is a better try than
"jaxrs.classes-scan = true"
Besides, FYI, I'm thinking of relaxing it a bit and enhancing a component-only
scan server to optionally check for the classes too (ex to combine the explicit
components and 3rd party JAX-RS Providers not marked as Components)
Thanks
> Consider adding Spring Boot starter
> ---
>
> Key: CXF-6869
> URL: https://issues.apache.org/jira/browse/CXF-6869
> Project: CXF
> Issue Type: New Feature
> Components: Integration
>Reporter: Vedran Pavic
>Assignee: Sergey Beryozkin
> Fix For: 3.1.7, 3.2.0
>
>
> I've recently authored a PR in Spring Boot to add support for
> auto-configuration of {{CXFServlet}} and default CXF's configuration:
> https://github.com/spring-projects/spring-boot/pull/5659
> The PR was closed with "won't fix" resolution since Boot team are unwilling
> to add CXF as a dependency to the project. Instead a 3rd party starter was
> suggested.
> The concept of a 3rd party starter is generally encouraged for technologies
> that don't have first-class support in projects from Spring portfolio. Such
> 3rd party starters are listed here:
> https://github.com/spring-projects/spring-boot/blob/master/spring-boot-starters/README.adoc
> If CXF team is interested, I'm willing to port my PR to CXF.
> Note that the original PR was focused around JAX-WS support, but can be
> easily expanded to include JAX-RS support as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6958) Error in documentation
Jasper Horn created CXF-6958:
Summary: Error in documentation
Key: CXF-6958
URL: https://issues.apache.org/jira/browse/CXF-6958
Project: CXF
Issue Type: Bug
Reporter: Jasper Horn
On
http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
in the code sample that reads:
{code}
@Path("/bookstore")
public interface BookStore {
@GET
Books getAllBooks();
@Path("{id}")
BookResource getBookSubresource(@PathParam("id") long id) throws
NoBookFoundException;
}
public class BookStoreImpl implements BookStore {
public Books getAllBooks() {}
public Book getBookSubresource(long id) throws NoBookFoundException {}
}
public interface BookResource {
@GET
Book getBook();
}
public class BookResourceImpl implements BookResource {
Book getBook() {}
}
{code}
Shouldn't that be
{code}
public BookResource getBookSubresource(long id) throws NoBookFoundException
{}
{code}
(In other words, returning a BookResource instead of a Book)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6958) Error in documentation
[
https://issues.apache.org/jira/browse/CXF-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6958.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Client+API
I wish all issues were requiring as much effort as this one :-)
thanks
> Error in documentation
> --
>
> Key: CXF-6958
> URL: https://issues.apache.org/jira/browse/CXF-6958
> Project: CXF
> Issue Type: Bug
>Reporter: Jasper Horn
>Assignee: Sergey Beryozkin
>
> On
> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
> in the code sample that reads:
> {code}
> @Path("/bookstore")
> public interface BookStore {
>@GET
>Books getAllBooks();
>
>@Path("{id}")
>BookResource getBookSubresource(@PathParam("id") long id) throws
> NoBookFoundException;
> }
>
> public class BookStoreImpl implements BookStore {
>public Books getAllBooks() {}
>
>public Book getBookSubresource(long id) throws NoBookFoundException {}
> }
>
> public interface BookResource {
>@GET
>Book getBook();
> }
>
> public class BookResourceImpl implements BookResource {
>Book getBook() {}
> }
> {code}
> Shouldn't that be
> {code}
>public BookResource getBookSubresource(long id) throws
> NoBookFoundException {}
> {code}
> (In other words, returning a BookResource instead of a Book)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
