[jira] [Created] (CXF-6763) STS requires ClaimHandler even in ClaimMapping only scenarios
Jan Bernhardt created CXF-6763:
--
Summary: STS requires ClaimHandler even in ClaimMapping only
scenarios
Key: CXF-6763
URL: https://issues.apache.org/jira/browse/CXF-6763
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 3.1.4
Reporter: Jan Bernhardt
Priority: Minor
In case that the STS is used only for token mapping, the STS does not need
ClaimHandler to lookup claims from a backend.
Example Scenario: Fediz-IDP is used as a RP-IDP only (with no direct user
login), but only doing claim mappings.
In this case the STS only needs a relationship with a ClaimMapper, but no
ClaimHandler are required.
The following code within {{org.apache.cxf.sts.operation.TokenIssueOperation}}
however checks if ClaimMapper for requested Claims exists and fails if not.
{code}
//Check if the requested claims can be handled by the configured claim handlers
ClaimCollection requestedClaims =
providerParameters.getRequestedPrimaryClaims();
checkClaimsSupport(requestedClaims);
requestedClaims = providerParameters.getRequestedSecondaryClaims();
checkClaimsSupport(requestedClaims);
providerParameters.setClaimsManager(claimsManager);
{code}
>From my understanding these {{checkClaimsSupport}} can be removed completely,
>because the STS will still fail, if the requested Claims are not available in
>the end.
--
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=15118940#comment-15118940
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy,
thanks for verifying the issue. I think the patch applied there is somewhat
unnecessarily complex (in terms of the code change and classes added and the
configuration required) and we could suggest a simpler approach along what I
sketched. Yes. I can share the stuff that I experimented. The only issue that I
had with what I did was that I was not getting the thread-local behavior from
context.setAttribtue(key) and context.getAttribtue(key) when I was using out of
the box configuration with the cxf's jaxrs sample code on Karaf. Do I need to
set some property or does it not work this way? Sergey?
regards, aki
> 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
>
> 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)
[jira] [Assigned] (CXF-6763) STS requires ClaimHandler even in ClaimMapping only scenarios
[
https://issues.apache.org/jira/browse/CXF-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh reassigned CXF-6763:
Assignee: Colm O hEigeartaigh
> STS requires ClaimHandler even in ClaimMapping only scenarios
> -
>
> Key: CXF-6763
> URL: https://issues.apache.org/jira/browse/CXF-6763
> Project: CXF
> Issue Type: Bug
> Components: STS
>Affects Versions: 3.1.4
>Reporter: Jan Bernhardt
>Assignee: Colm O hEigeartaigh
>Priority: Minor
>
> In case that the STS is used only for token mapping, the STS does not need
> ClaimHandler to lookup claims from a backend.
> Example Scenario: Fediz-IDP is used as a RP-IDP only (with no direct user
> login), but only doing claim mappings.
> In this case the STS only needs a relationship with a ClaimMapper, but no
> ClaimHandler are required.
> The following code within
> {{org.apache.cxf.sts.operation.TokenIssueOperation}} however checks if
> ClaimMapper for requested Claims exists and fails if not.
> {code}
> //Check if the requested claims can be handled by the configured claim
> handlers
> ClaimCollection requestedClaims =
> providerParameters.getRequestedPrimaryClaims();
> checkClaimsSupport(requestedClaims);
> requestedClaims = providerParameters.getRequestedSecondaryClaims();
> checkClaimsSupport(requestedClaims);
> providerParameters.setClaimsManager(claimsManager);
> {code}
> From my understanding these {{checkClaimsSupport}} can be removed completely,
> because the STS will still fail, if the requested Claims are not available in
> the end.
--
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=15119012#comment-15119012
]
Sergey Beryozkin commented on CXF-6740:
---
Hi Aki, which 'context' are you referring too ?
JAX-RS filter one has a setProperty/getProperty, and it must be tied to
httpRequest by default, but if you work directly with the CXF message, it
should be OKSorry if I'm missing something
Cheers, Sergey
> 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
>
> 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)
[jira] [Updated] (CXF-6763) STS requires ClaimHandler even in ClaimMapping only scenarios
[
https://issues.apache.org/jira/browse/CXF-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-6763:
-
Fix Version/s: 3.0.8
3.1.5
> STS requires ClaimHandler even in ClaimMapping only scenarios
> -
>
> Key: CXF-6763
> URL: https://issues.apache.org/jira/browse/CXF-6763
> Project: CXF
> Issue Type: Bug
> Components: STS
>Affects Versions: 3.1.4
>Reporter: Jan Bernhardt
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.1.5, 3.0.8
>
>
> In case that the STS is used only for token mapping, the STS does not need
> ClaimHandler to lookup claims from a backend.
> Example Scenario: Fediz-IDP is used as a RP-IDP only (with no direct user
> login), but only doing claim mappings.
> In this case the STS only needs a relationship with a ClaimMapper, but no
> ClaimHandler are required.
> The following code within
> {{org.apache.cxf.sts.operation.TokenIssueOperation}} however checks if
> ClaimMapper for requested Claims exists and fails if not.
> {code}
> //Check if the requested claims can be handled by the configured claim
> handlers
> ClaimCollection requestedClaims =
> providerParameters.getRequestedPrimaryClaims();
> checkClaimsSupport(requestedClaims);
> requestedClaims = providerParameters.getRequestedSecondaryClaims();
> checkClaimsSupport(requestedClaims);
> providerParameters.setClaimsManager(claimsManager);
> {code}
> From my understanding these {{checkClaimsSupport}} can be removed completely,
> because the STS will still fail, if the requested Claims are not available in
> the end.
--
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=15119041#comment-15119041
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Andriy, Sergey,
My temporary change to swagger-core is in my git branch [1]
It is branched from the origin's 01-18 version with this minor change [2]. That
means, it does not include the change included with swagger-1482.
And I am attachning the change and some samples for cxf as a patch file against
cxf's current master [3]
Once you build both swagger-core and cxf projects including the two samples at
its sample folders. You can install them on karaf by running the karaf comands
feature:repo-add cxf 3.2.0-SNAPSHOT
feature:install cxf-rs-description-swagger2
install -s mvn:org.apache.cxf.samples/jax_rs_description_swagger2_osgi
install -s mvn:org.apache.cxf.samples/jax_rs_description_swagger2_osgi2
and from the console, run
curl http://localhost:8181/cxf/swaggerSample/swagger.yaml
and
curl http://localhost:8181/cxf/swaggerSample2/swagger.yaml
to get two different swagger documents.
However, as I mentioned, if the first call is held between its set and get
lines and the second call's set is invoked, both calls will get the second
document. And this was my question mentioned earlier, whether we should add
another context attribute "swagger.local" with true or false to use the
uri-path to do the lookup in the context when this is set to true.
[1] https://github.com/elakito/swagger-core/tree/alt-1482
[2]
https://github.com/elakito/swagger-core/commit/957e06ecce5a1286e882c6fda2c0a776eec9f2c0
[3] 0001-temporary-work-for-cxf-6740.patch attached in this ticket
> 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
>
> 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#63
[jira] [Updated] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida updated CXF-6740:
--
Attachment: 0001-temporary-work-for-cxf-6740.patch
> 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
> Attachments: 0001-temporary-work-for-cxf-6740.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)
[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=15119055#comment-15119055
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey,
I am talking about servletContext that is injected in our code both to our
custom RequestFilter instance and Swagger's ApiListingResource.
As this seems to be a natural way to pass information from CXF to Swagger.
However, I think we should use a map as its value because it seems to be shared
among all the calling threads?
Or I am missing something here because when I use a normal thread, I observe
the thread-local behavior but not with the two calling threads.
regards, aki
> 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
> Attachments: 0001-temporary-work-for-cxf-6740.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)
[jira] [Resolved] (CXF-6763) STS requires ClaimHandler even in ClaimMapping only scenarios
[
https://issues.apache.org/jira/browse/CXF-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-6763.
--
Resolution: Fixed
> STS requires ClaimHandler even in ClaimMapping only scenarios
> -
>
> Key: CXF-6763
> URL: https://issues.apache.org/jira/browse/CXF-6763
> Project: CXF
> Issue Type: Bug
> Components: STS
>Affects Versions: 3.1.4
>Reporter: Jan Bernhardt
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 3.1.5, 3.0.8
>
>
> In case that the STS is used only for token mapping, the STS does not need
> ClaimHandler to lookup claims from a backend.
> Example Scenario: Fediz-IDP is used as a RP-IDP only (with no direct user
> login), but only doing claim mappings.
> In this case the STS only needs a relationship with a ClaimMapper, but no
> ClaimHandler are required.
> The following code within
> {{org.apache.cxf.sts.operation.TokenIssueOperation}} however checks if
> ClaimMapper for requested Claims exists and fails if not.
> {code}
> //Check if the requested claims can be handled by the configured claim
> handlers
> ClaimCollection requestedClaims =
> providerParameters.getRequestedPrimaryClaims();
> checkClaimsSupport(requestedClaims);
> requestedClaims = providerParameters.getRequestedSecondaryClaims();
> checkClaimsSupport(requestedClaims);
> providerParameters.setClaimsManager(claimsManager);
> {code}
> From my understanding these {{checkClaimsSupport}} can be removed completely,
> because the STS will still fail, if the requested Claims are not available in
> the end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6761) JAX-RS ClientImpl does not set TLSClientParameters on HTTPConduit when only HostnameVerifier is configured
[
https://issues.apache.org/jira/browse/CXF-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6761.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.2.0
3.0.8
3.1.5
Thanks for the patch
> JAX-RS ClientImpl does not set TLSClientParameters on HTTPConduit when only
> HostnameVerifier is configured
> --
>
> Key: CXF-6761
> URL: https://issues.apache.org/jira/browse/CXF-6761
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4
>Reporter: Chris Ribble
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> org.apache.cxf.jaxrs.client.spec.ClientImpl only copies the
> TLSClientParameters configured by
> ClientBuilder.newBuilder().hostnameVerifier(HostnameVerifier) if an
> SSLSocketFactory or TrustManagers are configured.
> This makes it impossible to use a custom HostnameVerifier without also
> declaring a custom SSLSocketFactory or TrustManagers.
> Snip of incorrect code from
> rt/rs/client/src/main/java/org/apache/cxf/jaxrs/client/spec/ClientImpl.java,
> line 282
> {code}
> // TLS
> TLSClientParameters tlsParams = secConfig.getTlsClientParams();
> if (tlsParams.getSSLSocketFactory() != null
> || tlsParams.getTrustManagers() != null) {
> clientCfg.getHttpConduit().setTlsClientParameters(tlsParams);
> }
> {code}
> Proposed replacement:
> {code}
> // TLS
> TLSClientParameters tlsParams = secConfig.getTlsClientParams();
> if (tlsParams.getSSLSocketFactory() != null
> || tlsParams.getTrustManagers() != null
> || tlsParams.getHostnameVerifier() != null) {
> clientCfg.getHttpConduit().setTlsClientParameters(tlsParams);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6760) extract swagger2 feature in its own module
[ https://issues.apache.org/jira/browse/CXF-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119103#comment-15119103 ] Sergey Beryozkin commented on CXF-6760: --- Hi Romain, it makes sense as it looks like the swagger related code can grow up quite a bit (I'm not even completely rejecting the idea of implementing Swagger spec in Java :-)), though we won't have time to do it for the coming 3.1.5 in the next couple of days, more likely for 3.1.6 > extract swagger2 feature in its own module > -- > > Key: CXF-6760 > URL: https://issues.apache.org/jira/browse/CXF-6760 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Romain Manni-Bucau > > the feature is not provided *with*dependencies so if cxf is in the container > and swagger the webapp then it leads very easily to issues. > Having an external module would make it smoother for integrations and doesnt > really hurt CXF. -- 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=15119128#comment-15119128
]
Sergey Beryozkin commented on CXF-6740:
---
Hi Aki
Right, CXF has a TL storage for making sure the injected contexts are thread
specific but the actual context value does not offer a TL storage for keeping
the attributes.
How about the following, register a custom CXF ContextProvider, in
jaxrs:providers:
{code:java}
public ServletContextProvider implements ContextProvider {
public ServletContext createContext(Message message) {
ServletContext sc = (ServletContext)message.get("HTTP.CONTEXT");
// ThreadLocalServletContext - custom ServletContext impl which delegates
to the original SC but
// manages the attributes in a thread local storage
return ThreadLocalServletContext(sc);
}
}
{code}
Perhaps it can work ?
Sergey
> 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
> Attachments: 0001-temporary-work-for-cxf-6740.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)
[jira] [Commented] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119179#comment-15119179
]
Neal Hu commented on CXF-6759:
--
I agree. The ultimate way is check the method signature, but seams too
complicated. Let's just hold all method names in same class. Need I work out
the patch?
Neal
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6738) Reduce contention on org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo
[ https://issues.apache.org/jira/browse/CXF-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119189#comment-15119189 ] ASF GitHub Bot commented on CXF-6738: - Github user asoldano closed the pull request at: https://github.com/apache/cxf/pull/105 > Reduce contention on > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo > -- > > Key: CXF-6738 > URL: https://issues.apache.org/jira/browse/CXF-6738 > Project: CXF > Issue Type: Improvement > Components: JAX-WS Runtime >Reporter: Alessio Soldano > > By profiling some benchmark application, > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo has been > found in the contention hotspots. That's because of the multiple synchronized > blocks in org.apache.cxf.ws.policy.PolicyEngineImpl, which seem to be there > basically for lazily getting the effective policy once the endpoint is fully > initialized. > I propose to replace those synchronized blocks with (properly implemented) > double-checked locking idiom so that no locking actually happens after > endpoints have been initialized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6738) Reduce contention on org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo
[ https://issues.apache.org/jira/browse/CXF-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119188#comment-15119188 ] ASF GitHub Bot commented on CXF-6738: - Github user asoldano commented on the pull request: https://github.com/apache/cxf/pull/105#issuecomment-175604073 I've applied the changes directly, closing the PR. > Reduce contention on > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo > -- > > Key: CXF-6738 > URL: https://issues.apache.org/jira/browse/CXF-6738 > Project: CXF > Issue Type: Improvement > Components: JAX-WS Runtime >Reporter: Alessio Soldano > > By profiling some benchmark application, > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo has been > found in the contention hotspots. That's because of the multiple synchronized > blocks in org.apache.cxf.ws.policy.PolicyEngineImpl, which seem to be there > basically for lazily getting the effective policy once the endpoint is fully > initialized. > I propose to replace those synchronized blocks with (properly implemented) > double-checked locking idiom so that no locking actually happens after > endpoints have been initialized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6738) Reduce contention on org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo
[ https://issues.apache.org/jira/browse/CXF-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano reassigned CXF-6738: Assignee: Alessio Soldano > Reduce contention on > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo > -- > > Key: CXF-6738 > URL: https://issues.apache.org/jira/browse/CXF-6738 > Project: CXF > Issue Type: Improvement > Components: JAX-WS Runtime >Reporter: Alessio Soldano >Assignee: Alessio Soldano > Fix For: 3.1.5, 3.2.0 > > > By profiling some benchmark application, > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo has been > found in the contention hotspots. That's because of the multiple synchronized > blocks in org.apache.cxf.ws.policy.PolicyEngineImpl, which seem to be there > basically for lazily getting the effective policy once the endpoint is fully > initialized. > I propose to replace those synchronized blocks with (properly implemented) > double-checked locking idiom so that no locking actually happens after > endpoints have been initialized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6738) Reduce contention on org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo
[ https://issues.apache.org/jira/browse/CXF-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated CXF-6738: - Fix Version/s: 3.2.0 3.1.5 > Reduce contention on > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo > -- > > Key: CXF-6738 > URL: https://issues.apache.org/jira/browse/CXF-6738 > Project: CXF > Issue Type: Improvement > Components: JAX-WS Runtime >Reporter: Alessio Soldano >Assignee: Alessio Soldano > Fix For: 3.1.5, 3.2.0 > > > By profiling some benchmark application, > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo has been > found in the contention hotspots. That's because of the multiple synchronized > blocks in org.apache.cxf.ws.policy.PolicyEngineImpl, which seem to be there > basically for lazily getting the effective policy once the endpoint is fully > initialized. > I propose to replace those synchronized blocks with (properly implemented) > double-checked locking idiom so that no locking actually happens after > endpoints have been initialized. -- 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=15119201#comment-15119201
]
Sergey Beryozkin commented on CXF-6740:
---
Hi Aki, sure, the 2nd approach is simpler, I did not realize it can be used
too
So, we still need a fix in Swagger, in addition to what can be done in CXF,
right ?
Thanks, Sergey
> 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
> Attachments: 0001-temporary-work-for-cxf-6740.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)
[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=15119193#comment-15119193
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey,
Okay. Then, we have an approach either using this technique to ensure the
attributes are held TL or using maps Map and Map as the values set in the context and doing the secondary lookup using
the basePath from these maps.
I think the second approach is simpler to manage and besides it does not
unnecessarily contaminate the TL pools, at least for us. How do you think?
A difficult question is whether this approach also works for the issue reporter
of swagger-1482 and also acceptable for the swagger-core team.
regards, aki
> 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
> Attachments: 0001-temporary-work-for-cxf-6740.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)
[jira] [Resolved] (CXF-6738) Reduce contention on org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo
[ https://issues.apache.org/jira/browse/CXF-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano resolved CXF-6738. -- Resolution: Fixed > Reduce contention on > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo > -- > > Key: CXF-6738 > URL: https://issues.apache.org/jira/browse/CXF-6738 > Project: CXF > Issue Type: Improvement > Components: JAX-WS Runtime >Reporter: Alessio Soldano >Assignee: Alessio Soldano > Fix For: 3.1.5, 3.2.0 > > > By profiling some benchmark application, > org.apache.cxf.binding.soap.SoapTransportFactory$SoapEndpointInfo has been > found in the contention hotspots. That's because of the multiple synchronized > blocks in org.apache.cxf.ws.policy.PolicyEngineImpl, which seem to be there > basically for lazily getting the effective policy once the endpoint is fully > initialized. > I propose to replace those synchronized blocks with (properly implemented) > double-checked locking idiom so that no locking actually happens after > endpoints have been initialized. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119222#comment-15119222
]
Sergey Beryozkin commented on CXF-6759:
---
If you have time then yes please do, if not then I will take care of it later
on...
Cheers, Sergey
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6759) WADL2JAVA Tools Generated Source has Duplicate Method Name
[
https://issues.apache.org/jira/browse/CXF-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119226#comment-15119226
]
Neal Hu commented on CXF-6759:
--
Will do it tmr. Thanks.
Neal
> WADL2JAVA Tools Generated Source has Duplicate Method Name
> --
>
> Key: CXF-6759
> URL: https://issues.apache.org/jira/browse/CXF-6759
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS, Tooling
>Affects Versions: 3.0.7, 3.1.4
> Environment: Windows
>Reporter: Neal Hu
> Fix For: 3.1.5, 3.0.8, 3.2.0
>
>
> Generate source using below wadl file contains duplicate method name:
> command: wadl2java.bat -p cxf -d . -impl hello.wadl
> http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>
> http://localhost:9088/Pojo/hello/";>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> /**
> * Created by Apache CXF WadlToJava code generator
> **/
> package cxf;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import javax.ws.rs.Produces;
> @Path("/BasicResource")
> public class BasicResourceResource {
> @GET
> @Produces("application/json")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> @GET
> @Produces("text/plain")
> @Path("/echo")
> public String getEcho() {
> //TODO: implement
> return null;
> }
> }
--
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=15119542#comment-15119542
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey,
Okay. I'll see how that approach will look alike. That will be a minor change
to my previous code.
Yes. and in any case, we would like to have the fix goes into swagger-core
because otherwise we will need to duplicate their ApiListingResource in cxf ;-(
regards, aki
> 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
> Attachments: 0001-temporary-work-for-cxf-6740.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)
[jira] [Commented] (CXF-6758) DataReaderImpl.handleEvent is too strict in case of XMLGregorianCalendar parse error of severity ValidationEvent.ERROR
[
https://issues.apache.org/jira/browse/CXF-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119447#comment-15119447
]
Thorsten Möller commented on CXF-6758:
--
Having visited your link, I agree, the Web service reply is syntactically
incorrect.
Still, what about the different behavior of the reference implementation. I
just like to understand why the reference implementation considers validation
events other than FATAL_ERROR as recoverable and why CXF does not. Is it more a
matter of laziness or superficialness in the reference implementation or is
there a clear reason?
Btw, setting set-jaxb-validation-event-handler to false didn't help much. There
is a new exception now and I'm currently trying to figure out what might be the
reason this time. In case you have an idea, this is the stack trace that I'm
getting now:
{noformat}
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:161)
at com.sun.proxy.$Proxy147.getListModel(Unknown Source)
at
ch.sbi.forte.ws.client.etg.IdentificationServiceImpl.getListModel(IdentificationServiceImpl.java:279)
at
ch.sbi.forte.services.rest.CarInsuranceResource.getListModel(CarInsuranceResource.java:302)
at
ch.sbi.forte.services.rest.CarInsuranceResource$Proxy$_$$_WeldClientProxy.getListModel(Unknown
Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at
org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at
ch.sbi.atlas.servlet.filter.ResponseHeaderFilter.doFilter(ResponseHeaderFilter.java:110)
at
io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
[jira] [Assigned] (CXF-6762) DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries
[ https://issues.apache.org/jira/browse/CXF-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh reassigned CXF-6762: Assignee: Colm O hEigeartaigh > DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries > --- > > Key: CXF-6762 > URL: https://issues.apache.org/jira/browse/CXF-6762 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Transports >Affects Versions: 3.1.4 >Reporter: Chris Ribble >Assignee: Colm O hEigeartaigh >Priority: Minor > Original Estimate: 48h > Remaining Estimate: 48h > > DefaultHostnameVerifier, which is used by default by the JAX-RS ClientBuilder > implementation in CXF (and which cannot be overridden without also overriding > the SSLContext, due to CXF-6761) improperly validates the request hostname > against the DNSName values from the SAN section of a certificate when > matching wildcards. > For example, the following works: > Hostname = my.test.com -> DNSName = *.test.com > But the following does not: > Hostname = 1.my.test.com -> DNSName = *.my.test.com > The reason this fails is that the validation code erroneously assumes (in > multiple places) that wildcards only ever exist on the root domain. > The logic should be improved to allow the wildcard to be used to replace 1 > domain name component or component fragment (comments in the code indicate > that this is its purpose, but it fails at this). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6762) DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries
[ https://issues.apache.org/jira/browse/CXF-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119686#comment-15119686 ] Colm O hEigeartaigh commented on CXF-6762: -- Hi Chris, I've updated the DefaultHostnameVerifier since the 3.1.4 release. Any chance you could build the latest 3.1.5-SNAPSHOT code + see whether it still fails for you? Colm. > DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries > --- > > Key: CXF-6762 > URL: https://issues.apache.org/jira/browse/CXF-6762 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Transports >Affects Versions: 3.1.4 >Reporter: Chris Ribble >Assignee: Colm O hEigeartaigh >Priority: Minor > Original Estimate: 48h > Remaining Estimate: 48h > > DefaultHostnameVerifier, which is used by default by the JAX-RS ClientBuilder > implementation in CXF (and which cannot be overridden without also overriding > the SSLContext, due to CXF-6761) improperly validates the request hostname > against the DNSName values from the SAN section of a certificate when > matching wildcards. > For example, the following works: > Hostname = my.test.com -> DNSName = *.test.com > But the following does not: > Hostname = 1.my.test.com -> DNSName = *.my.test.com > The reason this fails is that the validation code erroneously assumes (in > multiple places) that wildcards only ever exist on the root domain. > The logic should be improved to allow the wildcard to be used to replace 1 > domain name component or component fragment (comments in the code indicate > that this is its purpose, but it fails at this). -- 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=15119692#comment-15119692
]
Akitoshi Yoshida commented on CXF-6740:
---
Hi Sergey, Andriy,
I updated the code along our discussion.
The swagger-core code is in my alt-1482b branch [1] with its diff[2] to its
origin 01-08 version.
And cxf's change is attached [3] in this ticket.
[1] https://github.com/elakito/swagger-core/tree/alt-1482b
[2]
https://github.com/elakito/swagger-core/commit/7bca845dd844efaef4f41c8fdb1918121763fa02
[3] 0001-temporary-work-for-cxf-6740-take-2.patch
regards, aki
> 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
> Attachments: 0001-temporary-work-for-cxf-6740.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)
[jira] [Updated] (CXF-6740) Collision by Swagger2Feature in two OSGI bundles
[
https://issues.apache.org/jira/browse/CXF-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akitoshi Yoshida updated CXF-6740:
--
Attachment: 0001-temporary-work-for-cxf-6740-take-2.patch
> 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
> Attachments: 0001-temporary-work-for-cxf-6740-take-2.patch,
> 0001-temporary-work-for-cxf-6740.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)
[jira] [Updated] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods
[ https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amichai Rothman updated CXF-6737: - Attachment: bad_client_example3.diff updated example with a flag to use jaxb or aegis, and test exception throwing as well. > ClientProxyFactoryBean doesn't work with void methods > - > > Key: CXF-6737 > URL: https://issues.apache.org/jira/browse/CXF-6737 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: DOSGi 1.7.0 >Reporter: Amichai Rothman > Attachments: bad_client_example.diff, bad_client_example.diff, > bad_client_example3.diff > > > I'm trying to use a simple ClientProxyFactoryBean to connect to a > dosgi-exported service. Without specifying the wsdl url, it doesn't work > since apparently the method argument names don't match (arg0 vs actual > parameter name, as explained in CXF-897), so I added the wsdl url. Now > service methods that have a return value seem to work ok, but those with void > return type do not. > Further investigation suggests that the issue might be in > ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning > (no method for op) instead of binding the operation, because > initializeClassInfo returns false, because initializeParameter called with > the return type (near the bottom of initializeClassInfo) returns false, since > o.getOutput().getMessagePart/getMessagePartByIndex return null (since there > are no parts - the method can throw an exception, for which the output > message exists, but there is no actual return type). > A quick test in the debugger shows that if I manipulate the flow manually > (e.g. execute the if caluse in initializeWSDLOperation after > initializeClassInfo returns) then the method invocation works ok. > I am not familiar with the inner workings of WSDL or these classes, so I'm > not sure what is the correct place to apply a fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods
[ https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amichai Rothman updated CXF-6737: - Attachment: fix_void_method.diff added patch with potential fix for the issue. > ClientProxyFactoryBean doesn't work with void methods > - > > Key: CXF-6737 > URL: https://issues.apache.org/jira/browse/CXF-6737 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: DOSGi 1.7.0 >Reporter: Amichai Rothman > Attachments: bad_client_example.diff, bad_client_example.diff, > bad_client_example3.diff, fix_void_method.diff > > > I'm trying to use a simple ClientProxyFactoryBean to connect to a > dosgi-exported service. Without specifying the wsdl url, it doesn't work > since apparently the method argument names don't match (arg0 vs actual > parameter name, as explained in CXF-897), so I added the wsdl url. Now > service methods that have a return value seem to work ok, but those with void > return type do not. > Further investigation suggests that the issue might be in > ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning > (no method for op) instead of binding the operation, because > initializeClassInfo returns false, because initializeParameter called with > the return type (near the bottom of initializeClassInfo) returns false, since > o.getOutput().getMessagePart/getMessagePartByIndex return null (since there > are no parts - the method can throw an exception, for which the output > message exists, but there is no actual return type). > A quick test in the debugger shows that if I manipulate the flow manually > (e.g. execute the if caluse in initializeWSDLOperation after > initializeClassInfo returns) then the method invocation works ok. > I am not familiar with the inner workings of WSDL or these classes, so I'm > not sure what is the correct place to apply a fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6737) ClientProxyFactoryBean doesn't work with void methods
[ https://issues.apache.org/jira/browse/CXF-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119737#comment-15119737 ] Amichai Rothman commented on CXF-6737: -- After applying the patch with the suggested fix, the sample project (example 3) works flawlessly when setting the flag to use jaxb, and when setting it to aegis it works correctly the first time, and gives an exception on subsequent invocations - but the latter seems to be unrelated, perhaps it's triggering CXF-2548. > ClientProxyFactoryBean doesn't work with void methods > - > > Key: CXF-6737 > URL: https://issues.apache.org/jira/browse/CXF-6737 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: DOSGi 1.7.0 >Reporter: Amichai Rothman > Attachments: bad_client_example.diff, bad_client_example.diff, > bad_client_example3.diff, fix_void_method.diff > > > I'm trying to use a simple ClientProxyFactoryBean to connect to a > dosgi-exported service. Without specifying the wsdl url, it doesn't work > since apparently the method argument names don't match (arg0 vs actual > parameter name, as explained in CXF-897), so I added the wsdl url. Now > service methods that have a return value seem to work ok, but those with void > return type do not. > Further investigation suggests that the issue might be in > ReflectionServiceFactoryBean: initializeWSDLOperation prints out a warning > (no method for op) instead of binding the operation, because > initializeClassInfo returns false, because initializeParameter called with > the return type (near the bottom of initializeClassInfo) returns false, since > o.getOutput().getMessagePart/getMessagePartByIndex return null (since there > are no parts - the method can throw an exception, for which the output > message exists, but there is no actual return type). > A quick test in the debugger shows that if I manipulate the flow manually > (e.g. execute the if caluse in initializeWSDLOperation after > initializeClassInfo returns) then the method invocation works ok. > I am not familiar with the inner workings of WSDL or these classes, so I'm > not sure what is the correct place to apply a fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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 XmlSchema
[
https://issues.apache.org/jira/browse/CXF-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119746#comment-15119746
]
Amichai Rothman commented on CXF-2548:
--
I think I just came across the same issue while working on CXF-6737. If you
take the sample project #3 attached there and set the test flag to use Aegis
and then press the Go button twice - you will get this exception:
{quote}
org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in
collection
at org.apache.ws.commons.schema.XmlSchema.(XmlSchema.java:126)
at org.apache.ws.commons.schema.XmlSchema.(XmlSchema.java:140)
at
org.apache.cxf.common.xmlschema.SchemaCollection.newXmlSchemaInCollection(SchemaCollection.java:194)
at
org.apache.cxf.service.model.ServiceInfo.addNewSchema(ServiceInfo.java:165)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.createSchemas(AegisDatabinding.java:450)
at
org.apache.cxf.aegis.databinding.AegisDatabinding.initialize(AegisDatabinding.java:262)
at
org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:423)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:525)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:261)
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:102)
at
org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91)
at
org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:157)
at
org.apache.cxf.dosgi.samples.greeter.client.BadClient.createServiceProxy(BadClient.java:45)
at
org.apache.cxf.dosgi.samples.greeter.client.BadClient.go(BadClient.java:50)
at
org.apache.cxf.dosgi.samples.greeter.client.GreeterDialog$4.actionPerformed(GreeterDialog.java:114)
...
{quote}
(tested with CXF 3.1.1, which is the version used by the latest DOSGi)
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6762) DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries
[ https://issues.apache.org/jira/browse/CXF-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120525#comment-15120525 ] Chris Ribble commented on CXF-6762: --- I added 3.1.5-SNAPSHOT to my test cases's gradle build and verified that the issue does *not* happen: I no longer need to define a custom DefaultHostnameVerifier instance to be able to validate non-root wildcard hosts! Thanks! > DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries > --- > > Key: CXF-6762 > URL: https://issues.apache.org/jira/browse/CXF-6762 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Transports >Affects Versions: 3.1.4 >Reporter: Chris Ribble >Assignee: Colm O hEigeartaigh >Priority: Minor > Original Estimate: 48h > Remaining Estimate: 48h > > DefaultHostnameVerifier, which is used by default by the JAX-RS ClientBuilder > implementation in CXF (and which cannot be overridden without also overriding > the SSLContext, due to CXF-6761) improperly validates the request hostname > against the DNSName values from the SAN section of a certificate when > matching wildcards. > For example, the following works: > Hostname = my.test.com -> DNSName = *.test.com > But the following does not: > Hostname = 1.my.test.com -> DNSName = *.my.test.com > The reason this fails is that the validation code erroneously assumes (in > multiple places) that wildcards only ever exist on the root domain. > The logic should be improved to allow the wildcard to be used to replace 1 > domain name component or component fragment (comments in the code indicate > that this is its purpose, but it fails at this). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6762) DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries
[ https://issues.apache.org/jira/browse/CXF-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Ribble resolved CXF-6762. --- Resolution: Fixed Fix Version/s: 3.1.5 > DefaultHostnameVerifier fails for non-root wildcard SAN DNSName entries > --- > > Key: CXF-6762 > URL: https://issues.apache.org/jira/browse/CXF-6762 > Project: CXF > Issue Type: Bug > Components: JAX-RS, Transports >Affects Versions: 3.1.4 >Reporter: Chris Ribble >Assignee: Colm O hEigeartaigh >Priority: Minor > Fix For: 3.1.5 > > Original Estimate: 48h > Remaining Estimate: 48h > > DefaultHostnameVerifier, which is used by default by the JAX-RS ClientBuilder > implementation in CXF (and which cannot be overridden without also overriding > the SSLContext, due to CXF-6761) improperly validates the request hostname > against the DNSName values from the SAN section of a certificate when > matching wildcards. > For example, the following works: > Hostname = my.test.com -> DNSName = *.test.com > But the following does not: > Hostname = 1.my.test.com -> DNSName = *.my.test.com > The reason this fails is that the validation code erroneously assumes (in > multiple places) that wildcards only ever exist on the root domain. > The logic should be improved to allow the wildcard to be used to replace 1 > domain name component or component fragment (comments in the code indicate > that this is its purpose, but it fails at this). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6764) Should add RI JAXB Namespacemapper support
Neal Hu created CXF-6764:
Summary: Should add RI JAXB Namespacemapper support
Key: CXF-6764
URL: https://issues.apache.org/jira/browse/CXF-6764
Project: CXF
Issue Type: Bug
Components: Core, JAX-RS
Affects Versions: 3.1.4, 3.0.7
Environment: Windows
Reporter: Neal Hu
Fix For: 3.1.5, 3.0.8, 3.2.0
/cxf-core/src/main/java/org/apache/cxf/common/jaxb/JAXBUtils.java:1097
if (cls == null
&& (mcls.getName().contains(".internal.") ||
mcls.getName().contains("com.sun"))) {
try {
cls =
ClassLoaderUtils.loadClass("org.apache.cxf.common.jaxb.NamespaceMapper",
JAXBUtils.class);
} catch (ClassNotFoundException ex2) {
// ignore
}
}
CXF only add org.apache.cxf.common.jaxb.NamespaceMapper which extends
com.sun.xml.bind.marshaller.NamespacePrefixMapper, but the RI JAXB need a
mapper extends com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper
So when we add namespace mapper in JAXBElementProvider subclass, the RI JAXB
cann't add the namespace mapping correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
