[jira] [Created] (CXF-7008) Regression: CXF-5788 - JMS replyToDestination doesn't work
Tadayoshi Sato created CXF-7008:
---
Summary: Regression: CXF-5788 - JMS replyToDestination doesn't work
Key: CXF-7008
URL: https://issues.apache.org/jira/browse/CXF-7008
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 3.1.7
Reporter: Tadayoshi Sato
Fix for CXF-5788 is not applied to CXF 3.x branches. According to the source
code of
[JMSConfiguration|https://github.com/apache/cxf/blob/cxf-3.1.7/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java]:
{code:java}
/**
* Destination name to listen on for reply messages
*/
private String replyDestination;
[...]
/**
* Destination name to send out as replyTo address in the message
*/
private String replyToDestination;
{code}
so in client side if we set {{replyDestination}} to {{queue1}} but
{{replyToDestination}} to {{queue2}} on {{JMSConfiguration}}, we expect that
the request message has header {{JMSReplyTo="queue2"}} but the client listens
on {{queue1}} for a reply. It works as expected on CXF 2.7.18, but starts not
to work since 3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7008) Regression: CXF-5788 - JMS replyToDestination doesn't work
[
https://issues.apache.org/jira/browse/CXF-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418486#comment-15418486
]
ASF GitHub Bot commented on CXF-7008:
-
GitHub user tadayosi opened a pull request:
https://github.com/apache/cxf/pull/156
[CXF-7008] Regression: CXF-5788 - JMS replyToDestination doesn't work
See https://issues.apache.org/jira/browse/CXF-7008
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tadayosi/cxf CXF-7008
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cxf/pull/156.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #156
commit 0f51e22bc7e13630aeac1996fba4d06e97dea37c
Author: Tadayoshi Sato
Date: 2016-08-12T07:06:48Z
[CXF-7008] Regression: CXF-5788 - JMS replyToDestination doesn't work
> Regression: CXF-5788 - JMS replyToDestination doesn't work
> --
>
> Key: CXF-7008
> URL: https://issues.apache.org/jira/browse/CXF-7008
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.1.7
>Reporter: Tadayoshi Sato
>
> Fix for CXF-5788 is not applied to CXF 3.x branches. According to the source
> code of
> [JMSConfiguration|https://github.com/apache/cxf/blob/cxf-3.1.7/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java]:
> {code:java}
> /**
> * Destination name to listen on for reply messages
> */
> private String replyDestination;
> [...]
> /**
> * Destination name to send out as replyTo address in the message
> */
> private String replyToDestination;
> {code}
> so in client side if we set {{replyDestination}} to {{queue1}} but
> {{replyToDestination}} to {{queue2}} on {{JMSConfiguration}}, we expect that
> the request message has header {{JMSReplyTo="queue2"}} but the client listens
> on {{queue1}} for a reply. It works as expected on CXF 2.7.18, but starts not
> to work since 3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CXF-7008) Regression: CXF-5788 - JMS replyToDestination doesn't work
[
https://issues.apache.org/jira/browse/CXF-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-7008:
-
Assignee: Freeman Fang
> Regression: CXF-5788 - JMS replyToDestination doesn't work
> --
>
> Key: CXF-7008
> URL: https://issues.apache.org/jira/browse/CXF-7008
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.1.7
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
>
> Fix for CXF-5788 is not applied to CXF 3.x branches. According to the source
> code of
> [JMSConfiguration|https://github.com/apache/cxf/blob/cxf-3.1.7/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java]:
> {code:java}
> /**
> * Destination name to listen on for reply messages
> */
> private String replyDestination;
> [...]
> /**
> * Destination name to send out as replyTo address in the message
> */
> private String replyToDestination;
> {code}
> so in client side if we set {{replyDestination}} to {{queue1}} but
> {{replyToDestination}} to {{queue2}} on {{JMSConfiguration}}, we expect that
> the request message has header {{JMSReplyTo="queue2"}} but the client listens
> on {{queue1}} for a reply. It works as expected on CXF 2.7.18, but starts not
> to work since 3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7008) Regression: CXF-5788 - JMS replyToDestination doesn't work
[
https://issues.apache.org/jira/browse/CXF-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418555#comment-15418555
]
ASF GitHub Bot commented on CXF-7008:
-
Github user asfgit closed the pull request at:
https://github.com/apache/cxf/pull/156
> Regression: CXF-5788 - JMS replyToDestination doesn't work
> --
>
> Key: CXF-7008
> URL: https://issues.apache.org/jira/browse/CXF-7008
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.1.7
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
>
> Fix for CXF-5788 is not applied to CXF 3.x branches. According to the source
> code of
> [JMSConfiguration|https://github.com/apache/cxf/blob/cxf-3.1.7/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java]:
> {code:java}
> /**
> * Destination name to listen on for reply messages
> */
> private String replyDestination;
> [...]
> /**
> * Destination name to send out as replyTo address in the message
> */
> private String replyToDestination;
> {code}
> so in client side if we set {{replyDestination}} to {{queue1}} but
> {{replyToDestination}} to {{queue2}} on {{JMSConfiguration}}, we expect that
> the request message has header {{JMSReplyTo="queue2"}} but the client listens
> on {{queue1}} for a reply. It works as expected on CXF 2.7.18, but starts not
> to work since 3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FEDIZ-160) Replace Hibernate with Apache BVal
[ https://issues.apache.org/jira/browse/FEDIZ-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-160. - > Replace Hibernate with Apache BVal > -- > > Key: FEDIZ-160 > URL: https://issues.apache.org/jira/browse/FEDIZ-160 > Project: CXF-Fediz > Issue Type: Improvement >Affects Versions: 1.3.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > > As part of FEDIZ-122 (https://issues.apache.org/jira/browse/FEDIZ-122), > Apache BVal was replaced with Hibernate as part of the update to use Spring > 4. However, with a new BVal release out, we can go back to using it rather > than Hibernate for bean validation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-165) SAML SSO redirection on ForceAuthn or token expiry not working
[ https://issues.apache.org/jira/browse/FEDIZ-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-165. - > SAML SSO redirection on ForceAuthn or token expiry not working > -- > > Key: FEDIZ-165 > URL: https://issues.apache.org/jira/browse/FEDIZ-165 > Project: CXF-Fediz > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > > SAML SSO redirection on ForceAuthn or token expiry is not working -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-168) Support SAML Token without Audience Restriction
[ https://issues.apache.org/jira/browse/FEDIZ-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-168. - > Support SAML Token without Audience Restriction > --- > > Key: FEDIZ-168 > URL: https://issues.apache.org/jira/browse/FEDIZ-168 > Project: CXF-Fediz > Issue Type: Improvement > Components: IDP, Plugin >Affects Versions: 1.3.0, 1.2.2 >Reporter: Jan Bernhardt >Assignee: Jan Bernhardt > Fix For: 1.2.3, 1.3.1 > > > Currently Fediz only supports SAML with an audience restriction. However the > standard only requires audience restriction validation if this value is > present within the SAML token. If no audience restriction is set, this token > should be valid for any service. > Especially in cases when the Login SAML token should be used to login to a > webpage and the same token can be used to authenticate the user against > backend services, an audience restriction could be disturbing. > Fediz Plugin should accept SAML token without audience restrictions as valid > (if all other security requirements are met) and the Fediz IDP should be > configurable to request SAML token from the STS without audience restrictions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-163) Default to disabling Deflate Encoding for the SAML SSO response
[ https://issues.apache.org/jira/browse/FEDIZ-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-163. - > Default to disabling Deflate Encoding for the SAML SSO response > --- > > Key: FEDIZ-163 > URL: https://issues.apache.org/jira/browse/FEDIZ-163 > Project: CXF-Fediz > Issue Type: Improvement >Affects Versions: 1.3.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > > In 1.3.0, the deflate encoding is used by default to encode SAML SSO > Responses. However, the default web flow is to POST the response, and the > deflate encoding is not supposed to be used here according to the spec. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-166) "No message body writer" error for OAuthError in the OIDC IdP
[
https://issues.apache.org/jira/browse/FEDIZ-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh closed FEDIZ-166.
-
> "No message body writer" error for OAuthError in the OIDC IdP
> -
>
> Key: FEDIZ-166
> URL: https://issues.apache.org/jira/browse/FEDIZ-166
> Project: CXF-Fediz
> Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.3.1
>
>
> When an OAuthError is thrown in the Fediz OIDC IdP, such as for example the
> client request redirect URI does not match the stored value, the following
> exception is thrown (latest 1.3.1-SNAPSHOT code):
> ---
> ID: 5
> Response-Code: 500
> Content-Type: text/plain
> Headers: {Content-Type=[application/json], Date=[Tue, 24 May 2016 10:22:56
> GMT]}
> Payload: No message body writer has been found for class
> org.apache.cxf.rs.security.oauth2.common.OAuthError, ContentType:
> application/json
> --
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FEDIZ-161) FederationConfigImpl.init() calls loadConfig(File) which fails for war files with special characters in its name
[ https://issues.apache.org/jira/browse/FEDIZ-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-161. - > FederationConfigImpl.init() calls loadConfig(File) which fails for war files > with special characters in its name > > > Key: FEDIZ-161 > URL: https://issues.apache.org/jira/browse/FEDIZ-161 > Project: CXF-Fediz > Issue Type: Bug > Components: Plugin >Affects Versions: 1.2.2 >Reporter: Marc Calello >Assignee: Colm O hEigeartaigh > Fix For: 1.2.3, 1.3.1 > > > If the fediz_config.xml file resides within a war file with special > characters in its name, like the hash (#) character, used in Tomcat's war > naming convention, (e.g., example-app##1.0.1.war), the following exception is > thrown at startup: > java.io.FileNotFoundException: The system cannot find the file specified > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:221) > at > com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:190) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:162) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:171) > at > javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:189) > at > org.apache.cxf.fediz.core.config.FedizConfigurator.loadConfig(FedizConfigurator.java:43) > at > org.apache.cxf.fediz.spring.FederationConfigImpl.init(FederationConfigImpl.java:65) > This is related to a known issue with the JAXB UnmarshallerImpl: > https://community.oracle.com/thread/1626574?start=0&tstart=0 > This could be resolved by changing the following line in the loadConfig(File) > method to implement the suggestion from the Oracle thread above from: > rootConfig = (FedizConfig) getJaxbContext().createUnmarshaller().unmarshal(f); > to: > rootConfig = (FedizConfig) > getJaxbContext().createUnmarshaller().unmarshal(new FileInputStream(f)); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-76) Support Facebook Login for Trusted IDP
[ https://issues.apache.org/jira/browse/FEDIZ-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-76. > Support Facebook Login for Trusted IDP > -- > > Key: FEDIZ-76 > URL: https://issues.apache.org/jira/browse/FEDIZ-76 > Project: CXF-Fediz > Issue Type: New Feature > Components: IDP >Affects Versions: 1.1.0 >Reporter: Oliver Wulff >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-162) Make it possible to disable the requirement for a Signature when validating a SAML SSO AuthnRequest in the IdP
[ https://issues.apache.org/jira/browse/FEDIZ-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-162. - > Make it possible to disable the requirement for a Signature when validating a > SAML SSO AuthnRequest in the IdP > -- > > Key: FEDIZ-162 > URL: https://issues.apache.org/jira/browse/FEDIZ-162 > Project: CXF-Fediz > Issue Type: Improvement >Affects Versions: 1.3.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > > Make it possible to disable the requirement for a Signature when validating a > SAML SSO AuthnRequest in the IdP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-170) Load keystore/truststore resources in the container plugins
[ https://issues.apache.org/jira/browse/FEDIZ-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-170. - > Load keystore/truststore resources in the container plugins > --- > > Key: FEDIZ-170 > URL: https://issues.apache.org/jira/browse/FEDIZ-170 > Project: CXF-Fediz > Issue Type: Bug >Affects Versions: 1.3.0, 1.2.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.2.3, 1.3.1 > > > As well as loading a "file" for keystore/truststores, it's possible to use a > "resource" instead in the Fediz container plugin configuration. However, > "resource" isn't working. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-169) Enforce mandatory requested claims on the RP side
[ https://issues.apache.org/jira/browse/FEDIZ-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-169. - > Enforce mandatory requested claims on the RP side > - > > Key: FEDIZ-169 > URL: https://issues.apache.org/jira/browse/FEDIZ-169 > Project: CXF-Fediz > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.2.3, 1.3.1 > > > The RP configuration contains a list of Claims, which can be optional or > mandatory. However, the plugins don't currently enforce that mandatory claims > are present in the received token. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-164) IdP default flow doesn't support multiple realms
[ https://issues.apache.org/jira/browse/FEDIZ-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-164. - > IdP default flow doesn't support multiple realms > > > Key: FEDIZ-164 > URL: https://issues.apache.org/jira/browse/FEDIZ-164 > Project: CXF-Fediz > Issue Type: Bug >Affects Versions: 1.3.0, 1.2.2 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.2.3, 1.3.1 > > > The default webflow for WS-Federation (or SAML SSO in 1.3.0) in the IdP > doesn't support multiple realms as it just takes the first IDP config that is > available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-171) Add a configuration option to add the "Authenticated" role to the list of roles of the authenticated user
[ https://issues.apache.org/jira/browse/FEDIZ-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-171. - > Add a configuration option to add the "Authenticated" role to the list of > roles of the authenticated user > - > > Key: FEDIZ-171 > URL: https://issues.apache.org/jira/browse/FEDIZ-171 > Project: CXF-Fediz > Issue Type: Improvement >Affects Versions: 1.3.0 >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > > To make the Fediz container plugins work, it's necessary to specify a role > name in the web.xml configuration. However, it may be the case that you don't > care about authorization, only authentication. In that case, you will need to > configure all the roles in web.xml that match the roles of the authenticated > user. > This task is to add a new configuration parameter which will add the > "Authenticated" role to all authenticated users, so it's easy just to specify > the "Authenticated" role in the web.xml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FEDIZ-172) OIDC DataProvider should support client_credentials clients
[ https://issues.apache.org/jira/browse/FEDIZ-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh closed FEDIZ-172. - > OIDC DataProvider should support client_credentials clients > > > Key: FEDIZ-172 > URL: https://issues.apache.org/jira/browse/FEDIZ-172 > Project: CXF-Fediz > Issue Type: Improvement > Components: OIDC >Reporter: Sergey Beryozkin >Assignee: Colm O hEigeartaigh > Fix For: 1.3.1 > > > OAuth2 Client Credentials (https://tools.ietf.org/html/rfc6749#section-4.4) > is a simplest way for OAuth2 machine clients to request the access token. > For example, instead of the machine client authenticating with STS first and > then using the received assertion to authenticate against OAuth2 > AccessTokenService and use client_credentials to get an access token it is > much simpler for such a client to simply authenticate directly with the > AccessTokenService: > https://tools.ietf.org/html/rfc6749#section-4.4.2 > In this case the step involving the client authenticating with STS will be > done by AccessTokenService. > Both approaches are equivalent but the latter is simpler for the client and > makes the client code OAuth2-portable. > Note the data provider will already support such clients if they have been > pre-registered. However, pre-registering the clients to support their > authentication in cases when their data already exist in Syncope, LDAP, etc, > can be unrealistic -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7008) Regression: CXF-5788 - JMS replyToDestination doesn't work
[
https://issues.apache.org/jira/browse/CXF-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-7008.
---
Resolution: Fixed
Fix Version/s: 3.0.11
3.1.8
3.2.0
patch applied on behalf of Tadayoshi Sato with thanks
> Regression: CXF-5788 - JMS replyToDestination doesn't work
> --
>
> Key: CXF-7008
> URL: https://issues.apache.org/jira/browse/CXF-7008
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.1.7
>Reporter: Tadayoshi Sato
>Assignee: Freeman Fang
> Fix For: 3.2.0, 3.1.8, 3.0.11
>
>
> Fix for CXF-5788 is not applied to CXF 3.x branches. According to the source
> code of
> [JMSConfiguration|https://github.com/apache/cxf/blob/cxf-3.1.7/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConfiguration.java]:
> {code:java}
> /**
> * Destination name to listen on for reply messages
> */
> private String replyDestination;
> [...]
> /**
> * Destination name to send out as replyTo address in the message
> */
> private String replyToDestination;
> {code}
> so in client side if we set {{replyDestination}} to {{queue1}} but
> {{replyToDestination}} to {{queue2}} on {{JMSConfiguration}}, we expect that
> the request message has header {{JMSReplyTo="queue2"}} but the client listens
> on {{queue1}} for a reply. It works as expected on CXF 2.7.18, but starts not
> to work since 3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7007) Allow customizing atmosphere's config parameters when using websocket transport
[ https://issues.apache.org/jira/browse/CXF-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418594#comment-15418594 ] Jean-Philippe CLEMENT commented on CXF-7007: If the client WebSocket sends the binaryType in the request (header?) then it might dynamically be used in CXF, rather than a static server configuration. If the binaryType is not sent by the browser WebSocket then that option could be sent as extra request header in the request. For instance: ws://host:port/cxf/some/sample/r/norg.atmosphere.websocket.binaryWrite=true or ws://host:port/cxf/some/sample/r/nmode=binary or - if that makes sense ws://host:port/cxf/some/sample/r/nmode=blob ws://host:port/cxf/some/sample/r/nmode=arraybuffer > Allow customizing atmosphere's config parameters when using websocket > transport > --- > > Key: CXF-7007 > URL: https://issues.apache.org/jira/browse/CXF-7007 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Akitoshi Yoshida > > The atmosphere framework in CXF is currently set up with some predefined > options and there is no way to change this setting except customizing its > protocol interceptor. To be able to customize the behavior of websocket > processing, those options to be made configurable, possibly using a specific > Feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7007) Allow customizing atmosphere's config parameters when using websocket transport
[ https://issues.apache.org/jira/browse/CXF-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418594#comment-15418594 ] Jean-Philippe CLEMENT edited comment on CXF-7007 at 8/12/16 9:46 AM: - If the client WebSocket sends the binaryType in the request (header?) then it might dynamically be used in CXF, rather than a static server configuration. If the binaryType is not sent by the browser WebSocket then that option could be sent as extra request header. For instance: ws://host:port/cxf/some/sample/r/norg.atmosphere.websocket.binaryWrite=true or ws://host:port/cxf/some/sample/r/nmode=binary or - if that makes sense ws://host:port/cxf/some/sample/r/nmode=blob ws://host:port/cxf/some/sample/r/nmode=arraybuffer was (Author: jeanphi): If the client WebSocket sends the binaryType in the request (header?) then it might dynamically be used in CXF, rather than a static server configuration. If the binaryType is not sent by the browser WebSocket then that option could be sent as extra request header in the request. For instance: ws://host:port/cxf/some/sample/r/norg.atmosphere.websocket.binaryWrite=true or ws://host:port/cxf/some/sample/r/nmode=binary or - if that makes sense ws://host:port/cxf/some/sample/r/nmode=blob ws://host:port/cxf/some/sample/r/nmode=arraybuffer > Allow customizing atmosphere's config parameters when using websocket > transport > --- > > Key: CXF-7007 > URL: https://issues.apache.org/jira/browse/CXF-7007 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Akitoshi Yoshida > > The atmosphere framework in CXF is currently set up with some predefined > options and there is no way to change this setting except customizing its > protocol interceptor. To be able to customize the behavior of websocket > processing, those options to be made configurable, possibly using a specific > Feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6524) Swagger 2 feature doesn't work with blueprint endpoints
[
https://issues.apache.org/jira/browse/CXF-6524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418605#comment-15418605
]
Łukasz Dywicki commented on CXF-6524:
-
Sorry for one year delay :-) - yes I added feature at bus level, not endpoint.
With endpoint swagger feature works fine.
> Swagger 2 feature doesn't work with blueprint endpoints
> ---
>
> Key: CXF-6524
> URL: https://issues.apache.org/jira/browse/CXF-6524
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Łukasz Dywicki
>Assignee: Akitoshi Yoshida
> Fix For: 3.1.3, 3.0.7
>
>
> Swagger2 feature is not working with standard blueprint endpoints. Attaching
> of feature fails cause
> {{org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature#initialize(Server,
> Bus)}} method never gets called in this environment. What is being called is
> {{initializeProvider(InterceptorProvider, Bus)}} method which is not
> overriden by AbstractSwaggerFeature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7009) Swagger feature ignore interfaces under OSGi
Łukasz Dywicki created CXF-7009:
---
Summary: Swagger feature ignore interfaces under OSGi
Key: CXF-7009
URL: https://issues.apache.org/jira/browse/CXF-7009
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.7
Environment: Karaf 4.0.5
Reporter: Łukasz Dywicki
When more advanced structuring in project is used cxf swagger intergration
fails to generate proper swagger service descriptor (while it still works for
wadl).
For example:
{code:lang=java|title=SampleResource.java}
package org.code_house.swagger.example.api;
@Api
@Path("/test")
public interface SampleResource {
@GET
@ApiOperation("Something to do")
String getSomething();
}
{code}
{code:lang=java|title=DefaultSampleResource.java}
package org.code_house.swagger.example.core.internal;
import org.code_house.swagger.example.api.SampleResource;
public class DefaultSampleResource implements SampleResource {
public String getSomething() {
return "aaa";
}
}
{code}
Works properly, however there is no way to get Swagger2 feature picking this
up. From my analysis it seems that default package calculation uses just
package names of resources defined in class (impl classes) and ignores
implemented interfaces.
Passing a valid package name which contains interfaces is not working as well
because it resources are not visible from implementation bundle. This is side
effect of the Swagger resource scanning logic where it query classloader for
resources. This gets forwarded to CXF's BundleDelegatingClassLoader and then to
bundle which is not aware of any resources from packages different than it's
own.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7009) Swagger feature ignore interfaces under OSGi
[
https://issues.apache.org/jira/browse/CXF-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Łukasz Dywicki updated CXF-7009:
Description:
When more advanced structuring in project is used cxf swagger intergration
fails to generate proper swagger service descriptor (while it still works for
wadl).
For example:
{code:lang=java|title=SampleResource.java}
package org.code_house.swagger.example.api;
@Api
@Path("/test")
public interface SampleResource {
@GET
@ApiOperation("Something to do")
String getSomething();
}
{code}
{code:lang=java|title=DefaultSampleResource.java}
package org.code_house.swagger.example.core.internal;
import org.code_house.swagger.example.api.SampleResource;
public class DefaultSampleResource implements SampleResource {
public String getSomething() {
return "aaa";
}
}
{code}
Works properly, however there is no way to get Swagger2 feature picking this
up. From my analysis it seems that default package calculation uses just
package names of resources defined in class (impl classes) and ignores
implemented interfaces.
Passing to Swagger2Feature an valid package name which contains interfaces is
not working as well because it resources are not visible from implementation
bundle. This is side effect of the Swagger resource scanning logic where it
query classloader for resources. This gets forwarded to CXF's
BundleDelegatingClassLoader and then to bundle which is not aware of any
resources from packages different than it's own.
was:
When more advanced structuring in project is used cxf swagger intergration
fails to generate proper swagger service descriptor (while it still works for
wadl).
For example:
{code:lang=java|title=SampleResource.java}
package org.code_house.swagger.example.api;
@Api
@Path("/test")
public interface SampleResource {
@GET
@ApiOperation("Something to do")
String getSomething();
}
{code}
{code:lang=java|title=DefaultSampleResource.java}
package org.code_house.swagger.example.core.internal;
import org.code_house.swagger.example.api.SampleResource;
public class DefaultSampleResource implements SampleResource {
public String getSomething() {
return "aaa";
}
}
{code}
Works properly, however there is no way to get Swagger2 feature picking this
up. From my analysis it seems that default package calculation uses just
package names of resources defined in class (impl classes) and ignores
implemented interfaces.
Passing a valid package name which contains interfaces is not working as well
because it resources are not visible from implementation bundle. This is side
effect of the Swagger resource scanning logic where it query classloader for
resources. This gets forwarded to CXF's BundleDelegatingClassLoader and then to
bundle which is not aware of any resources from packages different than it's
own.
> Swagger feature ignore interfaces under OSGi
>
>
> Key: CXF-7009
> URL: https://issues.apache.org/jira/browse/CXF-7009
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Karaf 4.0.5
>Reporter: Łukasz Dywicki
>
> When more advanced structuring in project is used cxf swagger intergration
> fails to generate proper swagger service descriptor (while it still works for
> wadl).
> For example:
> {code:lang=java|title=SampleResource.java}
> package org.code_house.swagger.example.api;
> @Api
> @Path("/test")
> public interface SampleResource {
> @GET
> @ApiOperation("Something to do")
> String getSomething();
> }
> {code}
> {code:lang=java|title=DefaultSampleResource.java}
> package org.code_house.swagger.example.core.internal;
> import org.code_house.swagger.example.api.SampleResource;
> public class DefaultSampleResource implements SampleResource {
> public String getSomething() {
> return "aaa";
> }
> }
> {code}
> Works properly, however there is no way to get Swagger2 feature picking this
> up. From my analysis it seems that default package calculation uses just
> package names of resources defined in class (impl classes) and ignores
> implemented interfaces.
> Passing to Swagger2Feature an valid package name which contains interfaces is
> not working as well because it resources are not visible from implementation
> bundle. This is side effect of the Swagger resource scanning logic where it
> query classloader for resources. This gets forwarded to CXF's
> BundleDelegatingClassLoader and then to bundle which is not aware of any
> resources from packages different than it's own.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7009) Swagger feature ignore interfaces under OSGi
[
https://issues.apache.org/jira/browse/CXF-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418706#comment-15418706
]
Sergey Beryozkin commented on CXF-7009:
---
Hey Łukasz,
So is it correct, based on your analysis, that even if Swagger2Feature does
some extra work on calculating the resource packages, it will still not work
under OSGI ? I guess it does not matter if Swagger2Feature itself calculates it
or it is passed as a set as a Swagger2Feature property
Thanks, Sergey
> Swagger feature ignore interfaces under OSGi
>
>
> Key: CXF-7009
> URL: https://issues.apache.org/jira/browse/CXF-7009
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Karaf 4.0.5
>Reporter: Łukasz Dywicki
>
> When more advanced structuring in project is used cxf swagger intergration
> fails to generate proper swagger service descriptor (while it still works for
> wadl).
> For example:
> {code:lang=java|title=SampleResource.java}
> package org.code_house.swagger.example.api;
> @Api
> @Path("/test")
> public interface SampleResource {
> @GET
> @ApiOperation("Something to do")
> String getSomething();
> }
> {code}
> {code:lang=java|title=DefaultSampleResource.java}
> package org.code_house.swagger.example.core.internal;
> import org.code_house.swagger.example.api.SampleResource;
> public class DefaultSampleResource implements SampleResource {
> public String getSomething() {
> return "aaa";
> }
> }
> {code}
> Works properly, however there is no way to get Swagger2 feature picking this
> up. From my analysis it seems that default package calculation uses just
> package names of resources defined in class (impl classes) and ignores
> implemented interfaces.
> Passing to Swagger2Feature an valid package name which contains interfaces is
> not working as well because it resources are not visible from implementation
> bundle. This is side effect of the Swagger resource scanning logic where it
> query classloader for resources. This gets forwarded to CXF's
> BundleDelegatingClassLoader and then to bundle which is not aware of any
> resources from packages different than it's own.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7009) Swagger feature ignore interfaces under OSGi
[
https://issues.apache.org/jira/browse/CXF-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-7009.
---
Resolution: Duplicate
Resolving it as Duplicate of CXF-6904 as agreed with Lukasz
> Swagger feature ignore interfaces under OSGi
>
>
> Key: CXF-7009
> URL: https://issues.apache.org/jira/browse/CXF-7009
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.7
> Environment: Karaf 4.0.5
>Reporter: Łukasz Dywicki
>
> When more advanced structuring in project is used cxf swagger intergration
> fails to generate proper swagger service descriptor (while it still works for
> wadl).
> For example:
> {code:lang=java|title=SampleResource.java}
> package org.code_house.swagger.example.api;
> @Api
> @Path("/test")
> public interface SampleResource {
> @GET
> @ApiOperation("Something to do")
> String getSomething();
> }
> {code}
> {code:lang=java|title=DefaultSampleResource.java}
> package org.code_house.swagger.example.core.internal;
> import org.code_house.swagger.example.api.SampleResource;
> public class DefaultSampleResource implements SampleResource {
> public String getSomething() {
> return "aaa";
> }
> }
> {code}
> Works properly, however there is no way to get Swagger2 feature picking this
> up. From my analysis it seems that default package calculation uses just
> package names of resources defined in class (impl classes) and ignores
> implemented interfaces.
> Passing to Swagger2Feature an valid package name which contains interfaces is
> not working as well because it resources are not visible from implementation
> bundle. This is side effect of the Swagger resource scanning logic where it
> query classloader for resources. This gets forwarded to CXF's
> BundleDelegatingClassLoader and then to bundle which is not aware of any
> resources from packages different than it's own.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418742#comment-15418742 ] Sergey Beryozkin commented on CXF-6904: --- Łukasz has found an interesting workaround for this case. He has written the code that collects all the JAX-RS classes (from CXF ClassResourceInfo) and sets them on a Swagger instance: https://github.com/Code-House/karaf-swagger/blob/master/core/src/main/java/org/code_house/swagger/core/internal/SwaggerHolder.java#L45 and then he has extended the ApiListingResource: https://github.com/Code-House/karaf-swagger/blob/master/core/src/main/java/org/code_house/swagger/core/internal/EnhancedApiListingResource.java thus bypassing the Swagger scanning completely. > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7010) Swagger2Feature can not auto-link to SwaggerUi in OSGI
Sergey Beryozkin created CXF-7010: - Summary: Swagger2Feature can not auto-link to SwaggerUi in OSGI Key: CXF-7010 URL: https://issues.apache.org/jira/browse/CXF-7010 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.1.7 Reporter: Sergey Beryozkin Fix For: 3.2.0, 3.1.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6692) Update AbstractOAuthDataProvider to support JWT access tokens
[ https://issues.apache.org/jira/browse/CXF-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6692. --- Resolution: Fixed > Update AbstractOAuthDataProvider to support JWT access tokens > - > > Key: CXF-6692 > URL: https://issues.apache.org/jira/browse/CXF-6692 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8 > > > CXF already ships DefaultEncryptingOAuthProvider which can be used by the > servers to avoid storing the OAuth2 model, it uses a custom seriallization > format. It makes sense to offer a provider which uses a JWT token as a > properties container before encrypting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6909) Create an JCache based OAuthDataProvider
[ https://issues.apache.org/jira/browse/CXF-6909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15418954#comment-15418954 ] Sergey Beryozkin commented on CXF-6909: --- Please note that as part of https://issues.apache.org/jira/browse/CXF-6692 I've updated this provider to optionally support storing only JOSE (JWS or JWE) String representations of access tokens, as part of this work I've also updated the default config URL (was ending with ehcache3). Have a look please at the code, any concerns - let me know please > Create an JCache based OAuthDataProvider > > > Key: CXF-6909 > URL: https://issues.apache.org/jira/browse/CXF-6909 > Project: CXF > Issue Type: New Feature > Components: JAX-RS Security >Reporter: Luca Burgazzoli >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.1.7, 3.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CXF-6989) Content Disposition does not handle "=" in filename
[ https://issues.apache.org/jira/browse/CXF-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin reopened CXF-6989: --- > Content Disposition does not handle "=" in filename > --- > > Key: CXF-6989 > URL: https://issues.apache.org/jira/browse/CXF-6989 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: Kevin Osborn > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6989) Content Disposition does not handle "=" in filename
[ https://issues.apache.org/jira/browse/CXF-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6989. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.0.11 3.1.8 3.2.0 Hi Kevin, I updated the code to handle it, it is likely to be a tiny bit faster, without really complicating it. I agree that doing some more involved matching would be problematic. If you can see an opportunity for CXF ContentDisposition code be improved further to handle some other edge cases then please let us know, thanks > Content Disposition does not handle "=" in filename > --- > > Key: CXF-6989 > URL: https://issues.apache.org/jira/browse/CXF-6989 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: Kevin Osborn >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8, 3.0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (DOSGI-249) Redesign examples
Christian Schneider created DOSGI-249: - Summary: Redesign examples Key: DOSGI-249 URL: https://issues.apache.org/jira/browse/DOSGI-249 Project: CXF Distributed OSGi Issue Type: Improvement Components: Samples Affects Versions: 1.9.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 2.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6989) Content Disposition does not handle "=" in filename
[ https://issues.apache.org/jira/browse/CXF-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419146#comment-15419146 ] Kevin Osborn commented on CXF-6989: --- Your changes look good. And there are a ton of edge cases. This is a really good resource: http://greenbytes.de/tech/tc2231/#attwithfilenameandextparamescaped As you can see, there are a lot of test cases and even most browser miss a lot of cases. > Content Disposition does not handle "=" in filename > --- > > Key: CXF-6989 > URL: https://issues.apache.org/jira/browse/CXF-6989 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: Kevin Osborn >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8, 3.0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6989) Content Disposition does not handle "=" in filename
[ https://issues.apache.org/jira/browse/CXF-6989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419168#comment-15419168 ] Sergey Beryozkin commented on CXF-6989: --- Thanks, lots of test cases there :-). I see the one related to a case insensitive filename, but you provided a patch for that. It makes sense to continue addressing those ones that can occur in the practical situations so your expert advice will be welcomed. If you see ContentDisposition blocking some valid filename or other parameters in your work then let me know please. > Content Disposition does not handle "=" in filename > --- > > Key: CXF-6989 > URL: https://issues.apache.org/jira/browse/CXF-6989 > Project: CXF > Issue Type: Bug > Components: Core >Reporter: Kevin Osborn >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.8, 3.0.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
