[jira] [Created] (CXF-7035) Default Swagger2Serializers dynamicBasePath code needs to sync BeanConfig with Swagger
Sergey Beryozkin created CXF-7035: - Summary: Default Swagger2Serializers dynamicBasePath code needs to sync BeanConfig with Swagger Key: CXF-7035 URL: https://issues.apache.org/jira/browse/CXF-7035 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: 3.2.0, 3.1.8, 3.0.11 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7022) Allow customization of Swagger JSON generation
[
https://issues.apache.org/jira/browse/CXF-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455232#comment-15455232
]
Sergey Beryozkin commented on CXF-7022:
---
Hi Francesco, FYI, I had to update the interface as part of this JIRA:
https://issues.apache.org/jira/browse/CXF-7035
By the way I start wondering if having an interface is a problem for the future
or not (I suggested it during our discussion :-)). We don't know what yet we
may need to make available on it. We can of course keep enhancing
DefaultSwagger2Serializers but it means other custom serializers will miss out
unless we update the interface.
Moving Swagger2Serilaizers code into its own class is def good but may be it
will be easier going forward simply to have Swagger2Serilaizers class and only
keep enhancing it ? (to support the extra headers, making BeanConfig as in case
of CXF-7035 visible to it, etc, etc)
> Allow customization of Swagger JSON generation
> --
>
> Key: CXF-7022
> URL: https://issues.apache.org/jira/browse/CXF-7022
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Labels: swagger
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> Swagger JSON generation is currently performed in
> {{org.apache.cxf.jaxrs.swagger.Swagger2Serializers}}, which is directly
> instantiated by {{org.apache.cxf.jaxrs.swagger.Swagger2Feature}}.
> The latter can take a former's instance as parameter, thus allowing
> customization in a given deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7022) Allow customization of Swagger JSON generation
[
https://issues.apache.org/jira/browse/CXF-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455232#comment-15455232
]
Sergey Beryozkin edited comment on CXF-7022 at 9/1/16 12:30 PM:
Hi Francesco, FYI, I had to update the interface as part of this JIRA:
https://issues.apache.org/jira/browse/CXF-7035
By the way I start wondering if having an interface is a problem for the future
or not (I suggested it during our discussion :-)). We don't know what yet we
may need to make available on it. We can of course keep enhancing
DefaultSwagger2Serializers but it means other custom serializers will miss out
unless we update the interface.
Moving Swagger2Serilaizers code into its own class is def good but may be it
will be easier going forward simply to have Swagger2Serilaizers class and only
keep enhancing it ? (to support the extra headers, making BeanConfig as in case
of CXF-7035 visible to it, etc, etc)
For example, right now a default one is missing the extra headers support which
can be of general interest
was (Author: sergey_beryozkin):
Hi Francesco, FYI, I had to update the interface as part of this JIRA:
https://issues.apache.org/jira/browse/CXF-7035
By the way I start wondering if having an interface is a problem for the future
or not (I suggested it during our discussion :-)). We don't know what yet we
may need to make available on it. We can of course keep enhancing
DefaultSwagger2Serializers but it means other custom serializers will miss out
unless we update the interface.
Moving Swagger2Serilaizers code into its own class is def good but may be it
will be easier going forward simply to have Swagger2Serilaizers class and only
keep enhancing it ? (to support the extra headers, making BeanConfig as in case
of CXF-7035 visible to it, etc, etc)
> Allow customization of Swagger JSON generation
> --
>
> Key: CXF-7022
> URL: https://issues.apache.org/jira/browse/CXF-7022
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Labels: swagger
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> Swagger JSON generation is currently performed in
> {{org.apache.cxf.jaxrs.swagger.Swagger2Serializers}}, which is directly
> instantiated by {{org.apache.cxf.jaxrs.swagger.Swagger2Feature}}.
> The latter can take a former's instance as parameter, thus allowing
> customization in a given deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CXF-6590) MAPCodec: memory leak with sync client when soapfaults returned from endpoint
[ https://issues.apache.org/jira/browse/CXF-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bjørn Hilstad reopened CXF-6590: Estimated Complexity: Moderate (was: Unknown) I verified this fix when it was created and it seemed fine, but it does not actually handle all cases. It does not leak memory anymore in the case where the soapfault uses an wsa.Action of http://www.w3.org/2005/08/addressing/fault. But there is still a leak when the soapfault uses a wsa:Action that can be used for non WSA related faults. This is http://www.w3.org/2005/08/addressing/soap/fault and it is described in the WS-Addressing specification here: https://www.w3.org/TR/ws-addr-soap/#faults . The specification says that this value MAY be used, but you are also allowed to define custom values. The same reproducer can be used to trigger this but you need to update the wsa:Action in the response that is sent from the wiremock-part (file __files\altinnunavailable.xml in archive wiremock.zip) We have tested againt the latest release of cxf (3.1.7) and the problem is there to. To change CXF versions in the reproducer you just update the property cxf.version in pom.xml (archive cxfoom.zip) > MAPCodec: memory leak with sync client when soapfaults returned from endpoint > - > > Key: CXF-6590 > URL: https://issues.apache.org/jira/browse/CXF-6590 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.0.6 > Environment: CXF 3.0.6, JDK 1.7, CXF 3.1.2 >Reporter: Bjørn Hilstad >Assignee: Daniel Kulp > Fix For: 3.1.3, 3.0.7 > > Attachments: cxfoom.zip, wiremock.zip > > > This bug is similar to CXF-2591 but relates to sync clients. > A simple client using a service with WS-Addressing which makes repeated calls > to a service that returns a soapfault will cause a build up of objects in > MAPCodec::uncorrelatedExchanges. > The real use case is an application using Apache Camel to keep invoking a > service that returns a fault (for instance wsa:DestinationUnreachable) using > the built in redelivery-functions of Apache Camel. > A simple CXF client that reproduces the issue has been created. The client > just invokes a service in a loop and by observing the used memory (jconsole) > and performing memory dumps which can be analyzed using MAT, you can see the > issue. > A standalone wiremock functions as the endpoint. > The reproducers will be attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7035) Default Swagger2Serializers dynamicBasePath code needs to sync BeanConfig with Swagger
[ https://issues.apache.org/jira/browse/CXF-7035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7035. --- Resolution: Fixed > Default Swagger2Serializers dynamicBasePath code needs to sync BeanConfig > with Swagger > -- > > Key: CXF-7035 > URL: https://issues.apache.org/jira/browse/CXF-7035 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.8, 3.0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7036) Huge Retained Heap for JAXB-CXF Binding
Ananya Das created CXF-7036: --- Summary: Huge Retained Heap for JAXB-CXF Binding Key: CXF-7036 URL: https://issues.apache.org/jira/browse/CXF-7036 Project: CXF Issue Type: Bug Components: JAXB Databinding Affects Versions: 2.4 Reporter: Ananya Das Priority: Critical CXF is abstracting the generation of JAXB classes from an XSD , the shallow size (for 4 objects) is 352 but retained size is 104,009,896. This is happening for every service we have - we have 7 services . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7022) Allow customization of Swagger JSON generation
[
https://issues.apache.org/jira/browse/CXF-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15457477#comment-15457477
]
Francesco Chicchiriccò commented on CXF-7022:
-
Agree, an interface might be overkill in this case: are you going to take care
of such refactoring? I can do it, but not before next Monday.
> Allow customization of Swagger JSON generation
> --
>
> Key: CXF-7022
> URL: https://issues.apache.org/jira/browse/CXF-7022
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Labels: swagger
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> Swagger JSON generation is currently performed in
> {{org.apache.cxf.jaxrs.swagger.Swagger2Serializers}}, which is directly
> instantiated by {{org.apache.cxf.jaxrs.swagger.Swagger2Feature}}.
> The latter can take a former's instance as parameter, thus allowing
> customization in a given deployment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
