[jira] [Comment Edited] (CXF-7019) tests in rt/ws/transfer intermittently failure
[
https://issues.apache.org/jira/browse/CXF-7019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434310#comment-15434310
]
Freeman Fang edited comment on CXF-7019 at 8/24/16 8:35 AM:
commit fix
http://git-wip-us.apache.org/repos/asf/cxf/commit/9bcde744
http://git-wip-us.apache.org/repos/asf/cxf/commit/39a5690d
was (Author: ffang):
commit fix
http://git-wip-us.apache.org/repos/asf/cxf/commit/9bcde744
> tests in rt/ws/transfer intermittently failure
> --
>
> Key: CXF-7019
> URL: https://issues.apache.org/jira/browse/CXF-7019
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.2.0
>
>
> get exception like
> {code}
> org.apache.ws.commons.schema.XmlSchemaException: Unable to locate imported
> document at 'http://www.w3.org/2006/03/addressing/ws-addr.xsd', relative to
> 'schema1.xsd'.
> at
> org.apache.cxf.catalog.CatalogXmlSchemaURIResolver.resolveEntity(CatalogXmlSchemaURIResolver.java:76)
> at
> org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:684)
> at
> org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:538)
> at
> org.apache.ws.commons.schema.SchemaBuilder.handleSchemaElementChild(SchemaBuilder.java:1516)
> at
> org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:659)
> at
> org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:157)
> at
> org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:508)
> at
> org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:494)
> at
> org.apache.cxf.common.xmlschema.SchemaCollection.read(SchemaCollection.java:133)
> at
> org.apache.cxf.databinding.AbstractDataBinding.addSchemaDocument(AbstractDataBinding.java:193)
> at
> org.apache.cxf.databinding.AbstractDataBinding.addSchemaDocument(AbstractDataBinding.java:96)
> at
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:388)
> at
> org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:469)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:696)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
> at
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
> at
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
> at
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
> at
> org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
> at
> org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:211)
> at
> org.apache.cxf.ws.transfer.integration.IntegrationBaseTest.createLocalResource(IntegrationBaseTest.java:159)
> at
> org.apache.cxf.ws.transfer.integration.FragmentGetQNameTest.qetEmptyResultTest(FragmentGetQNameTest.java:99)
> {code}
> this is due to try download ws-addr.xsd remotely, we should add
> jax-ws-catalog.xml to always use the local one
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7020) explicity create woodstox event factory as fallback if XMLEventFactory.newInstance fail
Freeman Fang created CXF-7020: - Summary: explicity create woodstox event factory as fallback if XMLEventFactory.newInstance fail Key: CXF-7020 URL: https://issues.apache.org/jira/browse/CXF-7020 Project: CXF Issue Type: Improvement Reporter: Freeman Fang similarly as we create the XMLInputFactory in StaxUtils -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-7020) explicity create woodstox event factory as fallback if XMLEventFactory.newInstance fail
[ https://issues.apache.org/jira/browse/CXF-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-7020: - Assignee: Freeman Fang > explicity create woodstox event factory as fallback if > XMLEventFactory.newInstance fail > --- > > Key: CXF-7020 > URL: https://issues.apache.org/jira/browse/CXF-7020 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang > > similarly as we create the XMLInputFactory in StaxUtils -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7021) The WS-SecurityPolicy TransportBinding does not respect the digest method of the algorithm suite
Colm O hEigeartaigh created CXF-7021: Summary: The WS-SecurityPolicy TransportBinding does not respect the digest method of the algorithm suite Key: CXF-7021 URL: https://issues.apache.org/jira/browse/CXF-7021 Project: CXF Issue Type: Bug Affects Versions: 3.1.7, 3.0.10 Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.1.8, 3.0.11 The WS-SecurityPolicy TransportBinding does not respect the digest method of the algorithm suite. So if a SHA-256 digest policy is enabled, the signature digest method will still use the default SHA-1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-7013) SAML token using ws-security.callback-handler as for UT with ID attribute value
[ https://issues.apache.org/jira/browse/CXF-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-7013: Assignee: Colm O hEigeartaigh > SAML token using ws-security.callback-handler as for UT with ID attribute > value > --- > > Key: CXF-7013 > URL: https://issues.apache.org/jira/browse/CXF-7013 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh >Priority: Minor > > Processing of SAML token results in call of configured > ws-security.callback-handler same as for Username Token. > When CXF receives (no UT in it): > >ID="Abc-1" IssueInstant="2016-08-16T08:13:47Z" Version="2.0"> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=user > >Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">some_name >... > > it calls configured: > ws-security.callback-handler=com.SecurityCallback > with ID="Abc-1" from above Security section as username. > Ignoring this and moving on has no impact on processing SAML token but if > SecurityCallback does some funny stuff (or at list logging) for each received > UT it is really confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-7013) SAML token using ws-security.callback-handler as for UT with ID attribute value
[ https://issues.apache.org/jira/browse/CXF-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-7013: Assignee: Colm O hEigeartaigh > SAML token using ws-security.callback-handler as for UT with ID attribute > value > --- > > Key: CXF-7013 > URL: https://issues.apache.org/jira/browse/CXF-7013 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh >Priority: Minor > > Processing of SAML token results in call of configured > ws-security.callback-handler same as for Username Token. > When CXF receives (no UT in it): > >ID="Abc-1" IssueInstant="2016-08-16T08:13:47Z" Version="2.0"> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=user > >Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">some_name >... > > it calls configured: > ws-security.callback-handler=com.SecurityCallback > with ID="Abc-1" from above Security section as username. > Ignoring this and moving on has no impact on processing SAML token but if > SecurityCallback does some funny stuff (or at list logging) for each received > UT it is really confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7022) Allow customization of Swagger JSON generation
Francesco Chicchiriccò created CXF-7022:
---
Summary: 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ò
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] [Resolved] (CXF-7013) SAML token using ws-security.callback-handler as for UT with ID attribute value
[ https://issues.apache.org/jira/browse/CXF-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7013. -- Resolution: Not A Problem > SAML token using ws-security.callback-handler as for UT with ID attribute > value > --- > > Key: CXF-7013 > URL: https://issues.apache.org/jira/browse/CXF-7013 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh >Priority: Minor > > Processing of SAML token results in call of configured > ws-security.callback-handler same as for Username Token. > When CXF receives (no UT in it): > >ID="Abc-1" IssueInstant="2016-08-16T08:13:47Z" Version="2.0"> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=user > >Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">some_name >... > > it calls configured: > ws-security.callback-handler=com.SecurityCallback > with ID="Abc-1" from above Security section as username. > Ignoring this and moving on has no impact on processing SAML token but if > SecurityCallback does some funny stuff (or at list logging) for each received > UT it is really confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7013) SAML token using ws-security.callback-handler as for UT with ID attribute value
[ https://issues.apache.org/jira/browse/CXF-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434778#comment-15434778 ] Colm O hEigeartaigh commented on CXF-7013: -- What's happening here is that WSS4J is querying a CallbackHandler for a secret key associated with the Subject of the Assertion. It creates a WSPasswordCallback using the SAML Assertion Id and the usage "WSPasswordCallback.SECRET_KEY". So if you want to handle this in your CallbackHandler, then simply check the WSPasswordCallback usage and handle it accordingly, otherwise ignore. To avoid confusing logging, you can just log in the usage for "USERNAME_TOKEN". Colm. > SAML token using ws-security.callback-handler as for UT with ID attribute > value > --- > > Key: CXF-7013 > URL: https://issues.apache.org/jira/browse/CXF-7013 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh >Priority: Minor > > Processing of SAML token results in call of configured > ws-security.callback-handler same as for Username Token. > When CXF receives (no UT in it): > >ID="Abc-1" IssueInstant="2016-08-16T08:13:47Z" Version="2.0"> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=user > >Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">some_name >... > > it calls configured: > ws-security.callback-handler=com.SecurityCallback > with ID="Abc-1" from above Security section as username. > Ignoring this and moving on has no impact on processing SAML token but if > SecurityCallback does some funny stuff (or at list logging) for each received > UT it is really confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig
[
https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434861#comment-15434861
]
Damian Malczyk commented on CXF-6910:
-
How can I configure read timeout per Conduit right now? As I understand,
connection manager and all its properties like TTL, is bound to
AsyncHTTPConduitFactory, not Conduit itself.
> don't need setSocketTimeout when create ahc RequestConfig
> -
>
> Key: CXF-6910
> URL: https://issues.apache.org/jira/browse/CXF-6910
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> currently when we create the ahc RequestConfig we set the socketTimeout as
> setSocketTimeout((int) csPolicy.getReceiveTimeout()
> this cause the created http connection controlled by the socket level
> timeout, that said, if there's no data on the socket in a certain time, the
> connection would be closed, this overrule the TTL value of a connection,
> which means the connection timeToLive can't be managed by a
> connectionPoolManager, this is really painful for heavy loaded client request
> as we want the connectionPoolManager to manage the connection so that we
> could reuse the connection.
> Fortunately in AsyncHTTPConduit
> {code}
> protected synchronized HttpResponse getHttpResponse()
> {code}
> we already handle the timeout at application level so that we needn't set
> that at socket level, so that let the connectionPoolManager can decide the
> connection TTL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7022) Allow customization of Swagger JSON generation
[
https://issues.apache.org/jira/browse/CXF-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Chicchiriccò resolved CXF-7022.
-
Resolution: Fixed
> 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-6910) don't need setSocketTimeout when create ahc RequestConfig
[
https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434861#comment-15434861
]
Damian Malczyk edited comment on CXF-6910 at 8/24/16 1:15 PM:
--
How can I configure read timeout per Conduit right now? As I understand,
connection manager and all its properties like TTL, is bound to
AsyncHTTPConduitFactory, not Conduit itself.
For me it looks like:
{code}protected synchronized HttpResponse getHttpResponse(){code}
is used only after HTTP response is set by callback in async mode so it does
not enforce read timeout
was (Author: ddms):
How can I configure read timeout per Conduit right now? As I understand,
connection manager and all its properties like TTL, is bound to
AsyncHTTPConduitFactory, not Conduit itself.
> don't need setSocketTimeout when create ahc RequestConfig
> -
>
> Key: CXF-6910
> URL: https://issues.apache.org/jira/browse/CXF-6910
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> currently when we create the ahc RequestConfig we set the socketTimeout as
> setSocketTimeout((int) csPolicy.getReceiveTimeout()
> this cause the created http connection controlled by the socket level
> timeout, that said, if there's no data on the socket in a certain time, the
> connection would be closed, this overrule the TTL value of a connection,
> which means the connection timeToLive can't be managed by a
> connectionPoolManager, this is really painful for heavy loaded client request
> as we want the connectionPoolManager to manage the connection so that we
> could reuse the connection.
> Fortunately in AsyncHTTPConduit
> {code}
> protected synchronized HttpResponse getHttpResponse()
> {code}
> we already handle the timeout at application level so that we needn't set
> that at socket level, so that let the connectionPoolManager can decide the
> connection TTL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6910) don't need setSocketTimeout when create ahc RequestConfig
[
https://issues.apache.org/jira/browse/CXF-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15434924#comment-15434924
]
Freeman Fang commented on CXF-6910:
---
Same as before.
> don't need setSocketTimeout when create ahc RequestConfig
> -
>
> Key: CXF-6910
> URL: https://issues.apache.org/jira/browse/CXF-6910
> Project: CXF
> Issue Type: Improvement
> Components: Transports
>Reporter: Freeman Fang
>Assignee: Freeman Fang
> Fix For: 3.0.10, 3.1.7, 3.2.0
>
>
> currently when we create the ahc RequestConfig we set the socketTimeout as
> setSocketTimeout((int) csPolicy.getReceiveTimeout()
> this cause the created http connection controlled by the socket level
> timeout, that said, if there's no data on the socket in a certain time, the
> connection would be closed, this overrule the TTL value of a connection,
> which means the connection timeToLive can't be managed by a
> connectionPoolManager, this is really painful for heavy loaded client request
> as we want the connectionPoolManager to manage the connection so that we
> could reuse the connection.
> Fortunately in AsyncHTTPConduit
> {code}
> protected synchronized HttpResponse getHttpResponse()
> {code}
> we already handle the timeout at application level so that we needn't set
> that at socket level, so that let the connectionPoolManager can decide the
> connection TTL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7021) The WS-SecurityPolicy TransportBinding does not respect the digest method of the algorithm suite
[ https://issues.apache.org/jira/browse/CXF-7021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7021. -- Resolution: Fixed > The WS-SecurityPolicy TransportBinding does not respect the digest method of > the algorithm suite > > > Key: CXF-7021 > URL: https://issues.apache.org/jira/browse/CXF-7021 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.10, 3.1.7 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 3.1.8, 3.0.11 > > > The WS-SecurityPolicy TransportBinding does not respect the digest method of > the algorithm suite. So if a SHA-256 digest policy is enabled, the signature > digest method will still use the default SHA-1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7013) SAML token using ws-security.callback-handler as for UT with ID attribute value
[ https://issues.apache.org/jira/browse/CXF-7013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15435228#comment-15435228 ] Colm O hEigeartaigh commented on CXF-7013: -- For the record, I've changed how this works in WSS4J 2.2.0 (not backporting for backwards compatibility reasons): https://issues.apache.org/jira/browse/WSS-586 > SAML token using ws-security.callback-handler as for UT with ID attribute > value > --- > > Key: CXF-7013 > URL: https://issues.apache.org/jira/browse/CXF-7013 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh >Priority: Minor > > Processing of SAML token results in call of configured > ws-security.callback-handler same as for Username Token. > When CXF receives (no UT in it): > >ID="Abc-1" IssueInstant="2016-08-16T08:13:47Z" Version="2.0"> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">CN=user > >Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">some_name >... > > it calls configured: > ws-security.callback-handler=com.SecurityCallback > with ID="Abc-1" from above Security section as username. > Ignoring this and moving on has no impact on processing SAML token but if > SecurityCallback does some funny stuff (or at list logging) for each received > UT it is really confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7020) explicity create woodstox event factory as fallback if XMLEventFactory.newInstance fail
[ https://issues.apache.org/jira/browse/CXF-7020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-7020. --- Resolution: Fixed Fix Version/s: 3.1.8 3.2.0 > explicity create woodstox event factory as fallback if > XMLEventFactory.newInstance fail > --- > > Key: CXF-7020 > URL: https://issues.apache.org/jira/browse/CXF-7020 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.2.0, 3.1.8 > > > similarly as we create the XMLInputFactory in StaxUtils -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15436321#comment-15436321
]
Niten Aggarwal commented on CXF-6740:
-
Hi Andriy,
Is 3.2.0 available at master repo? Somehow build not finding version so let me
know correct repo location.
Thanks
Nitin
> Collision by Swagger2Feature in two OSGI bundles
> -
>
> Key: CXF-6740
> URL: https://issues.apache.org/jira/browse/CXF-6740
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.4
> Environment: Apache Karaf 4.0.2
>Reporter: Andre Schlegel
>Assignee: Andriy Redko
> Fix For: 3.2.0, 3.1.8
>
> Attachments: 0001-temporary-work-for-cxf-6740-take-2.patch,
> 0001-temporary-work-for-cxf-6740.patch, CXF-6740-Collision-by-Swagger.patch
>
>
> I have two separate bundles in my karaf, which are using cxf with the
> swagger2feature. The endpoints (/cxf/bpc-core and /cxf/bpc-monitor/ ) in both
> bundles working fine. But I got on both swagger-URL the same swagger-File
> (both for the monitor endpoints).
> I'm using the blueprint for swagger2feature configuration and annotation for
> the endpoints.
> core bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.core.resource.AuthenticationResource" />
> class="de.virtimo.bpc.core.resource.Configuration" />
>
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> Monitor Bundle
> {code}
> http://www.osgi.org/xmlns/blueprint/v1.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xmlns:cxf="http://cxf.apache.org/blueprint/core";
>xmlns:jaxrs="http://cxf.apache.org/blueprint/jaxrs";
>xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>http://cxf.apache.org/blueprint/core
> http://cxf.apache.org/schemas/blueprint/core.xsd
>http://cxf.apache.org/jaxrs
> http://cxf.apache.org/schemas/blueprint/jaxrs.xsd";>
>
> class="com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider" />
>
> class="de.virtimo.bpc.module.monitor.resource.Monitor" />
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
> Center"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
> I got the swagger-file for the monitor bundle on /cxf/bpc-core/swagger.json
> and /cxf/bpc-monitor/swagger.json
> Anyone suggestion how to handle this scenario?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
