[jira] [Resolved] (CXF-6510) LoggingOutInterceptor: formatLoggingMessage method is not used in every case
[ https://issues.apache.org/jira/browse/CXF-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6510. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.2.0 3.1.7 3.0.10 Patch from CodeSmell (Mike) applied > LoggingOutInterceptor: formatLoggingMessage method is not used in every case > > > Key: CXF-6510 > URL: https://issues.apache.org/jira/browse/CXF-6510 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.1 >Reporter: Vadim Guskov >Assignee: Sergey Beryozkin > Fix For: 3.0.10, 3.1.7, 3.2.0 > > > https://issues.apache.org/jira/browse/CXF-4392 issue has introduced special > method for logged message format. > All *log(logger, buffer.toString());* strings have been replaced by > *log(logger, formatLoggingMessage(buffer));* > But current version of *LoggingOutInterceptor.LogWriter.close()* contains > log(..) method call without format: > https://github.com/apache/cxf/blob/3dc89fe00c4e4165fc7b9c25ca0faec4ef097a87/core/src/main/java/org/apache/cxf/interceptor/LoggingOutInterceptor.java#L180 > Therefore format of logged message is impossible for the Writer case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6901) UriBuilder may lose resolved query templates
Sergey Beryozkin created CXF-6901: - Summary: UriBuilder may lose resolved query templates Key: CXF-6901 URL: https://issues.apache.org/jira/browse/CXF-6901 Project: CXF Issue Type: Bug Components: JAX-RS Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: 3.0.10, 3.1.7, 3.2.0 Typically one would start resolving at the final build() time, however, with resolveTemplate variations one can build step by step. In this case, if a template is part of the query component then if the resolved template has ended up in the list of the values which will need the extra encoding step, then this resolved template value will be lost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6901) UriBuilder may lose resolved query templates
[ https://issues.apache.org/jira/browse/CXF-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6901. --- Resolution: Fixed > UriBuilder may lose resolved query templates > > > Key: CXF-6901 > URL: https://issues.apache.org/jira/browse/CXF-6901 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.0.10, 3.1.7, 3.2.0 > > > Typically one would start resolving at the final build() time, however, with > resolveTemplate variations one can build step by step. In this case, if a > template is part of the query component then if the resolved template has > ended up in the list of the values which will need the extra encoding step, > then this resolved template value will be lost -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-6898) Update documentation with ContainerRequestFilter where RequestHandler is mentioned
[ https://issues.apache.org/jira/browse/CXF-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6898. --- Resolution: Fixed Assignee: Sergey Beryozkin > Update documentation with ContainerRequestFilter where RequestHandler is > mentioned > -- > > Key: CXF-6898 > URL: https://issues.apache.org/jira/browse/CXF-6898 > Project: CXF > Issue Type: Improvement > Components: Documentation >Reporter: Dennis Kieselhorst >Assignee: Sergey Beryozkin >Priority: Trivial > > The recent documentation still mentions RequestHandler although it no longer > exists. ContainerRequestFilter should be used instead. > See: > http://cxf.apache.org/docs/jax-rs-filters.html > http://cxf.apache.org/docs/secure-jax-rs-services.html#SecureJAX-RSServices-Authentication -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6049) wsdl2java generates code in two folders instead of one (only one ObjectFactory class)
[
https://issues.apache.org/jira/browse/CXF-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CXF-6049:
--
The problem persists with 3.1.6.
Ping?
> wsdl2java generates code in two folders instead of one (only one
> ObjectFactory class)
> -
>
> Key: CXF-6049
> URL: https://issues.apache.org/jira/browse/CXF-6049
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.7.12, 3.0.1, 2.7.13, 3.0.2
> Environment: Java 1.7.0 64-bit, Windows 7.
>Reporter: Gary Gregory
>
> With the WSDL:
> http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?WSDL
> Calling::
> {noformat}
> wsdl2java -server -impl -d C:/test/cxf/wsdl2java/src -classdir
> C:/test/cxf/wsdl2java/bin -compile
> http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?WSDL
> {noformat}
> This generates two source packages:
> - C:\test\cxf\wsdl2java\src\org\oorsprong\websamples
> - C:\test\cxf\wsdl2java\src\org\oorsprong\websamples_countryinfo
> Instead of one.
> CXF replaces the dot in the namespace from the WSDL with an underscore.
> Then JAXB cannot create a JAXBContext for classes in
> {{org.oorsprong.websamples_countryinfo}} because JAXB throws an exception
> because there is no ObjectFactory in that package.
> It seems to me that all the code should be generated in
> {{C:\test\cxf\wsdl2java\src\org\oorsprong\websamples_countryinfo}} and
> nothing in {{C:\test\cxf\wsdl2java\src\org\oorsprong\websamples}}?
> If I use the {{-p}} option to force generation to either package, the runtime
> throws execptions. In one case, CXF cannot find the object factory class, in
> the other, it cannot find a generated model class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6902) Problem with resource that returns Object with CXF version == 3.1.2
Balarami Reddy created CXF-6902:
---
Summary: Problem with resource that returns Object with CXF
version == 3.1.2
Key: CXF-6902
URL: https://issues.apache.org/jira/browse/CXF-6902
Project: CXF
Issue Type: Bug
Components: JAXB Databinding
Affects Versions: 3.1.2
Reporter: Balarami Reddy
Hello,
We have recently migrated from 2.7 to 3.1.2 and we see a behaviour change in
CXF which blocked us from making progress.
The sample code below gives "No message body writer has been found for response
class Integer" which used to work perfect in CXF 2.7
This is just sample code only. We have in our product several rest calls which
return integer/long/Object etc based on some calculations.
@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("/getinteger")
public Response getInteger() {
return Response.ok(4).build();
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-6903) add a NameDigestPasswordCallbackHandler for JAASLoginInterceptor
Freeman Fang created CXF-6903: - Summary: add a NameDigestPasswordCallbackHandler for JAASLoginInterceptor Key: CXF-6903 URL: https://issues.apache.org/jira/browse/CXF-6903 Project: CXF Issue Type: Improvement Reporter: Freeman Fang Currently if we use UsernameToken with JAASLoginInterceptor and wire into underlying container JAAS service we can only use PlainText password, we need a new NameDigestPasswordCallbackHandler in CXF which can store the nonce, createdTime from UsernameToken if use DigestPassword, so that later on in container JAAS we can create digest password from the stored one with nonce and createdTime passed in by NameDigestPasswordCallbackHandler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CXF-6903) add a NameDigestPasswordCallbackHandler for JAASLoginInterceptor
[ https://issues.apache.org/jira/browse/CXF-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-6903: - Assignee: Freeman Fang > add a NameDigestPasswordCallbackHandler for JAASLoginInterceptor > > > Key: CXF-6903 > URL: https://issues.apache.org/jira/browse/CXF-6903 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang > > Currently if we use UsernameToken with JAASLoginInterceptor and wire into > underlying container JAAS service we can only use PlainText password, we need > a new NameDigestPasswordCallbackHandler in CXF which can store the nonce, > createdTime from UsernameToken if use DigestPassword, so that later on in > container JAAS we can create digest password from the stored one with nonce > and createdTime passed in by NameDigestPasswordCallbackHandler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
Christian Lutz created CXF-6904: --- Summary: 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] [Resolved] (CXF-6903) add a NameDigestPasswordCallbackHandler for JAASLoginInterceptor
[ https://issues.apache.org/jira/browse/CXF-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-6903. --- Resolution: Fixed Fix Version/s: 3.2.0 3.1.7 3.0.10 > add a NameDigestPasswordCallbackHandler for JAASLoginInterceptor > > > Key: CXF-6903 > URL: https://issues.apache.org/jira/browse/CXF-6903 > Project: CXF > Issue Type: Improvement >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 3.0.10, 3.1.7, 3.2.0 > > > Currently if we use UsernameToken with JAASLoginInterceptor and wire into > underlying container JAAS service we can only use PlainText password, we need > a new NameDigestPasswordCallbackHandler in CXF which can store the nonce, > createdTime from UsernameToken if use DigestPassword, so that later on in > container JAAS we can create digest password from the stored one with nonce > and createdTime passed in by NameDigestPasswordCallbackHandler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FEDIZ-87) Fediz 1.1.1 Tomcat FederationAuthenticator SSO between web apps
[ https://issues.apache.org/jira/browse/FEDIZ-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15286144#comment-15286144 ] Jan Bernhardt commented on FEDIZ-87: Hi Marc, the fediz plugin will only get active, if you defined the matching path in your fediz plugin configuration and if the application requires authentication. Take a look at the FEdiz HelloWorld Demo Application. There you find an unprotected page without requesting authentication and one with authentication. Just use the EE Security Settings to manage that. > Fediz 1.1.1 Tomcat FederationAuthenticator SSO between web apps > --- > > Key: FEDIZ-87 > URL: https://issues.apache.org/jira/browse/FEDIZ-87 > Project: CXF-Fediz > Issue Type: Improvement >Affects Versions: 1.1.1 >Reporter: Lou Aloia >Priority: Minor > > Enable SSO between multiple web apps deployed on Tomcat so that users already > authenticated in one web app are not redirected to the IdP when they access > another web app from the same browser. Seems like integrating the > functionality in the Tomcat SingleSignOn valve would be a possible solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
