[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673099#comment-15673099
]
Alexander K. commented on CXF-7137:
---
Hi, according to OAuth2 spec, there are 3 ways for client's authentication:
confidential, public and bearer-only.
- Confidential clients require a secret to initiate login protocol.
- Public clients do not require a secret to initiate login protocol.
- Bearer-only clients are web services that never initiate a login (user must
be already authenticated).
So the protected web services are bearer-only clients and this means that
Swagger API Docs are read only because clicking on "Try it out!" button will
return an error saying "This request requires HTTP authentication."
This is fine unless you would like to allow the "Try it out!" option for test
purposes only. And this is our part.
Swagger-UI supports the OAuth2 spec by providing an option to configure the
required parameters. It is possible to define via Swagger annotations
SecurityDefinition as part of SwaggerDefinition annotation, but it does not
work because SwaggerDefinition annotation is ignored when using Swagger2Feature
(it is a separate issue). So I found references that provide a workaround by
overriding Swagger2Feature.addSwaggerResource() method:
super.addSwaggerResource(server, bus);
BeanConfig scanner = (BeanConfig) ScannerFactory.getScanner();
Swagger swagger = scanner.getSwagger();
swagger.securityDefinition("qa-auth", new
OAuth2Definition().implicit("http://localhost:8080/auth/realms/master/protocol/openid-connect/auth";).scope("qa",
"test"));
Once SecurityDefinition is defined, Swagger shows "Authorize" button in upper
right corner near "Explore" button which allows manual authorization by
redirecting to an authorization server's login page (Keycloak in my case).
After the manual authorization (login) the user should be able to try out the
protected services because Swagger-UI will receive a token from the
authorization server as part of authorization process. Of course the Swagger-UI
must be defined in the authorization server as a public or confidential client
and according to this the oauth parameters should be defined.
So, as you can see, the web services and Swagger clients are separated clients
and have different authentication types. Swagger allows access to web services
but only for eligible persons and for testing purposes only (since in the
authentication server you can even assign a client to a specific scope).
Now, the problem is that Swagger-UI generates URI to call authorization server
with incorrect parameters which are hard-coded in the HTML file
(realm=your-realms, client_id=your-client-id, etc):
http://localhost:8080/auth/realms/master/protocol/openid-connect/auth?response_type=token&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fservices%2Fo2c.html&realm=your-realms&client_id=your-client-id&scope=qa
As an example, you can see that Swashbuckle (.Net project for Swagger) allows
this configuration by its own syntax like this:
EnableSwaggerUi(c => { c.EnableOAuth2Support("test-client-id", "test-realm",
"Swagger UI"); })
Hopefully it was clear :)
Thanks
> Allow OAuth2 customization via Swagger2Feature
> --
>
> Key: CXF-7137
> URL: https://issues.apache.org/jira/browse/CXF-7137
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: Alexander K.
>
> It seems that there is no way to customize initOAuth() details like clientId,
> clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will
> allow Swagger-UI authorization for protected CXF REST services by an
> authorization server such as Keycloak.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[
https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673099#comment-15673099
]
Alexander K. edited comment on CXF-7137 at 11/17/16 8:11 AM:
-
Hi, according to OAuth2 spec, there are 3 ways for client's authentication:
confidential, public and bearer-only.
- Confidential clients require a secret to initiate login protocol.
- Public clients do not require a secret to initiate login protocol.
- Bearer-only clients are web services that never initiate a login (user must
be already authenticated).
So the protected web services are bearer-only clients and this means that
Swagger API Docs are read only because clicking on "Try it out!" button will
return an error saying "This request requires HTTP authentication."
This is fine unless you would like to allow the "Try it out!" option for test
purposes only. And this is our part.
Swagger-UI supports the OAuth2 spec by providing an option to configure the
required parameters. It is possible to define via Swagger annotations
SecurityDefinition as part of SwaggerDefinition annotation, but it does not
work because SwaggerDefinition annotation is ignored when using Swagger2Feature
(it is a separate issue). So I found references that provide a workaround by
overriding Swagger2Feature.addSwaggerResource() method:
super.addSwaggerResource(server, bus);
BeanConfig scanner = (BeanConfig) ScannerFactory.getScanner();
Swagger swagger = scanner.getSwagger();
swagger.securityDefinition("qa-auth", new
OAuth2Definition().implicit("http://localhost:8080/auth/realms/master/protocol/openid-connect/auth";).scope("qa",
"test"));
Once SecurityDefinition is defined, Swagger shows "Authorize" button in upper
right corner near "Explore" button which allows manual authorization by
redirecting to an authorization server's login page (Keycloak in my case).
After the manual authorization (login) the user should be able to try out the
protected services because Swagger-UI will receive a token from the
authorization server as part of authorization process. Of course the Swagger-UI
must be defined in the authorization server as a public or confidential client
and according to this the oauth parameters should be defined.
So, as you can see, the web services and Swagger clients are separated clients
and have different authentication types. Swagger allows access to web services
but only for eligible persons and for testing purposes only (since in the
authentication server you can even assign a client to a specific scope).
Now, the problem is that Swagger-UI generates URI to call authorization server
with incorrect parameters which are hard-coded in the HTML file
(realm=your-realms, client_id=your-client-id, etc):
http://localhost:8080/auth/realms/master/protocol/openid-connect/auth?response_type=token&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fservices%2Fo2c.html&realm=your-realms&client_id=your-client-id&scope=qa
As an example, you can see that Swashbuckle (.Net project for Swagger) allows
this configuration by its own syntax like this:
EnableSwaggerUi(c => { c.EnableOAuth2Support("test-client-id", "test-realm",
"Swagger UI"); })
Hopefully it was clear :)
Thanks
was (Author: alex...@amdocs.com):
Hi, according to OAuth2 spec, there are 3 ways for client's authentication:
confidential, public and bearer-only.
- Confidential clients require a secret to initiate login protocol.
- Public clients do not require a secret to initiate login protocol.
- Bearer-only clients are web services that never initiate a login (user must
be already authenticated).
So the protected web services are bearer-only clients and this means that
Swagger API Docs are read only because clicking on "Try it out!" button will
return an error saying "This request requires HTTP authentication."
This is fine unless you would like to allow the "Try it out!" option for test
purposes only. And this is our part.
Swagger-UI supports the OAuth2 spec by providing an option to configure the
required parameters. It is possible to define via Swagger annotations
SecurityDefinition as part of SwaggerDefinition annotation, but it does not
work because SwaggerDefinition annotation is ignored when using Swagger2Feature
(it is a separate issue). So I found references that provide a workaround by
overriding Swagger2Feature.addSwaggerResource() method:
super.addSwaggerResource(server, bus);
BeanConfig scanner = (BeanConfig) ScannerFactory.getScanner();
Swagger swagger = scanner.getSwagger();
swagger.securityDefinition("qa-auth", new
OAuth2Definition().implicit("http://localhost:8080/auth/realms/master/protocol/openid-connect/auth";).scope("qa",
"test"));
Once SecurityDefinition is defined, Swagger shows "Authorize" button in upper
right corner near "Explore" button which allows manual authorization by
redirecting to an authorization s
[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673166#comment-15673166 ] Sergey Beryozkin commented on CXF-7137: --- Thanks, lets try to agree on the common terminology first as I'm not aware of the 3 types of clients you've referred to. When I say 'client' I mean an Oauth2 client, public or confidential, the latter is a web server which has a secret allocated to it by OAuth2 AS and this client will only use this secret when it talks to AccessTokenService. What 'client' are you talking about ? thanks > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673195#comment-15673195 ] Alexander K. commented on CXF-7137: --- I mean the same as you: "an Oauth2 client, public or confidential". This one is required for Swagger-UI. > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673335#comment-15673335
]
Concombre Masqué commented on CXF-7117:
---
Hi Andriy,
I confirm it works great. I deployed two bundles, each bundle exposing a JAX-RS
server with absolute HTTP address, and the Swagger descriptors were ok (not the
same anymore). Maybe one thing that should be clearly documented is that you
must use property 'usePathBasedConfig' with value set to 'true' to make it
works correctly (if not you will end up with same Swagger descriptor for all
your REST api, as before).
Great job and thank you for this quick (and smart) fix.
Best regards.
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń closed CXF-7138.
--
Resolution: Not A Bug
Fix Version/s: Invalid
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
> Fix For: Invalid
>
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673427#comment-15673427
]
Marcin Gorgoń commented on CXF-7138:
[~sergeyb] thank you for the hint, but it will dissable logging whole SOAP
entirely. It would be nice to have an option to log SOAP, but skip MTOM
attachments.
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
> Fix For: Invalid
>
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń reopened CXF-7138:
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń updated CXF-7138:
---
Fix Version/s: (was: Invalid)
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673427#comment-15673427
]
Marcin Gorgoń edited comment on CXF-7138 at 11/17/16 11:13 AM:
---
[~sergeyb] thank you for the hint, but it will dissable logging whole SOAP
entirely:
---
ID: 5
Address: http://localhost:8080/services/RepoEndpointImpl
Encoding: UTF-8
Http-Method: POST
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:dfdf5c3a-f3e9-4ca5-be8e-c1dd5540ed8d";
start=""; start-info="text/xml"
Headers: {Accept=[*/*], SOAPAction=[""]}
Messages: --- Multipart Content ---
--
It would be nice to have an option to log SOAP, but skip MTOM attachments.
was (Author: mgorgon):
[~sergeyb] thank you for the hint, but it will dissable logging whole SOAP
entirely. It would be nice to have an option to log SOAP, but skip MTOM
attachments.
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673427#comment-15673427
]
Marcin Gorgoń edited comment on CXF-7138 at 11/17/16 11:18 AM:
---
[~sergeyb] thank you for the hint, but it will dissable logging whole SOAP
entirely:
---
ID: 5
Address: http://localhost:8080/services/RepoEndpointImpl
Encoding: UTF-8
Http-Method: POST
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:dfdf5c3a-f3e9-4ca5-be8e-c1dd5540ed8d";
start=""; start-info="text/xml"
Headers: {Accept=[*/*], SOAPAction=[""]}
Messages: --- Multipart Content ---
--
It would be nice to have an option to log SOAP, but skip MTOM attachments:
ID: 6
Address: http://localhost:8080/services/RepoEndpointImpl
Encoding: UTF-8
Http-Method: POST
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:06ea7341-ff34-4a83-9327-b2d4b78f4057";
start=""; start-info="text/xml"
Headers: {Accept=[*/*], SOAPAction=[""]}
Payload: --uuid:06ea7341-ff34-4a83-9327-b2d4b78f4057
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID:
http://schemas.xmlsoap.org/soap/envelope/";>/..
--uuid:06ea7341-ff34-4a83-9327-b2d4b78f4057
Content-Type: application/vnd.ms-word.document.12
Content-Transfer-Encoding: binary
Content-ID: <333af6a1-3c45-4143-964a-33a533cc3bd...@sample.com>
--- BINARY PAYLOAD ---
was (Author: mgorgon):
[~sergeyb] thank you for the hint, but it will dissable logging whole SOAP
entirely:
---
ID: 5
Address: http://localhost:8080/services/RepoEndpointImpl
Encoding: UTF-8
Http-Method: POST
Content-Type: multipart/related; type="application/xop+xml";
boundary="uuid:dfdf5c3a-f3e9-4ca5-be8e-c1dd5540ed8d";
start=""; start-info="text/xml"
Headers: {Accept=[*/*], SOAPAction=[""]}
Messages: --- Multipart Content ---
--
It would be nice to have an option to log SOAP, but skip MTOM attachments.
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673556#comment-15673556
]
Sergey Beryozkin commented on CXF-7138:
---
I think this issue needs to be resolved, please do it - as you've confirmed the
binary content won't be logged for your case.
The issue of selectively logging individual multipart parts is a different
issue altogether. Please open a new request which I'd qualify as a Wish or
Improvement. IMHO it will be hard to do right- one would need to parse the
whole multipart payload, decide which parts are non-binary, log them, ignore
binary ones. How and if it will be done is a diff discussion though to this
particular issue IMHO
thanks
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673570#comment-15673570
]
Andriy Redko commented on CXF-7117:
---
Hi Concombre,
Awesome, great it works, a bit hack'ish but not much choice we have here.
Sure, good point, I will update the documentation accordingly, thanks a lot for
reporting the issue!
Best Regards,
Andriy Redko
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko resolved CXF-7117.
---
Resolution: Fixed
Fix Version/s: 3.1.9
3.2.0
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>Assignee: Andriy Redko
> Fix For: 3.2.0, 3.1.9
>
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673577#comment-15673577 ] Sergey Beryozkin commented on CXF-7137: --- OK, thanks. So we have a confidential OAuth2 (web server) client. Can you please address my earlier question. This client does not want to let anyone else see this secret. This client will only use this secret to talk to AccessTokenService. Letting the users to Try it Out via Swagger UI would be a potential security issue. What am I missing ? cheers > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6420) Maven cxf-java2ws-plugin copies to the maven repository only the last wsdl of multiple services/executions - overwrites the others
[
https://issues.apache.org/jira/browse/CXF-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673622#comment-15673622
]
ericv. commented on CXF-6420:
-
could you explain how to retrieve the wsdl with maven dependencies ? It seems
that what you did imply that must be "serviceName.wsdl" instead of
"wsdl", unfortunately it does not work. On my Nexus 3 server I see that the
type is "wsdl" only. The filename is ok (serviceName.wsdl). So it is not
possible to retrieve the WSDL properly using maven coordinates.
> Maven cxf-java2ws-plugin copies to the maven repository only the last wsdl of
> multiple services/executions - overwrites the others
> --
>
> Key: CXF-6420
> URL: https://issues.apache.org/jira/browse/CXF-6420
> Project: CXF
> Issue Type: Improvement
> Components: Build system
>Affects Versions: 3.1.0
> Environment: in all environments
>Reporter: Andreas Panagiotidis
>Assignee: Daniel Kulp
> Labels: easyfix
> Fix For: 3.1.1, 3.0.6
>
> Attachments: test-cxf-with-deploy-plugin.zip
>
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> I use the Maven *cxf-java2ws-plugin:java2ws* to generate WSDLs from
> WebService Java classes.
> For each Service, I create an execution of the plugin, as suggest in this
> link
> http://mail-archives.apache.org/mod_mbox/cxf-users/201003.mbox/%3c201003132152.22957.dk...@apache.org%3E
> . I have not found any other option to generate multiple services in a
> single project.
> By default in the latest version of cxf-java2ws-plugin the configuration
> parameter "attachWsdl" is true.
> That means that the plugin generates a WSDL for *each* execution.
> Unfortunately, the plugin during the maven install phase tries to attache
> each generated WSDL to the local repository in the maven repository with the
> name:
> {code}
> maven-local-repository\[groupId]\[version]\[artifactId]-[version].wsdl
> {code}
> The naming of the file is the reason that maven does not copy all the WSDLs .
> Only the one of the first execution of the plugin get's copied. The plugin
> checks if the file exists already and it skips the others (which are named
> with the same name).
> Equally important, Maven version 3.3.3 does not allow to release a Maven
> project. (Maven 3.0.5 had a different process)
> The maven deploy plugin during the release uploads to the enterprise
> repository the first generated WSDL successfully. But then it tries to upload
> the WSDL from second execution, but that already exists in the Maven
> Enterprise Repository (the WSDLs have the same name). Thus, the project
> cannot upload the WSDLs and it cannot also get released.
> We may set the attachWsdl option to false, but this is not a solution, as for
> some the goal is to *deploy* the WSDL files.
> I attach a zip with a maven project that demonstrates the issue.
> You see that the plugin copies in the local repository only the last WSDL
> file, instead of generating once for each execution.
> {code}
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> test-cxf-with-deploy-plugin ---
> [INFO] Installing
> C:\test-cxf-with-deploy-plugin\target\test-cxf-with-deploy-plugin-1.0.jar to
> C:\\m3-repository\ch\apanag\test-cxf-with-deploy-plugin\1.0\test-cxf-with-deploy-plugin-1.0.jar
> [INFO] Installing C:\test-cxf-with-deploy-plugin\pom.xml to
> C:\eplatform\lib\m3-repository\ch\apanag\test-cxf-with-deploy-plugin\1.0\test-cxf-with-deploy-plugin-1.0.pom
> [INFO] Installing
> C:\test-cxf-with-deploy-plugin\target\generated\wsdl\MyService.wsdl to
> C:\m3-repository\ch\apanag\test-cxf-with-deploy-plugin\1.0\test-cxf-with-deploy-plugin-1.0.wsdl
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> Deploying a release version to a Maven Enterprise Repository throws an HTML
> 400 error, as normally a release repository does not allow the redeployment
> of file.
> In the end of the day, the plugin does not allow to copy to a repository each
> WSDL. This is against to what it promotes and what its goal was.
> A simple change is the solution. Add in the name of each generated WSDL the
> name of the Service that it represents too.
> {code}
> maven-local-repository\[groupId]\[version]\[artifactId]-[version].[service-name].wsdl
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7137) Allow OAuth2 customization via Swagger2Feature
[ https://issues.apache.org/jira/browse/CXF-7137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673724#comment-15673724 ] Alexander K. commented on CXF-7137: --- If I am not missing something, the idea is to authenticate an API with user based grants (also known as a password grant). The typical scenario includes a Login web page with username and password that is used to authenticate against a first-party API. The web server's secret still remains secret but it will use the authenticated user's token to proceed further. > Allow OAuth2 customization via Swagger2Feature > -- > > Key: CXF-7137 > URL: https://issues.apache.org/jira/browse/CXF-7137 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Affects Versions: 3.1.8 >Reporter: Alexander K. > > It seems that there is no way to customize initOAuth() details like clientId, > clientSecret, realm, appName, etc. for SwaggerUI-OAuth integration. This will > allow Swagger-UI authorization for protected CXF REST services by an > authorization server such as Keycloak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7141) cxf-rt-transports-http incorrectly requires org.osgi.http.service
Benson Margulies created CXF-7141: - Summary: cxf-rt-transports-http incorrectly requires org.osgi.http.service Key: CXF-7141 URL: https://issues.apache.org/jira/browse/CXF-7141 Project: CXF Issue Type: Bug Affects Versions: 3.1.4 Reporter: Benson Margulies org.apache.cxf.transport.http.osgi.HTTPTransportActivator optionally touches the HTTP service, but imports org.osgi.service.http unconditionally. I think it should be a dynamic import, and DISABLE_DEFAULT_HTTP_TRANSPORT should be replaced by reacting to the presence or absence of the service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7141) cxf-rt-transports-http incorrectly requires org.osgi.http.service
[ https://issues.apache.org/jira/browse/CXF-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673886#comment-15673886 ] Sergey Beryozkin commented on CXF-7141: --- Benson, DISABLE_DEFAULT_HTTP_TRANSPORT is there for CXF Http Osgi Transport, for Servlet based deployments to work without default CXF HTTP transport interfering, ex, CXFBlueprintServlet. There were also other side-effects with the users doing their own OSGI CXF integration and a "/cxf" servlet interfering, so lets keep it. Thanks > cxf-rt-transports-http incorrectly requires org.osgi.http.service > - > > Key: CXF-7141 > URL: https://issues.apache.org/jira/browse/CXF-7141 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Benson Margulies > > org.apache.cxf.transport.http.osgi.HTTPTransportActivator optionally touches > the HTTP service, but imports org.osgi.service.http unconditionally. I think > it should be a dynamic import, and DISABLE_DEFAULT_HTTP_TRANSPORT should be > replaced by reacting to the presence or absence of the service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7141) cxf-rt-transports-http incorrectly requires org.osgi.http.service
[ https://issues.apache.org/jira/browse/CXF-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673886#comment-15673886 ] Sergey Beryozkin edited comment on CXF-7141 at 11/17/16 2:41 PM: - Benson, DISABLE_DEFAULT_HTTP_TRANSPORT is there for CXF Http Osgi Transport, for Servlet based deployments to work without default CXF HTTP transport interfering, ex, CXFBlueprintServlet. There were also other side-effects with the users doing their own OSGI CXF integration and a "/cxf" servlet interfering. In other words, even of OSGI HttpService is available, CXF users should still be able to tell CXF not to use a default transport. So lets keep it. Thanks was (Author: sergey_beryozkin): Benson, DISABLE_DEFAULT_HTTP_TRANSPORT is there for CXF Http Osgi Transport, for Servlet based deployments to work without default CXF HTTP transport interfering, ex, CXFBlueprintServlet. There were also other side-effects with the users doing their own OSGI CXF integration and a "/cxf" servlet interfering, so lets keep it. Thanks > cxf-rt-transports-http incorrectly requires org.osgi.http.service > - > > Key: CXF-7141 > URL: https://issues.apache.org/jira/browse/CXF-7141 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Benson Margulies > > org.apache.cxf.transport.http.osgi.HTTPTransportActivator optionally touches > the HTTP service, but imports org.osgi.service.http unconditionally. I think > it should be a dynamic import, and DISABLE_DEFAULT_HTTP_TRANSPORT should be > replaced by reacting to the presence or absence of the service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7141) cxf-rt-transports-http incorrectly requires org.osgi.http.service
[ https://issues.apache.org/jira/browse/CXF-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673894#comment-15673894 ] Benson Margulies commented on CXF-7141: --- I don't mind if you keep the extra property so long as you fix the non-dynamic import :-). I am currently in the middle of trying to make something work that has only the CXF non-servet (http-jetty) transport in OSGi. I think that I should be leaving the plain http transport of the deployment altogether, but I ran into wiring errors looking for HttpService in one of my intermediate states. > cxf-rt-transports-http incorrectly requires org.osgi.http.service > - > > Key: CXF-7141 > URL: https://issues.apache.org/jira/browse/CXF-7141 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Benson Margulies > > org.apache.cxf.transport.http.osgi.HTTPTransportActivator optionally touches > the HTTP service, but imports org.osgi.service.http unconditionally. I think > it should be a dynamic import, and DISABLE_DEFAULT_HTTP_TRANSPORT should be > replaced by reacting to the presence or absence of the service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7141) cxf-rt-transports-http incorrectly requires org.osgi.http.service
[ https://issues.apache.org/jira/browse/CXF-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673894#comment-15673894 ] Benson Margulies edited comment on CXF-7141 at 11/17/16 2:45 PM: - I don't mind if you keep the extra property so long as you fix the non-dynamic import :-). I am currently in the middle of trying to make something work that has only the CXF non-servet (http-jetty) transport in OSGi. was (Author: bmargulies): I don't mind if you keep the extra property so long as you fix the non-dynamic import :-). I am currently in the middle of trying to make something work that has only the CXF non-servet (http-jetty) transport in OSGi. I think that I should be leaving the plain http transport of the deployment altogether, but I ran into wiring errors looking for HttpService in one of my intermediate states. > cxf-rt-transports-http incorrectly requires org.osgi.http.service > - > > Key: CXF-7141 > URL: https://issues.apache.org/jira/browse/CXF-7141 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Benson Margulies > > org.apache.cxf.transport.http.osgi.HTTPTransportActivator optionally touches > the HTTP service, but imports org.osgi.service.http unconditionally. I think > it should be a dynamic import, and DISABLE_DEFAULT_HTTP_TRANSPORT should be > replaced by reacting to the presence or absence of the service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CXF-7141) cxf-rt-transports-http incorrectly requires org.osgi.http.service
[ https://issues.apache.org/jira/browse/CXF-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15673886#comment-15673886 ] Benson Margulies edited comment on CXF-7141 at 11/17/16 2:47 PM: - Benson, DISABLE_DEFAULT_HTTP_TRANSPORT is there for CXF Http Osgi Transport, for Servlet based deployments to work without default CXF HTTP transport interfering, ex, CXFBlueprintServlet. There were also other side-effects with the users doing their own OSGI CXF integration and a "/cxf" servlet interfering. In other words, even if OSGI HttpService is available, CXF users should still be able to tell CXF not to use a default transport. So lets keep it. Thanks was (Author: sergey_beryozkin): Benson, DISABLE_DEFAULT_HTTP_TRANSPORT is there for CXF Http Osgi Transport, for Servlet based deployments to work without default CXF HTTP transport interfering, ex, CXFBlueprintServlet. There were also other side-effects with the users doing their own OSGI CXF integration and a "/cxf" servlet interfering. In other words, even of OSGI HttpService is available, CXF users should still be able to tell CXF not to use a default transport. So lets keep it. Thanks > cxf-rt-transports-http incorrectly requires org.osgi.http.service > - > > Key: CXF-7141 > URL: https://issues.apache.org/jira/browse/CXF-7141 > Project: CXF > Issue Type: Bug >Affects Versions: 3.1.4 >Reporter: Benson Margulies > > org.apache.cxf.transport.http.osgi.HTTPTransportActivator optionally touches > the HTTP service, but imports org.osgi.service.http unconditionally. I think > it should be a dynamic import, and DISABLE_DEFAULT_HTTP_TRANSPORT should be > replaced by reacting to the presence or absence of the service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7142) Blueprint mandatory in OSGi
Benson Margulies created CXF-7142: - Summary: Blueprint mandatory in OSGi Key: CXF-7142 URL: https://issues.apache.org/jira/browse/CXF-7142 Project: CXF Issue Type: Bug Affects Versions: 3.1.4 Reporter: Benson Margulies As I understand it, I'm supposed to be able to opt out of blueprint. But the jaxrs-frontend bundle requires it. [WARN ] 2016-11-17 06:50:54.561 [FelixStartLevel] org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer - Aries Blueprint packages not available. So namespaces will not be registered java.lang.NoClassDefFoundError: org/apache/aries/blueprint/NamespaceHandler at java.lang.ClassLoader.defineClass1(Native Method) ~[?:1.8.0_60] at java.lang.ClassLoader.defineClass(ClassLoader.java:760) ~[?:1.8.0_60] at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370) ~[org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154) ~[org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542) ~[org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79) ~[org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018) ~[org.apache.felix.framework-5.6.1.jar:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_60] at org.apache.cxf.jaxrs.blueprint.Activator$1.createNamespaceHandler(Activator.java:33) ~[org.apache.cxf-cxf-rt-frontend-jaxrs-3.1.4.jar:3.1.4] at org.apache.cxf.bus.blueprint.NamespaceHandlerRegisterer.register(NamespaceHandlerRegisterer.java:39) [org.apache.cxf-cxf-core-3.1.4.jar:3.1.4] at org.apache.cxf.jaxrs.blueprint.Activator.start(Activator.java:36) [org.apache.cxf-cxf-rt-frontend-jaxrs-3.1.4.jar:3.1.4] at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697) [org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.Felix.activateBundle(Felix.java:2226) [org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.Felix.startBundle(Felix.java:2144) [org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371) [org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) [org.apache.felix.framework-5.6.1.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_60] Caused by: java.lang.ClassNotFoundException: *** Class 'org.apache.aries.blueprint.NamespaceHandler' was not found. Bundle org.apache.cxf.cxf-rt-frontend-jaxrs [50] does not import package 'org.apache.aries.blueprint', nor is the package exported by any other bundle or available from the system class loader. *** at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2031) ~[org.apache.felix.framework-5.6.1.jar:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_60] ... 17 more Caused by: java.lang.ClassNotFoundException: org.apache.aries.blueprint.NamespaceHandler not found by org.apache.cxf.cxf-rt-frontend-jaxrs [50] at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574) ~[org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79) ~[org.apache.felix.framework-5.6.1.jar:?] at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018) ~[org.apache.felix.framework-5.6.1.jar:?] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_60] ... 17 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CXF-7138) Logging interceptor is logging binary content
[
https://issues.apache.org/jira/browse/CXF-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcin Gorgoń closed CXF-7138.
--
Resolution: Not A Bug
Created wish: https://issues.apache.org/jira/browse/CXF-7143
> Logging interceptor is logging binary content
> -
>
> Key: CXF-7138
> URL: https://issues.apache.org/jira/browse/CXF-7138
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.1.7
>Reporter: Marcin Gorgoń
>
> LoggingInInterceptor and LoggingOutInterceptor are dumping binary payloads,
> even when showBinaryContent is set to false (which is it's default value).
> Actually, AbstractLoggingInterceptor has defined only few binary content
> media types:
> BINARY_CONTENT_MEDIA_TYPES.add("application/octet-stream");
> BINARY_CONTENT_MEDIA_TYPES.add("image/png");
> BINARY_CONTENT_MEDIA_TYPES.add("image/jpeg");
> BINARY_CONTENT_MEDIA_TYPES.add("image/gif");
> When ZIP or PDF files are transmitted in XOP payload, they are not recognized
> as binary content and are logged.
> This enforces users writting their own filters, which should be provided by
> default, when showBinaryContent is set to false.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7143) Option for logging SOAP, but without XOP attachments
[ https://issues.apache.org/jira/browse/CXF-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcin Gorgoń updated CXF-7143: --- Description: As wrote in https://issues.apache.org/jira/browse/CXF-7138 AbstractLoggingInterceptor may be configured for skipping logging binary content in multipart message, but when set, it will not log SOAP. It would be nice to have an option to disable logging binary attachment, but preserve logging SOAP message. was: As wrote in https://issues.apache.org/jira/browse/CXF-7138 AbstractLoggingInterceptor may be configured for skipping logging binary content, but when set, it will not log whole SOAP. It would be nice to have an option to disable logging binary attachment, but preserve logging SOAP message. > Option for logging SOAP, but without XOP attachments > > > Key: CXF-7143 > URL: https://issues.apache.org/jira/browse/CXF-7143 > Project: CXF > Issue Type: Wish >Reporter: Marcin Gorgoń > > As wrote in https://issues.apache.org/jira/browse/CXF-7138 > AbstractLoggingInterceptor may be configured for skipping logging binary > content in multipart message, but when set, it will not log SOAP. > It would be nice to have an option to disable logging binary attachment, but > preserve logging SOAP message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7143) Option for logging SOAP, but without XOP attachments
Marcin Gorgoń created CXF-7143: -- Summary: Option for logging SOAP, but without XOP attachments Key: CXF-7143 URL: https://issues.apache.org/jira/browse/CXF-7143 Project: CXF Issue Type: Wish Reporter: Marcin Gorgoń As wrote in https://issues.apache.org/jira/browse/CXF-7138 AbstractLoggingInterceptor may be configured for skipping logging binary content, but when set, it will not log whole SOAP. It would be nice to have an option to disable logging binary attachment, but preserve logging SOAP message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7133) Don't rely on disabled scanning in CDI
[ https://issues.apache.org/jira/browse/CXF-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675372#comment-15675372 ] ASF GitHub Bot commented on CXF-7133: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/199 > Don't rely on disabled scanning in CDI > -- > > Key: CXF-7133 > URL: https://issues.apache.org/jira/browse/CXF-7133 > Project: CXF > Issue Type: Bug > Components: Integration >Affects Versions: 3.1.9 >Reporter: John D. Ament > Fix For: 3.1.9 > > > In CXF-7097, a scan tag was added to turn off default application scanning. > This approach doesn't work for all packaging types, and creates a bit of an > issue informing consumers. > Would be better if the class were just written correctly to not be discovered. > I have a patch, will raise after the other one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6969) CXF Async HTTP Transport - add supports to configure httpclient with new method
[ https://issues.apache.org/jira/browse/CXF-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-6969. --- Resolution: Not A Problem No response so for. Mark as "Not A Problem" and close for now > CXF Async HTTP Transport - add supports to configure httpclient with new > method > --- > > Key: CXF-6969 > URL: https://issues.apache.org/jira/browse/CXF-6969 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Chester Kim >Assignee: Freeman Fang > > Refer to https://issues.apache.org/jira/browse/CXF-6964 > Configuration of timeout and etc of httpclient with properties are deprecated > in the latest version of apache httpcomponents. We need to go with new way > (Configuration class). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7134) Fix how non-normal scoped beans are used in CDI extension
[ https://issues.apache.org/jira/browse/CXF-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15675511#comment-15675511 ] ASF GitHub Bot commented on CXF-7134: - Github user asfgit closed the pull request at: https://github.com/apache/cxf/pull/200 > Fix how non-normal scoped beans are used in CDI extension > - > > Key: CXF-7134 > URL: https://issues.apache.org/jira/browse/CXF-7134 > Project: CXF > Issue Type: Bug > Components: Integration >Affects Versions: 3.1.8 >Reporter: John D. Ament > Fix For: 3.1.9 > > > When bean instances are looked up, they are never closed. We need to hold on > to all creational contexts and destroy them afterwards. > In addition, need to look at how dependent scoped beans are used. They're > currently behaving like singletons which doesn't sound right. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7134) Fix how non-normal scoped beans are used in CDI extension
[ https://issues.apache.org/jira/browse/CXF-7134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-7134. --- Resolution: Fixed Fix Version/s: 3.2.0 > Fix how non-normal scoped beans are used in CDI extension > - > > Key: CXF-7134 > URL: https://issues.apache.org/jira/browse/CXF-7134 > Project: CXF > Issue Type: Bug > Components: Integration >Affects Versions: 3.1.8 >Reporter: John D. Ament > Fix For: 3.2.0, 3.1.9 > > > When bean instances are looked up, they are never closed. We need to hold on > to all creational contexts and destroy them afterwards. > In addition, need to look at how dependent scoped beans are used. They're > currently behaving like singletons which doesn't sound right. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7133) Don't rely on disabled scanning in CDI
[ https://issues.apache.org/jira/browse/CXF-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko resolved CXF-7133. --- Resolution: Fixed Fix Version/s: 3.2.0 > Don't rely on disabled scanning in CDI > -- > > Key: CXF-7133 > URL: https://issues.apache.org/jira/browse/CXF-7133 > Project: CXF > Issue Type: Bug > Components: Integration >Affects Versions: 3.1.9 >Reporter: John D. Ament > Fix For: 3.2.0, 3.1.9 > > > In CXF-7097, a scan tag was added to turn off default application scanning. > This approach doesn't work for all packaging types, and creates a bit of an > issue informing consumers. > Would be better if the class were just written correctly to not be discovered. > I have a patch, will raise after the other one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
