[jira] [Commented] (CXF-5428) Sevice list page default stylesheet is not effective
[
https://issues.apache.org/jira/browse/CXF-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976569#comment-13976569
]
Sergey Beryozkin commented on CXF-5428:
---
This is actually fixed as part of
https://issues.apache.org/jira/browse/CXF-5620,
CXF 2.7.11 (released) & 3.0.0 (released in 2 weeks)
Cheers, Sergey
> Sevice list page default stylesheet is not effective
>
>
> Key: CXF-5428
> URL: https://issues.apache.org/jira/browse/CXF-5428
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.7.8
>Reporter: ptma
>Assignee: Sergey Beryozkin
>Priority: Trivial
> Labels: patch
> Fix For: 2.6.12, 2.7.9, 3.0.0-milestone2
>
>
> Fix:
> Move line 86
> PrintWriter writer = response.getWriter();
> to line 126
> Modify line 172
> URL url = this.getClass().getResource("servicelist.css");
> with
> URL url = this.getClass().getResource("../servicelist.css");
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5620) Exception when try to generate the service list of deployed services
[ https://issues.apache.org/jira/browse/CXF-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-5620: -- Fix Version/s: 2.7.11 3.0.0 > Exception when try to generate the service list of deployed services > > > Key: CXF-5620 > URL: https://issues.apache.org/jira/browse/CXF-5620 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.7.10 > Environment: Tomcat 6/7.0 >Reporter: gary diao >Priority: Minor > Fix For: 2.7.11, 3.0.0 > > > When try to access the service list get following error: > Mar 15, 2014 5:43:42 PM org.apache.catalina.core.StandardWrapperValve invoke > SEVERE: Servlet.service() for servlet CXFServlet threw exception > java.lang.IllegalStateException: getWriter() has already been called for this > response > at > org.apache.catalina.connector.Response.getOutputStream(Response.java:580) > at > org.apache.catalina.connector.ResponseFacade.getOutputStream(ResponseFacade.java:183) > at > org.apache.cxf.transport.servlet.servicelist.ServiceListGeneratorServlet.renderStyleSheet(ServiceListGeneratorServlet.java:174) > at > org.apache.cxf.transport.servlet.servicelist.ServiceListGeneratorServlet.service(ServiceListGeneratorServlet.java:89) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:170) > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153) > at > org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:167) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:211) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) > at java.lang.Thread.run(Thread.java:662) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5428) Sevice list page default stylesheet is not effective
[
https://issues.apache.org/jira/browse/CXF-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976578#comment-13976578
]
Maxim Solodovnik commented on CXF-5428:
---
Thanks
> Sevice list page default stylesheet is not effective
>
>
> Key: CXF-5428
> URL: https://issues.apache.org/jira/browse/CXF-5428
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.7.8
>Reporter: ptma
>Assignee: Sergey Beryozkin
>Priority: Trivial
> Labels: patch
> Fix For: 2.6.12, 2.7.9, 3.0.0-milestone2
>
>
> Fix:
> Move line 86
> PrintWriter writer = response.getWriter();
> to line 126
> Modify line 172
> URL url = this.getClass().getResource("servicelist.css");
> with
> URL url = this.getClass().getResource("../servicelist.css");
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5479) Create a Maven plugin for generating WADL at build time
[ https://issues.apache.org/jira/browse/CXF-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976580#comment-13976580 ] Sergey Beryozkin commented on CXF-5479: --- Thanks Freeman; I think we will be able to have such a documentation provider seamlessly migrated to the the descriptions module in the future if ever needed (via the class inheritance trick). Cheers, Sergey > Create a Maven plugin for generating WADL at build time > --- > > Key: CXF-5479 > URL: https://issues.apache.org/jira/browse/CXF-5479 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Freeman Fang > Fix For: 3.0.0 > > Attachments: CXF-5479-doclet.patch, CXF-5479.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5704) Enhance Spring-based auto-discovery code to locate classes implementing matcing interfaces
Sergey Beryozkin created CXF-5704: - Summary: Enhance Spring-based auto-discovery code to locate classes implementing matcing interfaces Key: CXF-5704 URL: https://issues.apache.org/jira/browse/CXF-5704 Project: CXF Issue Type: Improvement Components: Core Affects Versions: 3.0.0-milestone2 Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5704) Enhance Spring-based auto-discovery code to locate classes implementing matching interfaces
[ https://issues.apache.org/jira/browse/CXF-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-5704: -- Summary: Enhance Spring-based auto-discovery code to locate classes implementing matching interfaces (was: Enhance Spring-based auto-discovery code to locate classes implementing matcing interfaces) > Enhance Spring-based auto-discovery code to locate classes implementing > matching interfaces > --- > > Key: CXF-5704 > URL: https://issues.apache.org/jira/browse/CXF-5704 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0-milestone2 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CXF-5704) Enhance Spring-based auto-discovery code to locate classes implementing matching interfaces
[ https://issues.apache.org/jira/browse/CXF-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-5704. --- Resolution: Fixed > Enhance Spring-based auto-discovery code to locate classes implementing > matching interfaces > --- > > Key: CXF-5704 > URL: https://issues.apache.org/jira/browse/CXF-5704 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0-milestone2 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5479) Create a Maven plugin for generating WADL at build time
[ https://issues.apache.org/jira/browse/CXF-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976665#comment-13976665 ] Sergey Beryozkin commented on CXF-5479: --- I've added the initial documentation here: https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Services+Description#JAXRSServicesDescription-java2wadlMavenplugin Thanks, Sergey > Create a Maven plugin for generating WADL at build time > --- > > Key: CXF-5479 > URL: https://issues.apache.org/jira/browse/CXF-5479 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Freeman Fang > Fix For: 3.0.0 > > Attachments: CXF-5479-doclet.patch, CXF-5479.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-5702:
--
Priority: Minor (was: Blocker)
Summary: CXF 3.0 ApplicationPath issue with JAX-RS (was: CXF 3.0
implementation issue with JAX-RS)
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Priority: Minor
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CXF-5702) CXF 3.0 ApplicationPath issue with JAX-RS
[
https://issues.apache.org/jira/browse/CXF-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-5702.
---
Resolution: Fixed
Fix Version/s: 3.0.0
Assignee: Sergey Beryozkin
You are right, ApplicationPath needs to be ignored by default
> CXF 3.0 ApplicationPath issue with JAX-RS
> -
>
> Key: CXF-5702
> URL: https://issues.apache.org/jira/browse/CXF-5702
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.0.0-milestone2
> Environment: Windows
>Reporter: Kou, Zhi Qiang
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
>
> It seems CXF JAX-RS implementation has something wrong with the relationship
> between defined servlet-mapping and the value of ApplicationPath annotation.
> From JSR-339 spec, section 2.3.2: If the Application subclass is annotated
> with @ApplicationPath, implementations are REQUIRED to use the value of this
> annotation appended with ”/*” to define a mapping for the added server.
> Otherwise, the application MUST be packaged with a web.xml that specifies a
> servlet mapping.
> Also from ApplicationPath javadoc:
> Identifies the application path that serves as the base URI for all resource
> URIs provided by Path. May only be applied to a subclass of Application.
> *When published in a Servlet container, the value of the application path may
> be overridden using a servlet-mapping element in the web.xml.*
> https://jsr311.java.net/nonav/javadoc/javax/ws/rs/ApplicationPath.html
> From above information, if both servlet-mapping in web.xml and
> ApplicationPath has value, only one of them should be used as the base URI,
> and it should be the value of servlet-mapping in web.xml.
> In my application, my web.xml looks like below. There are two servlet
> defined, each for one jaxrs application. And the servlet-mapping values are
> defined as "/first/" and "/second/".
> {quote}
>
> rest1
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.UserDemoApplication
>
>
>
> rest2
>
> org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet
>
> javax.ws.rs.Application
>
> com.ibm.sample.jaxrs.GroupDemoApplication
>
>
>
> rest1
> /first/*
>
>
> rest2
> /second/*
>
> {quote}
> And in my application classes:
> {quote}
> @ApplicationPath("userdemo")
> public class UserDemoApplication extends javax.ws.rs.core.Application {
> @ApplicationPath("groupdemo")
> public class GroupDemoApplication extends javax.ws.rs.core.Application {
> {quote}
> So in this case according to spec and javadoc, "/first/" and "/second/"
> should be used as the base URI, but not the "userdemo" and "groupdemo" or
> BOTH.
> But in my CXF application I can only access the resources via URLs:
> http://localhost:9080/SingleParameterCxf/first/userdemo/users/eric
> http://localhost:9080/SingleParameterCxf/second/groupdemo/groups/root
> However if I implement the same application using Jersey RI libs, I can
> access my resources via URLs:
> http://localhost:9080/SingleParameterJersey/first/users/eric
> http://localhost:9080/SingleParameterJersey/second/groups/root
> My feeling is Jersey RI implementation is correct behavior according to SPEC
> and JavaDoc. Please let me know if my understanding is correct or not.
> Any help is highly appreciated! Thank you!
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CXF-5701) wadl response with JAXB + headers should optionally generate JAX-RS Response
[
https://issues.apache.org/jira/browse/CXF-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-5701:
--
Issue Type: Improvement (was: Bug)
Summary: wadl response with JAXB + headers should optionally generate
JAX-RS Response (was: wadl response with JAXB + headers generates wrong type,
headers cannot be set)
I disagree it is a bug, marking it as Improvement, having Response in the
signature makes it difficult to consume it with proxies, if headers need to be
returned then one can add ContainerResponseFilter right now.
I agree it is worth supporting generation of Responses instead if preferred
> wadl response with JAXB + headers should optionally generate JAX-RS Response
>
>
> Key: CXF-5701
> URL: https://issues.apache.org/jira/browse/CXF-5701
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.7.10
> Environment: Little-Net:users-api minfrin$ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
>Reporter: Graham Leggett
>
> When I run wadl2java on the following fragment of wadl, I get the API
> interface defined below:
> {code}
>
>
>
>
>The SHA1 hash of the sum of DN and modifiedTimestamp of the
> matching users.
>
>
>The Cache-Control header as specified through configuration
> in context.xml.
>
>
>MUST have the value "Authorization", as we vary on the
> Authorization header.
>
> Return list of users. Must have admin role to receive the
> response.
> Note: no users = empty list with status:200
>
> {code}
> {code}
>@GET
>@Produces({"application/json", "application/xml" })
>Users getUsers(@QueryParam("page") Long page, @QueryParam("pageSize") Long
> pageSize, @QueryParam("sort") String sort, @QueryParam("fl") String fl,
>@HeaderParam("If-None-Match") String If_None_Match,
> @HeaderParam("Authorization") String Authorization);
> {code}
> The problem with the interface that is being produced above is that we return
> a JAXB Users object, with no mechanism to return any of the ETag,
> Cache-Control or Vary headers as required by the wadl.
> To maintain backwards compatibility we need an option to send the correct
> response based on whether headers are present or not.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5701) wadl response with JAXB + headers should optionally generate JAX-RS Response
[
https://issues.apache.org/jira/browse/CXF-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976708#comment-13976708
]
Graham Leggett commented on CXF-5701:
-
Do you have documentation / an example to show how it would be possible to
return an ETag with a ContainerResponseFilter?
> wadl response with JAXB + headers should optionally generate JAX-RS Response
>
>
> Key: CXF-5701
> URL: https://issues.apache.org/jira/browse/CXF-5701
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.7.10
> Environment: Little-Net:users-api minfrin$ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
>Reporter: Graham Leggett
>
> When I run wadl2java on the following fragment of wadl, I get the API
> interface defined below:
> {code}
>
>
>
>
>The SHA1 hash of the sum of DN and modifiedTimestamp of the
> matching users.
>
>
>The Cache-Control header as specified through configuration
> in context.xml.
>
>
>MUST have the value "Authorization", as we vary on the
> Authorization header.
>
> Return list of users. Must have admin role to receive the
> response.
> Note: no users = empty list with status:200
>
> {code}
> {code}
>@GET
>@Produces({"application/json", "application/xml" })
>Users getUsers(@QueryParam("page") Long page, @QueryParam("pageSize") Long
> pageSize, @QueryParam("sort") String sort, @QueryParam("fl") String fl,
>@HeaderParam("If-None-Match") String If_None_Match,
> @HeaderParam("Authorization") String Authorization);
> {code}
> The problem with the interface that is being produced above is that we return
> a JAXB Users object, with no mechanism to return any of the ETag,
> Cache-Control or Vary headers as required by the wadl.
> To maintain backwards compatibility we need an option to send the correct
> response based on whether headers are present or not.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5671) NTLM API not exposed
[
https://issues.apache.org/jira/browse/CXF-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976719#comment-13976719
]
Sergey Beryozkin commented on CXF-5671:
---
I've just tried
{code:java}
WebClient.getConfig(wc).getRequestContext().put(org.apache.http.auth.Credentials.class.getName(),
new TestCredential());
{code}
and I can confirm AsyncHttpConduit picks it up
> NTLM API not exposed
>
>
> Key: CXF-5671
> URL: https://issues.apache.org/jira/browse/CXF-5671
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.0.0-milestone2
> Environment: Tomcat 6, jdk (1.6 and 1.7)
>Reporter: Jayashankar
>
> NTLM API using AsyncHTTPConduit is deprecated in cxf 3.0 milestone 2 release,
> where as it is working in 2.7.7.. It is affecting backward compatibility and
> there is no proper API to refactor.
> HTTPConduit http = (HTTPConduit)client.getConduit();
> if ( http instanceof AsyncHTTPConduit ) {
> AsyncHTTPConduit conduit = (AsyncHTTPConduit)http;
> DefaultHttpAsyncClient defaultHttpAsyncClient = null;
> try {
> defaultHttpAsyncClient = conduit.getHttpAsyncClient();
> } catch (IOException e) {
> // TODO Auto-generated catch block }
>
> defaultHttpAsyncClient.getCredentialsProvider().setCredentials(
> AuthScope.ANY, new NTCredentials( "user", "pwd", "host", "domain" ) );
>
> conduit.getClient().setAllowChunking( false );
> conduit.getClient().setAutoRedirect( true );
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5701) wadl response with JAXB + headers should optionally generate JAX-RS Response
[
https://issues.apache.org/jira/browse/CXF-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976723#comment-13976723
]
Sergey Beryozkin commented on CXF-5701:
---
Something like this:
{code:java}
public static class ETagContainerResponseFilter implements
ContainerResponseFilter {
@Override
public void filter(ContainerRequestContext requestContext,
ContainerResponseContext responseContext) throws IOException {
MultivaluedMap headers =
responseContext.getHeaders();
// add headers
}
}
{code}
> wadl response with JAXB + headers should optionally generate JAX-RS Response
>
>
> Key: CXF-5701
> URL: https://issues.apache.org/jira/browse/CXF-5701
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.7.10
> Environment: Little-Net:users-api minfrin$ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
>Reporter: Graham Leggett
>
> When I run wadl2java on the following fragment of wadl, I get the API
> interface defined below:
> {code}
>
>
>
>
>The SHA1 hash of the sum of DN and modifiedTimestamp of the
> matching users.
>
>
>The Cache-Control header as specified through configuration
> in context.xml.
>
>
>MUST have the value "Authorization", as we vary on the
> Authorization header.
>
> Return list of users. Must have admin role to receive the
> response.
> Note: no users = empty list with status:200
>
> {code}
> {code}
>@GET
>@Produces({"application/json", "application/xml" })
>Users getUsers(@QueryParam("page") Long page, @QueryParam("pageSize") Long
> pageSize, @QueryParam("sort") String sort, @QueryParam("fl") String fl,
>@HeaderParam("If-None-Match") String If_None_Match,
> @HeaderParam("Authorization") String Authorization);
> {code}
> The problem with the interface that is being produced above is that we return
> a JAXB Users object, with no mechanism to return any of the ETag,
> Cache-Control or Vary headers as required by the wadl.
> To maintain backwards compatibility we need an option to send the correct
> response based on whether headers are present or not.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5701) wadl response with JAXB + headers should optionally generate JAX-RS Response
[
https://issues.apache.org/jira/browse/CXF-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976750#comment-13976750
]
Sergey Beryozkin commented on CXF-5701:
---
The request and response contexts can provide the relevant info, example, you
can check the response entity, etc. However, I'm not sure what is the right way
to get ETag generated inside the filter persisted inside the application
resource, may be have it implementing ContainerResponseFilter, etc...It can
become a bit not clean all right...Hence the need for the improvement :-)
> wadl response with JAXB + headers should optionally generate JAX-RS Response
>
>
> Key: CXF-5701
> URL: https://issues.apache.org/jira/browse/CXF-5701
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.7.10
> Environment: Little-Net:users-api minfrin$ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
>Reporter: Graham Leggett
>
> When I run wadl2java on the following fragment of wadl, I get the API
> interface defined below:
> {code}
>
>
>
>
>The SHA1 hash of the sum of DN and modifiedTimestamp of the
> matching users.
>
>
>The Cache-Control header as specified through configuration
> in context.xml.
>
>
>MUST have the value "Authorization", as we vary on the
> Authorization header.
>
> Return list of users. Must have admin role to receive the
> response.
> Note: no users = empty list with status:200
>
> {code}
> {code}
>@GET
>@Produces({"application/json", "application/xml" })
>Users getUsers(@QueryParam("page") Long page, @QueryParam("pageSize") Long
> pageSize, @QueryParam("sort") String sort, @QueryParam("fl") String fl,
>@HeaderParam("If-None-Match") String If_None_Match,
> @HeaderParam("Authorization") String Authorization);
> {code}
> The problem with the interface that is being produced above is that we return
> a JAXB Users object, with no mechanism to return any of the ETag,
> Cache-Control or Vary headers as required by the wadl.
> To maintain backwards compatibility we need an option to send the correct
> response based on whether headers are present or not.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5701) wadl response with JAXB + headers should optionally generate JAX-RS Response
[
https://issues.apache.org/jira/browse/CXF-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976736#comment-13976736
]
Graham Leggett commented on CXF-5701:
-
The ETag would be generated by the implementation on a response specific basis,
how would the generated ETag be passed from the implementation to the
ContainerResponseFilter you have described above?
> wadl response with JAXB + headers should optionally generate JAX-RS Response
>
>
> Key: CXF-5701
> URL: https://issues.apache.org/jira/browse/CXF-5701
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.7.10
> Environment: Little-Net:users-api minfrin$ java -version
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
>Reporter: Graham Leggett
>
> When I run wadl2java on the following fragment of wadl, I get the API
> interface defined below:
> {code}
>
>
>
>
>The SHA1 hash of the sum of DN and modifiedTimestamp of the
> matching users.
>
>
>The Cache-Control header as specified through configuration
> in context.xml.
>
>
>MUST have the value "Authorization", as we vary on the
> Authorization header.
>
> Return list of users. Must have admin role to receive the
> response.
> Note: no users = empty list with status:200
>
> {code}
> {code}
>@GET
>@Produces({"application/json", "application/xml" })
>Users getUsers(@QueryParam("page") Long page, @QueryParam("pageSize") Long
> pageSize, @QueryParam("sort") String sort, @QueryParam("fl") String fl,
>@HeaderParam("If-None-Match") String If_None_Match,
> @HeaderParam("Authorization") String Authorization);
> {code}
> The problem with the interface that is being produced above is that we return
> a JAXB Users object, with no mechanism to return any of the ETag,
> Cache-Control or Vary headers as required by the wadl.
> To maintain backwards compatibility we need an option to send the correct
> response based on whether headers are present or not.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5671) NTLM API not exposed
[
https://issues.apache.org/jira/browse/CXF-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976764#comment-13976764
]
Jayashankar commented on CXF-5671:
--
But are you certain that NTLM hand shake is happening as expected ? Where in my
case, the type 3 hand shake is taking my system credentials and ultimately
failing. The consumer is with JDK 6.
This is the authorization header going
TlRMTVNTUAADGAAYAIIIAQgBmgoACgBYCgAKAGIWABYAbACiAQAABYKIogYBsR0P2ZThXptXCah8dUBtXbZooVIAUABFAEcAQQBrAGEAcgBuAGoAVwBLAEEAUgBOAEoAVwA3AEgAWQBEAP4BHTokKCu5xdtzrzC
I actually gave Username = te
password = Testeng!
> NTLM API not exposed
>
>
> Key: CXF-5671
> URL: https://issues.apache.org/jira/browse/CXF-5671
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.0.0-milestone2
> Environment: Tomcat 6, jdk (1.6 and 1.7)
>Reporter: Jayashankar
>
> NTLM API using AsyncHTTPConduit is deprecated in cxf 3.0 milestone 2 release,
> where as it is working in 2.7.7.. It is affecting backward compatibility and
> there is no proper API to refactor.
> HTTPConduit http = (HTTPConduit)client.getConduit();
> if ( http instanceof AsyncHTTPConduit ) {
> AsyncHTTPConduit conduit = (AsyncHTTPConduit)http;
> DefaultHttpAsyncClient defaultHttpAsyncClient = null;
> try {
> defaultHttpAsyncClient = conduit.getHttpAsyncClient();
> } catch (IOException e) {
> // TODO Auto-generated catch block }
>
> defaultHttpAsyncClient.getCredentialsProvider().setCredentials(
> AuthScope.ANY, new NTCredentials( "user", "pwd", "host", "domain" ) );
>
> conduit.getClient().setAllowChunking( false );
> conduit.getClient().setAutoRedirect( true );
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5671) NTLM API not exposed
[
https://issues.apache.org/jira/browse/CXF-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976838#comment-13976838
]
Sergey Beryozkin commented on CXF-5671:
---
Well, this issue about not being possible to affect NTLM with AsyncHttpConduit
and as we've confirmed AsyncHttpConduit does take custom Credentials (ex,
NTCredentials) into the consideration. So I think this issue can be resolved.
I've no idea why the actual handshake fails. Does it work for you if you use
HttpClient directly ?
Here are the relevant versions used by CXF 3.0.0 milestone2:
4.0.1
4.3.3
4.3.2
> NTLM API not exposed
>
>
> Key: CXF-5671
> URL: https://issues.apache.org/jira/browse/CXF-5671
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS Security
>Affects Versions: 3.0.0-milestone2
> Environment: Tomcat 6, jdk (1.6 and 1.7)
>Reporter: Jayashankar
>
> NTLM API using AsyncHTTPConduit is deprecated in cxf 3.0 milestone 2 release,
> where as it is working in 2.7.7.. It is affecting backward compatibility and
> there is no proper API to refactor.
> HTTPConduit http = (HTTPConduit)client.getConduit();
> if ( http instanceof AsyncHTTPConduit ) {
> AsyncHTTPConduit conduit = (AsyncHTTPConduit)http;
> DefaultHttpAsyncClient defaultHttpAsyncClient = null;
> try {
> defaultHttpAsyncClient = conduit.getHttpAsyncClient();
> } catch (IOException e) {
> // TODO Auto-generated catch block }
>
> defaultHttpAsyncClient.getCredentialsProvider().setCredentials(
> AuthScope.ANY, new NTCredentials( "user", "pwd", "host", "domain" ) );
>
> conduit.getClient().setAllowChunking( false );
> conduit.getClient().setAutoRedirect( true );
> }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-3662) wadl2java : Return types aren't generated properly on server interfaces for methods with more than 1 response element.
[
https://issues.apache.org/jira/browse/CXF-3662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976867#comment-13976867
]
Claude-Alain commented on CXF-3662:
---
In this example, there is a normal response and an error. In that case, the
error can be treated with an exception mapper. In case there a additional
response (for example with status code = 204), I think it would be more logical
to have a return type "javax.ws.rs.core.Response" instead of taking the first
one.
> wadl2java : Return types aren't generated properly on server interfaces for
> methods with more than 1 response element.
> --
>
> Key: CXF-3662
> URL: https://issues.apache.org/jira/browse/CXF-3662
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 2.4.1
> Environment: Windows 7 32 bit
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
>Reporter: Ceri Hughes
>Assignee: Sergey Beryozkin
> Fix For: 2.4.2, 2.5
>
>
> My wadl file frequently has more than 1 response element in the method
> elements, i.e.:
> {code}
>
> Gets default user configuration values.
>
>element="fmc:userDefaults" />
>
>
>element="fmc:errorList" />
>
>
> {code}
> If there is more than 1 response element, the wadl2java tool assumes that the
> return type from generated methods is always void. There is a line of code
> that checks for exactly 1 response element - if there isn't 1 (i.e. 0 or more
> than 1), then void is assumed. Can it not take the representation of the 1st
> response in a case when there is more than 1 (or better, the representation
> from the response with a success status)?
> See the first line of
> org.apache.cxf.jaxrs.ext.codegen.SourceGenerator.writeResponseType
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CXF-5664) CXF STS does not support wst:Participants
[ https://issues.apache.org/jira/browse/CXF-5664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977041#comment-13977041 ] Colm O hEigeartaigh commented on CXF-5664: -- Oops, it's now fixed! Colm. > CXF STS does not support wst:Participants > - > > Key: CXF-5664 > URL: https://issues.apache.org/jira/browse/CXF-5664 > Project: CXF > Issue Type: Bug > Components: STS >Affects Versions: 2.7.8, 2.7.9, 2.7.10 >Reporter: Stephen Chappell >Assignee: Colm O hEigeartaigh > Labels: features, security > Fix For: 2.7.12, 3.0.0 > > > The CXF STS does not recognize the wst:Participants element within a > wst:RequestSecurityToken, and instead throws a BadRequest SOAP fault. The > Participants element should be parsed and added to the list of > AudienceRestrictions in the issued token. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CXF-5705) OAuth2 Client should support public certificates in addition to client secret
Sergey Beryozkin created CXF-5705: - Summary: OAuth2 Client should support public certificates in addition to client secret Key: CXF-5705 URL: https://issues.apache.org/jira/browse/CXF-5705 Project: CXF Issue Type: Improvement Components: JAX-RS, JAX-RS Security Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Right now Client can only have a secret which will be typically assigned to it during the client registration. Client should also support persisting public certificates of confidential clients. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5705) OAuth2 Client should support public certificates in addition to client secret
[ https://issues.apache.org/jira/browse/CXF-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977470#comment-13977470 ] Sergey Beryozkin commented on CXF-5705: --- One possibility is to introduce ClientCredentials interface which can represent either a generated secret or public certificate however it may pose problems with persisting the Client model. > OAuth2 Client should support public certificates in addition to client secret > - > > Key: CXF-5705 > URL: https://issues.apache.org/jira/browse/CXF-5705 > Project: CXF > Issue Type: Improvement > Components: JAX-RS, JAX-RS Security >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > > Right now Client can only have a secret which will be typically assigned to > it during the client registration. Client should also support persisting > public certificates of confidential clients. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CXF-5705) OAuth2 Client should support public certificates in addition to client secret
[ https://issues.apache.org/jira/browse/CXF-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977485#comment-13977485 ] Sergey Beryozkin commented on CXF-5705: --- Actually, we can introduce a credentials type, "secret" is default, if it is "public cert" then String property will hold a base64 encoded certificate representation. > OAuth2 Client should support public certificates in addition to client secret > - > > Key: CXF-5705 > URL: https://issues.apache.org/jira/browse/CXF-5705 > Project: CXF > Issue Type: Improvement > Components: JAX-RS, JAX-RS Security >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin > > Right now Client can only have a secret which will be typically assigned to > it during the client registration. Client should also support persisting > public certificates of confidential clients. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CXF-5704) Enhance Spring-based auto-discovery code to locate classes implementing matching interfaces
[ https://issues.apache.org/jira/browse/CXF-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò updated CXF-5704: Attachment: Syncope-trunk-CXF-5704.patch I've built from CXF master branch, then applied this patch to Syncope trunk: when the Syncope core application is being deployed, I get the following exception: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 92 in XML document from file [/home/ilgrosso/work/syncope/trunk/core/target/cargo/configurations/tomcat7x/webapps/syncope/WEB-INF/classes/restContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 92; columnNumber: 131; cvc-complex-type.3.2.2: Attribute 'basePackages' is not allowed to appear in element 'jaxrs:server'. What am I doing wrong? > Enhance Spring-based auto-discovery code to locate classes implementing > matching interfaces > --- > > Key: CXF-5704 > URL: https://issues.apache.org/jira/browse/CXF-5704 > Project: CXF > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.0-milestone2 >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 3.0.0 > > Attachments: Syncope-trunk-CXF-5704.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CXF-5704) Enhance Spring-based auto-discovery code to locate classes implementing matching interfaces
[
https://issues.apache.org/jira/browse/CXF-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977905#comment-13977905
]
Francesco Chicchiriccò edited comment on CXF-5704 at 4/23/14 6:52 AM:
--
I've built from CXF master branch, then applied this patch to Syncope trunk:
when the Syncope core application is being deployed, I get the following
exception:
{code}
Exception sending context initialized event to listener instance of class
org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 92
in XML document from file
[/home/ilgrosso/work/syncope/trunk/core/target/cargo/configurations/tomcat7x/webapps/syncope/WEB-INF/classes/restContext.xml]
is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 92;
columnNumber: 131; cvc-complex-type.3.2.2: Attribute 'basePackages' is not
allowed to appear in element 'jaxrs:server'.
{code}
What am I doing wrong?
was (Author: ilgrosso):
I've built from CXF master branch, then applied this patch to Syncope trunk:
when the Syncope core application is being deployed, I get the following
exception:
Exception sending context initialized event to listener instance of class
org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 92
in XML document from file
[/home/ilgrosso/work/syncope/trunk/core/target/cargo/configurations/tomcat7x/webapps/syncope/WEB-INF/classes/restContext.xml]
is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 92;
columnNumber: 131; cvc-complex-type.3.2.2: Attribute 'basePackages' is not
allowed to appear in element 'jaxrs:server'.
What am I doing wrong?
> Enhance Spring-based auto-discovery code to locate classes implementing
> matching interfaces
> ---
>
> Key: CXF-5704
> URL: https://issues.apache.org/jira/browse/CXF-5704
> Project: CXF
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.0.0-milestone2
>Reporter: Sergey Beryozkin
>Assignee: Sergey Beryozkin
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: Syncope-trunk-CXF-5704.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
