[jira] [Created] (CXF-4321) NPE in MEXInInterceptor
Richard Opalka created CXF-4321:
---
Summary: NPE in MEXInInterceptor
Key: CXF-4321
URL: https://issues.apache.org/jira/browse/CXF-4321
Project: CXF
Issue Type: Bug
Components: WS-* Components
Reporter: Richard Opalka
Fix For: 2.6.1, 2.5.4
09:59:48,358 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
(http-/127.0.0.1:8080-2) Interceptor for {http://example.com}AddNumbersService
has thrown exception, unwinding now: java.lang.NullPointerException
at
org.apache.cxf.ws.mex.MEXInInterceptor.handleMessage(MEXInInterceptor.java:64)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
at
org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
at
org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
[jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
[jbossws-spi.jar:2.1.0-SNAPSHOT]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
[jbossweb-7.0.16.Final.jar:]
at
org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
[jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
[jbossweb-7.0.16.Final.jar:]
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
[jbossweb-7.0.16.Final.jar:]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4321) NPE in MEXInInterceptor
[
https://issues.apache.org/jira/browse/CXF-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Opalka updated CXF-4321:
Attachment: CXF-4321.patch
Attaching fix proposal
> NPE in MEXInInterceptor
> ---
>
> Key: CXF-4321
> URL: https://issues.apache.org/jira/browse/CXF-4321
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Reporter: Richard Opalka
> Fix For: 2.6.1, 2.5.4
>
> Attachments: CXF-4321.patch
>
>
> 09:59:48,358 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> (http-/127.0.0.1:8080-2) Interceptor for
> {http://example.com}AddNumbersService has thrown exception, unwinding now:
> java.lang.NullPointerException
> at
> org.apache.cxf.ws.mex.MEXInInterceptor.handleMessage(MEXInInterceptor.java:64)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
> at
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
> at
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> [jbossws-spi.jar:2.1.0-SNAPSHOT]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> [jbossweb-7.0.16.Final.jar:]
> at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DOSGI-111) DOSGi bundle attempts to load WSDL using wrong bundle in WSDL-first configuration
[
https://issues.apache.org/jira/browse/DOSGI-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278649#comment-13278649
]
Sergey Beryozkin commented on DOSGI-111:
Anthony, thanks for the confirmation. I think this issue can be solved as Not a
Problem. I do not know myself how to correctly export from the root package,
but that issue is outside of the DSW control. DSW itself does the dynamic
import at the moment, so dswContext.getBundle().getResource() should result in
searching the imported resources
> DOSGi bundle attempts to load WSDL using wrong bundle in WSDL-first
> configuration
> --
>
> Key: DOSGI-111
> URL: https://issues.apache.org/jira/browse/DOSGI-111
> Project: CXF Distributed OSGi
> Issue Type: Bug
> Components: DSW
>Affects Versions: 1.3
> Environment: JRE6 (1.6.0_24)
> Felix 4.0.2
> CXF DOSGi 1.3 single bundle
>Reporter: Adam Crossley
> Fix For: 1.3.1
>
>
> I'm using a WSDL-first approach to expose a web service. My supplied WSDL
> file which is in my service bundle is not found during registration of the
> web service.
> I have the following code in my activator:
> props = new Hashtable();
> props.put("service.exported.interfaces", "*");
> props.put("service.exported.configs", "wsdl");
> props.put("org.apache.cxf.ws.address",
> "http://localhost:8080/WebService";);
> props.put("osgi.remote.configuration.wsdl.service.ns",
> "http://tradeservice.com/";);
> props.put("osgi.remote.configuration.wsdl.service.name", "Trade");
> props.put("osgi.remote.configuration.wsdl.port.name",
> "TradeSoap");
> props.put("osgi.remote.configuration.wsdl.location",
> "trade.wsdl");
> tradeRegistration =
> ctx.registerService(TradeWebService.class.getName(), new
> TradeWebServiceImpl(), props);
> The trade.wsdl file is in the root of my service bundle and is accessible by
> classes within my bundle.
> When the registerService() method is called I get this error:
> NullPointerException: (TopologyManager.java:333)
> I debugged through the dsw code and found the problem appears to be this line:
> WsdlConfigurationTypeHandler.java:120
> URL wsdlURL = dswContext.getBundle().getResource(location);
> The WSDL resource is being loaded in the context of the DOSGi bundle, instead
> of from my service bundle, thus the file is not found and the registration
> fails.
> If I package my WDSL file into the DOSGi bundle, then it works and the web
> service registers properly and publishes my supplied WSDL.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4321) NPE in MEXInInterceptor
[
https://issues.apache.org/jira/browse/CXF-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278650#comment-13278650
]
Richard Opalka commented on CXF-4321:
-
The patch have to be applied to both trunk & 2.5.x-fixes branch
> NPE in MEXInInterceptor
> ---
>
> Key: CXF-4321
> URL: https://issues.apache.org/jira/browse/CXF-4321
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Reporter: Richard Opalka
> Fix For: 2.6.1, 2.5.4
>
> Attachments: CXF-4321.patch
>
>
> 09:59:48,358 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> (http-/127.0.0.1:8080-2) Interceptor for
> {http://example.com}AddNumbersService has thrown exception, unwinding now:
> java.lang.NullPointerException
> at
> org.apache.cxf.ws.mex.MEXInInterceptor.handleMessage(MEXInInterceptor.java:64)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
> at
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
> at
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> [jbossws-spi.jar:2.1.0-SNAPSHOT]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> [jbossweb-7.0.16.Final.jar:]
> at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CXF-4321) NPE in MEXInInterceptor
[
https://issues.apache.org/jira/browse/CXF-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessio Soldano reassigned CXF-4321:
Assignee: Alessio Soldano
> NPE in MEXInInterceptor
> ---
>
> Key: CXF-4321
> URL: https://issues.apache.org/jira/browse/CXF-4321
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Reporter: Richard Opalka
>Assignee: Alessio Soldano
> Fix For: 2.6.1, 2.5.4
>
> Attachments: CXF-4321.patch
>
>
> 09:59:48,358 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> (http-/127.0.0.1:8080-2) Interceptor for
> {http://example.com}AddNumbersService has thrown exception, unwinding now:
> java.lang.NullPointerException
> at
> org.apache.cxf.ws.mex.MEXInInterceptor.handleMessage(MEXInInterceptor.java:64)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
> at
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
> at
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> [jbossws-spi.jar:2.1.0-SNAPSHOT]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> [jbossweb-7.0.16.Final.jar:]
> at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FEDIZ-11) Support for WS-Trust Namespace 2005/02
Oliver Wulff created FEDIZ-11: - Summary: Support for WS-Trust Namespace 2005/02 Key: FEDIZ-11 URL: https://issues.apache.org/jira/browse/FEDIZ-11 Project: CXF-Fediz Issue Type: Bug Components: Plugin Reporter: Oliver Wulff Assignee: Oliver Wulff Fix For: 1.0 Fediz Plugin validates the namespace against WS-Trust 1.3. Microsoft ADFS uses the namespace 2005/02 by default: http://schemas.xmlsoap.org/ws/2005/02/trust -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FEDIZ-11) Support for WS-Trust Namespace 2005/02
[ https://issues.apache.org/jira/browse/FEDIZ-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff updated FEDIZ-11: -- Issue Type: Improvement (was: Bug) > Support for WS-Trust Namespace 2005/02 > -- > > Key: FEDIZ-11 > URL: https://issues.apache.org/jira/browse/FEDIZ-11 > Project: CXF-Fediz > Issue Type: Improvement > Components: Plugin >Reporter: Oliver Wulff >Assignee: Oliver Wulff > Fix For: 1.0 > > > Fediz Plugin validates the namespace against WS-Trust 1.3. > Microsoft ADFS uses the namespace 2005/02 by default: > http://schemas.xmlsoap.org/ws/2005/02/trust -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FEDIZ-11) Support for WS-Trust Namespace 2005/02
[ https://issues.apache.org/jira/browse/FEDIZ-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wulff resolved FEDIZ-11. --- Resolution: Fixed > Support for WS-Trust Namespace 2005/02 > -- > > Key: FEDIZ-11 > URL: https://issues.apache.org/jira/browse/FEDIZ-11 > Project: CXF-Fediz > Issue Type: Improvement > Components: Plugin >Reporter: Oliver Wulff >Assignee: Oliver Wulff > Fix For: 1.0 > > > Fediz Plugin validates the namespace against WS-Trust 1.3. > Microsoft ADFS uses the namespace 2005/02 by default: > http://schemas.xmlsoap.org/ws/2005/02/trust -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4322) Update RequestDispatcherProvider to do the basic discovery of view handlers based on the current class name
Sergey Beryozkin created CXF-4322: - Summary: Update RequestDispatcherProvider to do the basic discovery of view handlers based on the current class name Key: CXF-4322 URL: https://issues.apache.org/jira/browse/CXF-4322 Project: CXF Issue Type: Improvement Components: JAX-RS Reporter: Sergey Beryozkin Assignee: Sergey Beryozkin Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4322) Update RequestDispatcherProvider to do the basic discovery of view handlers based on the current class name
[ https://issues.apache.org/jira/browse/CXF-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278722#comment-13278722 ] Sergey Beryozkin commented on CXF-4322: --- Given the class name such BookInfo, the handler should check by default that the "/WEB-INF/bookInfo.jsp" resource exists. Some variations are also possible > Update RequestDispatcherProvider to do the basic discovery of view handlers > based on the current class name > --- > > Key: CXF-4322 > URL: https://issues.apache.org/jira/browse/CXF-4322 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4322) Update RequestDispatcherProvider to do the basic discovery of view handlers based on the current class name
[ https://issues.apache.org/jira/browse/CXF-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-4322. --- Resolution: Fixed Fix Version/s: 2.4.8 2.5.4 2.6.1 > Update RequestDispatcherProvider to do the basic discovery of view handlers > based on the current class name > --- > > Key: CXF-4322 > URL: https://issues.apache.org/jira/browse/CXF-4322 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Assignee: Sergey Beryozkin >Priority: Minor > Fix For: 2.6.1, 2.5.4, 2.4.8 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4290) Allow user-specified classloader for JAXRSClientFactory
[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278752#comment-13278752
]
Sergey Beryozkin commented on CXF-4290:
---
Chris, can you please download a 2.5.4-SNAPSHOT bundle from
https://builds.apache.org/job/CXF-2.5-deploy/org.apache.cxf$cxf-bundle/ and
test it ? Using the shipped ProxyClassLoader is optional - but may be it can
help in your case too.
> Allow user-specified classloader for JAXRSClientFactory
> ---
>
> Key: CXF-4290
> URL: https://issues.apache.org/jira/browse/CXF-4290
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.5
> Environment: Apache Karaf 2.2.4, CXF 2.5.0
>Reporter: Chris Dolan
>
> I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
> helper exposes this interface as a OSGi service:
> {code}
> public interface JaxRsClientBuilder {
> T createClient(@Nonnull String baseUrl, @Nonnull Class
> resourceApiClass);
> }
> {code}
> However, I discovered a blocking problem. If the user of my helper doesn't
> import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
> exceptions from java.lang.reflect.Proxy because there's no classloader
> anywhere that can see both resourceApiClass and
> org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
> http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
> dynamically make an aggregate classloader that can see both resourceApiClass
> and Client. I think I can trick JAXRSClientFactory into using this new
> classloader for the main resource (by passing in a new Proxy instance as the
> resource class), but I can't wedge my custom classloader in for subresources
> because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
> I request the following as a possible solution. Certainly, I'd accept a
> better solution. For example, it looks like JAX-RS 2.0 should eliminate this
> problem by making Client into a public interface instead of an implementation
> detail.
> 1) add a new method variant to JAXRSClientFactory that takes a classloader
> 2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
> cri.getServiceClass().getClassLoader() or the thread context classloader
> 3) change ClientProxyImpl to save this classloader and use it for
> subresources
> See also the following which describes my failed attempt to work around this
> issue:
> http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4145) Add the ability to restrict what algorithms were used for encryption/signature
[ https://issues.apache.org/jira/browse/CXF-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-4145. --- Resolution: Fixed > Add the ability to restrict what algorithms were used for encryption/signature > -- > > Key: CXF-4145 > URL: https://issues.apache.org/jira/browse/CXF-4145 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Colm O hEigeartaigh >Assignee: Sergey Beryozkin > Fix For: 2.6.1, 2.5.4 > > > This task is to add some functionality on the inbound side to restrict what > algorithms can be used by the client. Examples include the symmetric and Key > Transport algorithms for encryption, and signature/c14n/digest algorithms for > signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4145) Add the ability to restrict what algorithms were used for encryption/signature
[ https://issues.apache.org/jira/browse/CXF-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278754#comment-13278754 ] Sergey Beryozkin commented on CXF-4145: --- We talked with Colm, XML Signature code is invoked in a 'secure' mode which means the signature algorithms will be checked too, which combined with the possibility to set the restricting properties should meet many of the demands. The only thing which is missing then is adding a check similar to the one used by the WS code to do a simplified WSI Basic Security Profile like check, specifically for the encryption algorithms. We can manage this enhancement a bit later on > Add the ability to restrict what algorithms were used for encryption/signature > -- > > Key: CXF-4145 > URL: https://issues.apache.org/jira/browse/CXF-4145 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Colm O hEigeartaigh >Assignee: Sergey Beryozkin > Fix For: 2.6.1, 2.5.4 > > > This task is to add some functionality on the inbound side to restrict what > algorithms can be used by the client. Examples include the symmetric and Key > Transport algorithms for encryption, and signature/c14n/digest algorithms for > signature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4146) Add the ability to use the same Encryption/Signature algorithms as was received
[ https://issues.apache.org/jira/browse/CXF-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278756#comment-13278756 ] Sergey Beryozkin commented on CXF-4146: --- Having the same signature and encryption property beans registered with in and out handlers achieves it. More enhancements are possible in the future, example, when the WSI BP like check is done, the accumulated properties will be passed to the out handlers and reused, thus simplifying the configuration > Add the ability to use the same Encryption/Signature algorithms as was > received > --- > > Key: CXF-4146 > URL: https://issues.apache.org/jira/browse/CXF-4146 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Colm O hEigeartaigh > Fix For: 2.6.1, 2.5.4 > > > This task is to add a boolean switch to allow an endpoint to return > encrypted/signed content to the client using the same algorithms as was > received in the request. This task depends on CXF-4145, to ensure that the > client uses algorithms that are considered acceptable to the endpoint. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4146) Add the ability to use the same Encryption/Signature algorithms as was received
[ https://issues.apache.org/jira/browse/CXF-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-4146. --- Resolution: Fixed Fix Version/s: 2.5.4 2.6.1 Assignee: Sergey Beryozkin > Add the ability to use the same Encryption/Signature algorithms as was > received > --- > > Key: CXF-4146 > URL: https://issues.apache.org/jira/browse/CXF-4146 > Project: CXF > Issue Type: Improvement > Components: JAX-RS Security >Reporter: Colm O hEigeartaigh >Assignee: Sergey Beryozkin > Fix For: 2.6.1, 2.5.4 > > > This task is to add a boolean switch to allow an endpoint to return > encrypted/signed content to the client using the same algorithms as was > received in the request. This task depends on CXF-4145, to ensure that the > client uses algorithms that are considered acceptable to the endpoint. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4321) NPE in MEXInInterceptor
[
https://issues.apache.org/jira/browse/CXF-4321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessio Soldano resolved CXF-4321.
--
Resolution: Fixed
> NPE in MEXInInterceptor
> ---
>
> Key: CXF-4321
> URL: https://issues.apache.org/jira/browse/CXF-4321
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Reporter: Richard Opalka
>Assignee: Alessio Soldano
> Fix For: 2.6.1, 2.5.4
>
> Attachments: CXF-4321.patch
>
>
> 09:59:48,358 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> (http-/127.0.0.1:8080-2) Interceptor for
> {http://example.com}AddNumbersService has thrown exception, unwinding now:
> java.lang.NullPointerException
> at
> org.apache.cxf.ws.mex.MEXInInterceptor.handleMessage(MEXInInterceptor.java:64)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:123)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:207)
> at
> org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:91)
> at
> org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:169)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:185)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:108)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> [jbossws-spi.jar:2.1.0-SNAPSHOT]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
> [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
> [jbossweb-7.0.16.Final.jar:]
> at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
> [jbossweb-7.0.16.Final.jar:]
> at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4323) Should use documented Jetty continuation API
Daniel Kulp created CXF-4323: Summary: Should use documented Jetty continuation API Key: CXF-4323 URL: https://issues.apache.org/jira/browse/CXF-4323 Project: CXF Issue Type: Improvement Components: Transports Affects Versions: 2.6 Reporter: Daniel Kulp Assignee: Daniel Kulp Fix For: 2.6.1 We currently use some of the "raw" async context objects from Jetty to implement the jetty based continuations. However, when running in a "real" jetty server, the default classloader hides those. We should use the documented ContinuationSupport.getContinuation methods to set that up. That will allow use of the continuations when run in a war inside jetty 7.x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4290) Allow user-specified classloader for JAXRSClientFactory
[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278914#comment-13278914
]
Chris Dolan commented on CXF-4290:
--
I think it worked. I need to do a more detailed test, but for right now, I just
renamed it to cxf-bundle-2.5.0.jar and dropped it into my Maven repo, and
commented out my temporary "Import-Package: org.apache.cxf.jaxrs.client" and
everything works.
Nothing breaks, anyway, so I say ship it! :-) Thanks so much, Sergey.
> Allow user-specified classloader for JAXRSClientFactory
> ---
>
> Key: CXF-4290
> URL: https://issues.apache.org/jira/browse/CXF-4290
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.5
> Environment: Apache Karaf 2.2.4, CXF 2.5.0
>Reporter: Chris Dolan
>
> I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
> helper exposes this interface as a OSGi service:
> {code}
> public interface JaxRsClientBuilder {
> T createClient(@Nonnull String baseUrl, @Nonnull Class
> resourceApiClass);
> }
> {code}
> However, I discovered a blocking problem. If the user of my helper doesn't
> import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
> exceptions from java.lang.reflect.Proxy because there's no classloader
> anywhere that can see both resourceApiClass and
> org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
> http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
> dynamically make an aggregate classloader that can see both resourceApiClass
> and Client. I think I can trick JAXRSClientFactory into using this new
> classloader for the main resource (by passing in a new Proxy instance as the
> resource class), but I can't wedge my custom classloader in for subresources
> because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
> I request the following as a possible solution. Certainly, I'd accept a
> better solution. For example, it looks like JAX-RS 2.0 should eliminate this
> problem by making Client into a public interface instead of an implementation
> detail.
> 1) add a new method variant to JAXRSClientFactory that takes a classloader
> 2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
> cri.getServiceClass().getClassLoader() or the thread context classloader
> 3) change ClientProxyImpl to save this classloader and use it for
> subresources
> See also the following which describes my failed attempt to work around this
> issue:
> http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4290) Allow user-specified classloader for JAXRSClientFactory
[
https://issues.apache.org/jira/browse/CXF-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278920#comment-13278920
]
Chris Dolan commented on CXF-4290:
--
Oops, no, I need more testing. My previous test was flawed - I used the wrong
client jar...
> Allow user-specified classloader for JAXRSClientFactory
> ---
>
> Key: CXF-4290
> URL: https://issues.apache.org/jira/browse/CXF-4290
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 2.5
> Environment: Apache Karaf 2.2.4, CXF 2.5.0
>Reporter: Chris Dolan
>
> I wrote a helper class that isolates CXF's JAXRSClientFactory from users. My
> helper exposes this interface as a OSGi service:
> {code}
> public interface JaxRsClientBuilder {
> T createClient(@Nonnull String baseUrl, @Nonnull Class
> resourceApiClass);
> }
> {code}
> However, I discovered a blocking problem. If the user of my helper doesn't
> import org.apache.cxf.jaxrs.client in its OSGi classloader, then I get
> exceptions from java.lang.reflect.Proxy because there's no classloader
> anywhere that can see both resourceApiClass and
> org.apache.cxf.jaxrs.client.Client. I tried a solution (based on
> http://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html) where I
> dynamically make an aggregate classloader that can see both resourceApiClass
> and Client. I think I can trick JAXRSClientFactory into using this new
> classloader for the main resource (by passing in a new Proxy instance as the
> resource class), but I can't wedge my custom classloader in for subresources
> because of the way ClientProxyImpl.invoke() calls JAXRSClientFactory.
> I request the following as a possible solution. Certainly, I'd accept a
> better solution. For example, it looks like JAX-RS 2.0 should eliminate this
> problem by making Client into a public interface instead of an implementation
> detail.
> 1) add a new method variant to JAXRSClientFactory that takes a classloader
> 2) pass this classloader to JAXRSClientFactoryBean, and use it instead of
> cri.getServiceClass().getClassLoader() or the thread context classloader
> 3) change ClientProxyImpl to save this classloader and use it for
> subresources
> See also the following which describes my failed attempt to work around this
> issue:
> http://stackoverflow.com/questions/10458378/how-can-i-make-a-java-lang-reflect-proxy-from-two-separate-classloaders
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4323) Should use documented Jetty continuation API
[ https://issues.apache.org/jira/browse/CXF-4323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved CXF-4323. -- Resolution: Fixed > Should use documented Jetty continuation API > > > Key: CXF-4323 > URL: https://issues.apache.org/jira/browse/CXF-4323 > Project: CXF > Issue Type: Improvement > Components: Transports >Affects Versions: 2.6 >Reporter: Daniel Kulp >Assignee: Daniel Kulp > Fix For: 2.6.1 > > > We currently use some of the "raw" async context objects from Jetty to > implement the jetty based continuations. However, when running in a "real" > jetty server, the default classloader hides those. We should use the > documented ContinuationSupport.getContinuation methods to set that up. That > will allow use of the continuations when run in a war inside jetty 7.x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4324) UriInfo uninjectable
Chris Eineke created CXF-4324:
-
Summary: UriInfo uninjectable
Key: CXF-4324
URL: https://issues.apache.org/jira/browse/CXF-4324
Project: CXF
Issue Type: Bug
Reporter: Chris Eineke
Attachments: uriinfofail.zip
Spring v3.1.1
CXF v2.5.3
Dozer v5.3.2
(see attached project for further versioning details)
I'm using CXF 2.5.3 and Spring 3.1.1.RELEASE with dozer 5.3.2.
My restful service code maps domain objects to transfer objects, but for the
life of me I cannot get UriInfo injected into my dozer custom mappers.
The restful services are request-scoped and produced by several
RequestScopeResourceFactoryS. I'm using CGLIB as the proxy implementation. My
dozer mappers are defined as singletons, same thing for the dozer bean itself.
I've tried the following:
1. @Autowire-annotating a UriInfo instance variable => null.
2. @Context-annotating a UriInfo instance variable => null.
3. Written a UriInfoInjectable interface { @Context public void
setUriInfo(UriInfo value); } and implemented in the service => setter is never
called => null.
4. Tried writing an CXF interceptor that loaded UriInfo into a holder bean
trying to intercept in several different phases and using the three last
approaches => null.
I attached a sample project that exhibits the problem.
1. mvn clean tomcat:run
2. http://localhost:8080/uriinfofail/
Note the TRACE messages saying that uriInfo is null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-4324) UriInfo uninjectable
[
https://issues.apache.org/jira/browse/CXF-4324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Eineke updated CXF-4324:
--
Attachment: uriinfofail.zip
Sample project.
> UriInfo uninjectable
>
>
> Key: CXF-4324
> URL: https://issues.apache.org/jira/browse/CXF-4324
> Project: CXF
> Issue Type: Bug
>Reporter: Chris Eineke
> Labels: cxf, dependency-injection, dozer, spring, uriinfo
> Attachments: uriinfofail.zip
>
>
> Spring v3.1.1
> CXF v2.5.3
> Dozer v5.3.2
> (see attached project for further versioning details)
> I'm using CXF 2.5.3 and Spring 3.1.1.RELEASE with dozer 5.3.2.
> My restful service code maps domain objects to transfer objects, but for the
> life of me I cannot get UriInfo injected into my dozer custom mappers.
> The restful services are request-scoped and produced by several
> RequestScopeResourceFactoryS. I'm using CGLIB as the proxy implementation. My
> dozer mappers are defined as singletons, same thing for the dozer bean
> itself.
> I've tried the following:
> 1. @Autowire-annotating a UriInfo instance variable => null.
> 2. @Context-annotating a UriInfo instance variable => null.
> 3. Written a UriInfoInjectable interface { @Context public void
> setUriInfo(UriInfo value); } and implemented in the service => setter is
> never called => null.
> 4. Tried writing an CXF interceptor that loaded UriInfo into a holder bean
> trying to intercept in several different phases and using the three last
> approaches => null.
> I attached a sample project that exhibits the problem.
> 1. mvn clean tomcat:run
> 2. http://localhost:8080/uriinfofail/
> Note the TRACE messages saying that uriInfo is null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
