[jira] [Updated] (CXF-7668) Downgrade the Servlet API to Servlet 3.0
[
https://issues.apache.org/jira/browse/CXF-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-7668:
--
Description:
{color:#80}When deploying cxf 3.2 on tomcat 7, it breaks because of a hard
dependency {color}{color:#80}on Servlet 3.1 classes in
Servlet3ContinuationProvider
{color}{color:#80}(javax.servlet.WriteListener), which results in
ClassNotFound at runtime. {color}{color:#80}At some point JAX-RS 2.1 API
dropped NIO support and the dependecy on Servlet 3.1 API as well, right before
releasing the spec (commit reference
{color}+[https://github.com/jax-rs/api/commit/a4faa965bbe4d058caa41f56f712fa52fc9600fe#diff-bb05b5ab9309760c3271445278116a2f]+{color:#80}).
{color}
{color:#80}The Servlet 3.0 should be the base line.{color}
was:
{color:#80}When deploying cxf 3.2 on tomcat 7, it breaks because of a hard
dependency {color}{color:#80}on Servlet 3.1 classes in
Servlet3ContinuationProvider
{color}{color:#80}{color:#80}(javax.servlet.WriteListener), which
results in ClassNotFound at runtime. {color}{color}{color:#80}At some point
JAX-RS 2.1 API dropped NIO support and the dependecy on Servlet 3.1 API as
well, right before {color}
{color:#80}releasing the spec (commit reference
{color}+[https://github.com/jax-rs/api/commit/a4faa965bbe4d058caa41f56f712fa52fc9600fe#diff-bb05b5ab9309760c3271445278116a2f]+{color:#80}).
The Servlet 3.0 should be the base line.
{color}
> Downgrade the Servlet API to Servlet 3.0
>
>
> Key: CXF-7668
> URL: https://issues.apache.org/jira/browse/CXF-7668
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
>
> {color:#80}When deploying cxf 3.2 on tomcat 7, it breaks because of a
> hard dependency {color}{color:#80}on Servlet 3.1 classes in
> Servlet3ContinuationProvider
> {color}{color:#80}(javax.servlet.WriteListener), which results in
> ClassNotFound at runtime. {color}{color:#80}At some point JAX-RS 2.1 API
> dropped NIO support and the dependecy on Servlet 3.1 API as well, right
> before releasing the spec (commit reference
> {color}+[https://github.com/jax-rs/api/commit/a4faa965bbe4d058caa41f56f712fa52fc9600fe#diff-bb05b5ab9309760c3271445278116a2f]+{color:#80}).
> {color}
> {color:#80}The Servlet 3.0 should be the base line.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7668) Downgrade the Servlet API to Servlet 3.0
[
https://issues.apache.org/jira/browse/CXF-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-7668:
--
Description:
{color:#80}When deploying cxf 3.2 on tomcat 7, it breaks because of a hard
dependency {color}{color:#80}on Servlet 3.1 classes in
Servlet3ContinuationProvider
{color}{color:#80}{color:#80}(javax.servlet.WriteListener), which
results in ClassNotFound at runtime. {color}{color}{color:#80}At some point
JAX-RS 2.1 API dropped NIO support and the dependecy on Servlet 3.1 API as
well, right before {color}
{color:#80}releasing the spec (commit reference
{color}+[https://github.com/jax-rs/api/commit/a4faa965bbe4d058caa41f56f712fa52fc9600fe#diff-bb05b5ab9309760c3271445278116a2f]+{color:#80}).
The Servlet 3.0 should be the base line.
{color}
> Downgrade the Servlet API to Servlet 3.0
>
>
> Key: CXF-7668
> URL: https://issues.apache.org/jira/browse/CXF-7668
> Project: CXF
> Issue Type: Improvement
>Reporter: Andriy Redko
>Assignee: Andriy Redko
>Priority: Major
>
> {color:#80}When deploying cxf 3.2 on tomcat 7, it breaks because of a
> hard dependency {color}{color:#80}on Servlet 3.1 classes in
> Servlet3ContinuationProvider
> {color}{color:#80}{color:#80}(javax.servlet.WriteListener), which
> results in ClassNotFound at runtime. {color}{color}{color:#80}At some
> point JAX-RS 2.1 API dropped NIO support and the dependecy on Servlet 3.1 API
> as well, right before {color}
> {color:#80}releasing the spec (commit reference
> {color}+[https://github.com/jax-rs/api/commit/a4faa965bbe4d058caa41f56f712fa52fc9600fe#diff-bb05b5ab9309760c3271445278116a2f]+{color:#80}).
> The Servlet 3.0 should be the base line.
> {color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7668) Downgrade the Servlet API to Servlet 3.0
Andriy Redko created CXF-7668: - Summary: Downgrade the Servlet API to Servlet 3.0 Key: CXF-7668 URL: https://issues.apache.org/jira/browse/CXF-7668 Project: CXF Issue Type: Improvement Reporter: Andriy Redko Assignee: Andriy Redko -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7666) Binary multipart payload are shown even if logBinary Flag is set to false
[
https://issues.apache.org/jira/browse/CXF-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386653#comment-16386653
]
Dennis Kieselhorst commented on CXF-7666:
-
There is also a logMultipart flag. Have you tried it?
> Binary multipart payload are shown even if logBinary Flag is set to false
> -
>
> Key: CXF-7666
> URL: https://issues.apache.org/jira/browse/CXF-7666
> Project: CXF
> Issue Type: Bug
> Components: logging
>Affects Versions: 3.2.1
>Reporter: Mohamed Moez MANSOURI
>Priority: Major
>
> **
> Iam using
> {code:java}
>
> org.apache.cxf
> cxf-rt-features-logging
> 3.2.1
>
> {code}
> And i still have logs of binary parts of a multipart message (image/png) even
> if the flag "logBinary" of AbstractLoggingInterceptor is false by default.
> Can you help me ? I would like that if that flag is false , it applies also
> to the inner parts of a multipart message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7667) Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7667. -- Resolution: Fixed > Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no > STSProperties are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an exception on the first invocation. Better instead to > log the error and not to add the specific STS operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7667) Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7667: - Priority: Trivial (was: Major) > Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no > STSProperties are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Trivial > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an exception on the first invocation. Better instead to > log the error and not to add the specific STS operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7667) Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7667: - Description: If the DefaultSecurityTokenServiceProvider is set up without an STSProperties Object there will be an exception on the first invocation. Better instead to log the error and not to add the specific STS operation. (was: If the DefaultSecurityTokenServiceProvider is set up without an STSProperties Object there will be an exception on the first invocation. Better instead to log the erro) > Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no > STSProperties are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an exception on the first invocation. Better instead to > log the error and not to add the specific STS operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7667) Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7667: - Description: If the DefaultSecurityTokenServiceProvider is set up without an STSProperties Object there will be an exception on the first invocation. Better instead to log the erro (was: If the DefaultSecurityTokenServiceProvider is set up without an STSProperties Object there will be an exception on the first invocation. Better instead to log the error and throw an Exception on startup.) > Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties > are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an exception on the first invocation. Better instead to > log the erro -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7667) Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7667: - Summary: Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available (was: Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties are available) > Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no > STSProperties are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an exception on the first invocation. Better instead to > log the erro -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7667) Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7667: - Description: If the DefaultSecurityTokenServiceProvider is set up without an STSProperties Object there will be an exception on the first invocation. Better instead to log the error and throw an Exception on startup. (was: If the DefaultSecurityTokenServiceProvider is set up without an STSProperties Object there will be an NPE on the first invocation. Better instead to log the error and not to add the corresponding STS operation.) > Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties > are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an exception on the first invocation. Better instead to > log the error and throw an Exception on startup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7667) Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties are available
[ https://issues.apache.org/jira/browse/CXF-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CXF-7667: - Summary: Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties are available (was: Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available) > Throw an error in the DefaultSecurityTokenServiceProvider if no STSProperties > are available > --- > > Key: CXF-7667 > URL: https://issues.apache.org/jira/browse/CXF-7667 > Project: CXF > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.15, 3.2.3 > > > If the DefaultSecurityTokenServiceProvider is set up without an STSProperties > Object there will be an NPE on the first invocation. Better instead to log > the error and not to add the corresponding STS operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7667) Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available
Colm O hEigeartaigh created CXF-7667: Summary: Don't add an STS operation in the DefaultSecurityTokenServiceProvider if no STSProperties are available Key: CXF-7667 URL: https://issues.apache.org/jira/browse/CXF-7667 Project: CXF Issue Type: Improvement Reporter: Colm O hEigeartaigh Assignee: Colm O hEigeartaigh Fix For: 3.1.15, 3.2.3 If the DefaultSecurityTokenServiceProvider is set up without an STSProperties Object there will be an NPE on the first invocation. Better instead to log the error and not to add the corresponding STS operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7666) Binary multipart payload are shown even if logBinary Flag is set to false
Mohamed Moez MANSOURI created CXF-7666:
--
Summary: Binary multipart payload are shown even if logBinary Flag
is set to false
Key: CXF-7666
URL: https://issues.apache.org/jira/browse/CXF-7666
Project: CXF
Issue Type: Bug
Components: logging
Affects Versions: 3.2.1
Reporter: Mohamed Moez MANSOURI
**
Iam using
{code:java}
org.apache.cxf
cxf-rt-features-logging
3.2.1
{code}
And i still have logs of binary parts of a multipart message (image/png) even
if the flag "logBinary" of AbstractLoggingInterceptor is false by default.
Can you help me ? I would like that if that flag is false , it applies also to
the inner parts of a multipart message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7625) JAX-RS 2.1 TCK: UriBuilder doesn't handle case where "port" is not an integer
[
https://issues.apache.org/jira/browse/CXF-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385987#comment-16385987
]
Alexey Markevich commented on CXF-7625:
---
Test failed in case query present: "myscheme://not.really.a.host:fakePort/?q=v"
> JAX-RS 2.1 TCK: UriBuilder doesn't handle case where "port" is not an integer
> -
>
> Key: CXF-7625
> URL: https://issues.apache.org/jira/browse/CXF-7625
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Major
> Fix For: 3.2.2
>
>
> The JAX-RS 2.1 TCK (which isn't public in EE4J yet, but once it is, I'll post
> a link) has a test that checks the String content of a call to
> URI.toString(). The URI contains what looks like an HTTP URL, but does not
> specify an integer for the port - it uses a string instead. While debugging
> this, the "host" and "port" portion of the URI is passed in as scheme
> specific part, and the host field is null and the port field is -1.
> {{The UriBuilderImpl creates the URI object, this scheme specific part is
> lost, so when the user (test) calls uri.toString(), they do not see that
> info. Here is an example:}}
> {{String uriString = "myscheme://not.really.a.host:fakePort/";}}{{URI uri =
> UriBuilder.fromUri(uriString).build();}}{{assertEquals(uriString,
> uri.toString());}}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
