[jira] [Created] (CXF-8640) Missing OSGi import javax.xml.ws in cxf bundles
Jan Filipski created CXF-8640: - Summary: Missing OSGi import javax.xml.ws in cxf bundles Key: CXF-8640 URL: https://issues.apache.org/jira/browse/CXF-8640 Project: CXF Issue Type: Bug Components: OSGi Environment: Issue is only visible on JDK9 or higher (where javax.xml.ws package is not present in JDK directly). Can be easily reproduced on Karaf container if you try to install cxf-logging-feature. Reporter: Jan Filipski cxf-rt-features-logging bundle has missing import to javax.xml.ws package. This affects probably all versions. LoggingFeature class has indirect dependency to javax.xml.ws.WebServiceFeature, by extending AbstractFeature. Issue is directly visible, because OSGi Activator calls constructor in start method. That's blocking bundle activation. Probably all bundles with classes extending AbstractFeature has the same issue. Not-so-elegant solution is to add javax.xml.ws package to classpath, imitating JDK8 and lower behavior (as I do for years). Target resolution should be provided by importing required package by cxf bundles. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CXF-8641) NPE on NamePasswordCallbackHandler
Jan Filipski created CXF-8641:
-
Summary: NPE on NamePasswordCallbackHandler
Key: CXF-8641
URL: https://issues.apache.org/jira/browse/CXF-8641
Project: CXF
Issue Type: Bug
Components: Core
Reporter: Jan Filipski
If Basic Auth password is empty, AbstractHTTPDestination sets password to null.
Later, if NamePasswordCallbackHandler is used, it calls String.toCharArray() on
null password.
Standard authentication error should be present, without NullPointerException
Stacktrace looks like that
{code:java}
org.apache.cxf.interceptor.security.AuthenticationException: Authentication
failed: java.lang.NullPointerException
at
org.apache.cxf.interceptor.security.NamePasswordCallbackHandler.handle(NamePasswordCallbackHandler.java:67)
at
java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:904)
at
java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:901)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:901)
at
org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.doLogin(LdapLoginModule.java:49)
at
org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.login(LdapLoginModule.java:37)
at
org.apache.karaf.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:83)
at
java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
at
java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
at
java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
at
java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
at
org.apache.cxf.interceptor.security.JAASLoginInterceptor.handleMessage(JAASLoginInterceptor.java:140)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
at
org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1363)
at
org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:298)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:489)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1278)
at
org.eclipse.jetty.server.handler
[jira] [Assigned] (CXF-8640) Missing OSGi import javax.xml.ws in cxf bundles
[ https://issues.apache.org/jira/browse/CXF-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Yue Fang reassigned CXF-8640: - Assignee: Freeman Yue Fang > Missing OSGi import javax.xml.ws in cxf bundles > --- > > Key: CXF-8640 > URL: https://issues.apache.org/jira/browse/CXF-8640 > Project: CXF > Issue Type: Bug > Components: OSGi > Environment: Issue is only visible on JDK9 or higher (where > javax.xml.ws package is not present in JDK directly). > Can be easily reproduced on Karaf container if you try to install > cxf-logging-feature. >Reporter: Jan Filipski >Assignee: Freeman Yue Fang >Priority: Minor > > cxf-rt-features-logging bundle has missing import to javax.xml.ws package. > This affects probably all versions. > LoggingFeature class has indirect dependency to > javax.xml.ws.WebServiceFeature, by extending AbstractFeature. > Issue is directly visible, because OSGi Activator calls constructor in start > method. That's blocking bundle activation. Probably all bundles with classes > extending AbstractFeature has the same issue. > Not-so-elegant solution is to add javax.xml.ws package to classpath, > imitating JDK8 and lower behavior (as I do for years). Target resolution > should be provided by importing required package by cxf bundles. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CXF-8641) NPE on NamePasswordCallbackHandler
[
https://issues.apache.org/jira/browse/CXF-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang reassigned CXF-8641:
-
Assignee: Freeman Yue Fang
> NPE on NamePasswordCallbackHandler
> --
>
> Key: CXF-8641
> URL: https://issues.apache.org/jira/browse/CXF-8641
> Project: CXF
> Issue Type: Bug
> Components: Core
>Reporter: Jan Filipski
>Assignee: Freeman Yue Fang
>Priority: Major
>
> If Basic Auth password is empty, AbstractHTTPDestination sets password to
> null.
> Later, if NamePasswordCallbackHandler is used, it calls String.toCharArray()
> on null password.
> Standard authentication error should be present, without NullPointerException
> Stacktrace looks like that
> {code:java}
> org.apache.cxf.interceptor.security.AuthenticationException: Authentication
> failed: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.security.NamePasswordCallbackHandler.handle(NamePasswordCallbackHandler.java:67)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:904)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:901)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:901)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.doLogin(LdapLoginModule.java:49)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.login(LdapLoginModule.java:37)
> at
> org.apache.karaf.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:83)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> at
> org.apache.cxf.interceptor.security.JAASLoginInterceptor.handleMessage(JAASLoginInterceptor.java:140)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
> at
> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1363)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:298)
> at
> org.eclipse.jetty.server.handler.
[jira] [Commented] (CXF-8640) Missing OSGi import javax.xml.ws in cxf bundles
[ https://issues.apache.org/jira/browse/CXF-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477901#comment-17477901 ] Freeman Yue Fang commented on CXF-8640: --- Hi [~globalbus], This is expected behaviour per OSGi classloader delegation mechanism. cxf-rt-features-logging bundle imports package org.apache.cxf.feature, and org.apache.cxf.feature.AbstractFeature class which extends javax.xml.ws.WebServiceFeature is in cxf-core bundle, and cxf-core bundle imports javax.xml.ws package. And this works by my test with Karaf+JDK11. If this doesn't work for you, please elaborate the Karaf/CXF version you use, as well as the detailed step to reproduce it. Thanks! Freeman > Missing OSGi import javax.xml.ws in cxf bundles > --- > > Key: CXF-8640 > URL: https://issues.apache.org/jira/browse/CXF-8640 > Project: CXF > Issue Type: Bug > Components: OSGi > Environment: Issue is only visible on JDK9 or higher (where > javax.xml.ws package is not present in JDK directly). > Can be easily reproduced on Karaf container if you try to install > cxf-logging-feature. >Reporter: Jan Filipski >Assignee: Freeman Yue Fang >Priority: Minor > > cxf-rt-features-logging bundle has missing import to javax.xml.ws package. > This affects probably all versions. > LoggingFeature class has indirect dependency to > javax.xml.ws.WebServiceFeature, by extending AbstractFeature. > Issue is directly visible, because OSGi Activator calls constructor in start > method. That's blocking bundle activation. Probably all bundles with classes > extending AbstractFeature has the same issue. > Not-so-elegant solution is to add javax.xml.ws package to classpath, > imitating JDK8 and lower behavior (as I do for years). Target resolution > should be provided by importing required package by cxf bundles. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CXF-8640) Missing OSGi import javax.xml.ws in cxf bundles
[
https://issues.apache.org/jira/browse/CXF-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477970#comment-17477970
]
Jan Filipski commented on CXF-8640:
---
yes, you're right. That's a karaf issue in my own configuration.
Anyway, if someone is looking for issue with stacktrace like that, double check
your configuration at etc/config.properties in
org.osgi.framework.system.packages.extra property. Remainings from karaf 4.1.x
endorsed libs causes a problem.
{code:java}
Caused by: java.lang.ClassNotFoundException: javax.xml.ws.WebServiceFeature
at java.net.URLClassLoader.findClass(URLClassLoader.java:445) ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:587) ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
at
org.apache.felix.framework.ExtensionManager$ExtensionManagerWiring.getClassByDelegation(ExtensionManager.java:1179)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1586)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1516)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:78)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1950)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
at java.lang.ClassLoader.defineClass(ClassLoader.java:1012) ~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2312)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2130)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2064)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1533)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:78)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1950)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
at java.lang.ClassLoader.defineClass(ClassLoader.java:1012) ~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2312)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2130)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2064)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1533)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:78)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1950)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1343)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1586)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1516)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:78)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1950)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
at java.lang.ClassLoader.defineClass(ClassLoader.java:1012) ~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2312)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2130)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2064)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1533)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:78)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1950)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[?:?]
at
org.apache.cxf.ext.logging.osgi.Activator$ConfigUpdater.(Activator.java:59)
~[?:?]
at org.apache.cxf.ext.logging.osgi.Activator.start(Activator.java:44) ~[?:?]
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java
[jira] [Closed] (CXF-8640) Missing OSGi import javax.xml.ws in cxf bundles
[ https://issues.apache.org/jira/browse/CXF-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Filipski closed CXF-8640. - Resolution: Invalid > Missing OSGi import javax.xml.ws in cxf bundles > --- > > Key: CXF-8640 > URL: https://issues.apache.org/jira/browse/CXF-8640 > Project: CXF > Issue Type: Bug > Components: OSGi > Environment: Issue is only visible on JDK9 or higher (where > javax.xml.ws package is not present in JDK directly). > Can be easily reproduced on Karaf container if you try to install > cxf-logging-feature. >Reporter: Jan Filipski >Assignee: Freeman Yue Fang >Priority: Minor > > cxf-rt-features-logging bundle has missing import to javax.xml.ws package. > This affects probably all versions. > LoggingFeature class has indirect dependency to > javax.xml.ws.WebServiceFeature, by extending AbstractFeature. > Issue is directly visible, because OSGi Activator calls constructor in start > method. That's blocking bundle activation. Probably all bundles with classes > extending AbstractFeature has the same issue. > Not-so-elegant solution is to add javax.xml.ws package to classpath, > imitating JDK8 and lower behavior (as I do for years). Target resolution > should be provided by importing required package by cxf bundles. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (CXF-8641) NPE on NamePasswordCallbackHandler
[
https://issues.apache.org/jira/browse/CXF-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Yue Fang resolved CXF-8641.
---
Fix Version/s: 3.4.6
3.5.1
4.0.0
Resolution: Fixed
patch applied on behalf of [~globalbus] with thanks!
> NPE on NamePasswordCallbackHandler
> --
>
> Key: CXF-8641
> URL: https://issues.apache.org/jira/browse/CXF-8641
> Project: CXF
> Issue Type: Bug
> Components: Core
>Reporter: Jan Filipski
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.4.6, 3.5.1, 4.0.0
>
>
> If Basic Auth password is empty, AbstractHTTPDestination sets password to
> null.
> Later, if NamePasswordCallbackHandler is used, it calls String.toCharArray()
> on null password.
> Standard authentication error should be present, without NullPointerException
> Stacktrace looks like that
> {code:java}
> org.apache.cxf.interceptor.security.AuthenticationException: Authentication
> failed: java.lang.NullPointerException
> at
> org.apache.cxf.interceptor.security.NamePasswordCallbackHandler.handle(NamePasswordCallbackHandler.java:67)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:904)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:901)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:901)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.doLogin(LdapLoginModule.java:49)
> at
> org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.login(LdapLoginModule.java:37)
> at
> org.apache.karaf.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:83)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> at
> org.apache.cxf.interceptor.security.JAASLoginInterceptor.handleMessage(JAASLoginInterceptor.java:140)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:225)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:763)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
> at
> org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1618)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
> at
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1610)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.jav
[jira] [Created] (CXF-8642) ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1
Florian Kamella created CXF-8642: Summary: ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1 Key: CXF-8642 URL: https://issues.apache.org/jira/browse/CXF-8642 Project: CXF Issue Type: Bug Components: JAX-RS Affects Versions: 3.4.1 Reporter: Florian Kamella Starting with version cxf version 3.4.1 Response.hasEntitiy() does return false after a call to Response.readEntity() threw an exception, even when Response.bufferEntity() was called before. Response response = // obtain response with an entity from service call response.bufferEntity() response.hasEntity() // true response.readEntity(SomeWrongEntityClass.class) // throws an exception response.hasEntity() //false I created a github repository with ready-to-run sample code to show the issue https://github.com/cowclaw/cxf-regression Simply clone the repository and run ./gradlew build to see it in action. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8642) ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1
[ https://issues.apache.org/jira/browse/CXF-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8642: -- Affects Version/s: 3.4.5 3.5.0 > ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1 > > > Key: CXF-8642 > URL: https://issues.apache.org/jira/browse/CXF-8642 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.0, 3.4.1, 3.4.5 >Reporter: Florian Kamella >Assignee: Andriy Redko >Priority: Major > > Starting with version cxf version 3.4.1 Response.hasEntitiy() does return > false after a call to Response.readEntity() threw an exception, even when > Response.bufferEntity() was called before. > Response response = // obtain response with an entity from service call > response.bufferEntity() > response.hasEntity() // true > response.readEntity(SomeWrongEntityClass.class) // throws an exception > response.hasEntity() //false > I created a github repository with ready-to-run sample code to show the issue > https://github.com/cowclaw/cxf-regression > Simply clone the repository and run ./gradlew build to see it in action. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8642) ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1
[ https://issues.apache.org/jira/browse/CXF-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8642: -- Fix Version/s: 3.4.6 3.5.1 4.0.0 > ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1 > > > Key: CXF-8642 > URL: https://issues.apache.org/jira/browse/CXF-8642 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.0, 3.4.1, 3.4.5 >Reporter: Florian Kamella >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.6, 3.5.1, 4.0.0 > > > Starting with version cxf version 3.4.1 Response.hasEntitiy() does return > false after a call to Response.readEntity() threw an exception, even when > Response.bufferEntity() was called before. > Response response = // obtain response with an entity from service call > response.bufferEntity() > response.hasEntity() // true > response.readEntity(SomeWrongEntityClass.class) // throws an exception > response.hasEntity() //false > I created a github repository with ready-to-run sample code to show the issue > https://github.com/cowclaw/cxf-regression > Simply clone the repository and run ./gradlew build to see it in action. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CXF-8642) ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1
[ https://issues.apache.org/jira/browse/CXF-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko reassigned CXF-8642: - Assignee: Andriy Redko > ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1 > > > Key: CXF-8642 > URL: https://issues.apache.org/jira/browse/CXF-8642 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.4.1 >Reporter: Florian Kamella >Assignee: Andriy Redko >Priority: Major > > Starting with version cxf version 3.4.1 Response.hasEntitiy() does return > false after a call to Response.readEntity() threw an exception, even when > Response.bufferEntity() was called before. > Response response = // obtain response with an entity from service call > response.bufferEntity() > response.hasEntity() // true > response.readEntity(SomeWrongEntityClass.class) // throws an exception > response.hasEntity() //false > I created a github repository with ready-to-run sample code to show the issue > https://github.com/cowclaw/cxf-regression > Simply clone the repository and run ./gradlew build to see it in action. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CXF-8642) ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1
[ https://issues.apache.org/jira/browse/CXF-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478294#comment-17478294 ] Andriy Redko commented on CXF-8642: --- Thank you for reporting it, [~cowclaw] , the regression was introduced while implementing TCK compliant behavior: the `hasEntity()` now ensures that the entity stream is not empty. However in your case, the entity stream is not empty but is fully consumed and the `hasEntity()` mistaken this fact with the empty stream. > ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1 > > > Key: CXF-8642 > URL: https://issues.apache.org/jira/browse/CXF-8642 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.0, 3.4.1, 3.4.5 >Reporter: Florian Kamella >Assignee: Andriy Redko >Priority: Major > Fix For: 3.4.6, 3.5.1, 4.0.0 > > > Starting with version cxf version 3.4.1 Response.hasEntitiy() does return > false after a call to Response.readEntity() threw an exception, even when > Response.bufferEntity() was called before. > Response response = // obtain response with an entity from service call > response.bufferEntity() > response.hasEntity() // true > response.readEntity(SomeWrongEntityClass.class) // throws an exception > response.hasEntity() //false > I created a github repository with ready-to-run sample code to show the issue > https://github.com/cowclaw/cxf-regression > Simply clone the repository and run ./gradlew build to see it in action. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CXF-8642) ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1
[ https://issues.apache.org/jira/browse/CXF-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andriy Redko updated CXF-8642: -- Labels: response (was: ) > ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1 > > > Key: CXF-8642 > URL: https://issues.apache.org/jira/browse/CXF-8642 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.0, 3.4.1, 3.4.5 >Reporter: Florian Kamella >Assignee: Andriy Redko >Priority: Major > Labels: response > Fix For: 3.4.6, 3.5.1, 4.0.0 > > > Starting with version cxf version 3.4.1 Response.hasEntitiy() does return > false after a call to Response.readEntity() threw an exception, even when > Response.bufferEntity() was called before. > Response response = // obtain response with an entity from service call > response.bufferEntity() > response.hasEntity() // true > response.readEntity(SomeWrongEntityClass.class) // throws an exception > response.hasEntity() //false > I created a github repository with ready-to-run sample code to show the issue > https://github.com/cowclaw/cxf-regression > Simply clone the repository and run ./gradlew build to see it in action. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (CXF-8642) ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1
[ https://issues.apache.org/jira/browse/CXF-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17478294#comment-17478294 ] Andriy Redko edited comment on CXF-8642 at 1/19/22, 2:11 AM: - Thank you for reporting it, [~cowclaw] , the regression was introduced while implementing TCK compliant behavior: the `hasEntity()` now ensures that the entity stream is not empty. However in your case, the entity stream is not empty but is fully consumed with an exception and the `hasEntity()` mistaken this fact with the empty stream. was (Author: reta): Thank you for reporting it, [~cowclaw] , the regression was introduced while implementing TCK compliant behavior: the `hasEntity()` now ensures that the entity stream is not empty. However in your case, the entity stream is not empty but is fully consumed and the `hasEntity()` mistaken this fact with the empty stream. > ResponseImpl#hasEntity changed behaviour starting with cxf 3.4.1 > > > Key: CXF-8642 > URL: https://issues.apache.org/jira/browse/CXF-8642 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.5.0, 3.4.1, 3.4.5 >Reporter: Florian Kamella >Assignee: Andriy Redko >Priority: Major > Labels: response > Fix For: 3.4.6, 3.5.1, 4.0.0 > > > Starting with version cxf version 3.4.1 Response.hasEntitiy() does return > false after a call to Response.readEntity() threw an exception, even when > Response.bufferEntity() was called before. > Response response = // obtain response with an entity from service call > response.bufferEntity() > response.hasEntity() // true > response.readEntity(SomeWrongEntityClass.class) // throws an exception > response.hasEntity() //false > I created a github repository with ready-to-run sample code to show the issue > https://github.com/cowclaw/cxf-regression > Simply clone the repository and run ./gradlew build to see it in action. -- This message was sent by Atlassian Jira (v8.20.1#820001)
