[jira] [Commented] (CXF-7576) ws-security enonce ecache einstance data not found
[ https://issues.apache.org/jira/browse/CXF-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664832#comment-16664832 ] Vinay Khatri commented on CXF-7576: --- This is mostly on multiple server instances. Where request is initiated by a server instance(and some file is stored in tmp folder), and due to load balancing the response is handled by another server instance. Since a file stored on initiator node is not available here fileNotFoundException occurs. > ws-security enonce ecache einstance data not found > -- > > Key: CXF-7576 > URL: https://issues.apache.org/jira/browse/CXF-7576 > Project: CXF > Issue Type: Bug > Components: JAX-WS Runtime >Affects Versions: 3.1.6 >Reporter: Soumya Panda >Assignee: Colm O hEigeartaigh >Priority: Major > > _Hi Team, > We are seeing a weird issue. It was working fine and nothing change but now > it started failing with below error : > _ > _{color:red}net.sf.ehcache.CacheException: java.io.FileNotFoundException: > /tmp/cxf745201861/ws-security%002enonce%002ecache%002einstance- > {color}_1663277296.data (No such file or directory) > at > net.sf.ehcache.store.disk.DiskStorageFactory.(DiskStorageFactory.java:146) > at net.sf.ehcache.store.disk.DiskStore.create(DiskStore.java:154) > at > net.sf.ehcache.store.disk.DiskStore.createCacheStore(DiskStore.java:182) > at net.sf.ehcache.Cache.initialise(Cache.java:1199) > at > net.sf.ehcache.CacheManager.initializeEhcache(CacheManager.java:1370) > at net.sf.ehcache.CacheManager.addCacheNoCheck(CacheManager.java:1436) > at > net.sf.ehcache.CacheManager.addCacheIfAbsent(CacheManager.java:1936) > at > org.apache.wss4j.common.cache.EHCacheReplayCache.(EHCacheReplayCache.java:54) > at > org.apache.cxf.ws.security.cache.CXFEHCacheReplayCache.(CXFEHCacheReplayCache.java:37) > at > org.apache.cxf.ws.security.wss4j.WSS4JUtils.getReplayCache(WSS4JUtils.java:124) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.getReplayCache(WSS4JInInterceptor.java:776) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.configureReplayCaches(WSS4JInInterceptor.java:413) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:249) > at > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:184) > at > com.sbc.cc.clarify.api.util.cxf.interceptors.security.WebInInterceptor.handleMessage(WebInInterceptor.java:60) > at > com.sbc.cc.clarify.api.util.cxf.interceptors.security.WebInInterceptor.handleMessage(WebInInterceptor.java:19) > 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:251) > at > org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:234) > at > org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:70) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1065) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:798) > _{color:red}Caused by: > java.io.FileNotFoundException: > /tmp/cxf745201861/ws-security%002enonce%002ecache%002einstance-1663277296.data > (No such file or directory){color}_ > at java.io.RandomAccessFile.open(Native Method) > at java.io.RandomAccessFile.(RandomAccessFile.java:253) > at > net.sf.ehcache.store.disk.DiskStorageFactory.allocateRandomAccessFiles(DiskStorageFactory.java:207) > at > net.sf.ehcache.store.disk.DiskStorageFactory
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664837#comment-16664837 ] Romain Manni-Bucau commented on CXF-7361: - On Java 11 with last CXF version, CXFAuthenticator passes. Things changed quite a bit since java 9 so not 100% sure why but I guess while CXF is an unnamed module we are fine. > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7838) Remove illegal reflective access in ReflectionUtil
[ https://issues.apache.org/jira/browse/CXF-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664856#comment-16664856 ] Freeman Fang commented on CXF-7838: --- OK, I can see the {code} WARNING: Illegal reflective access by org.apache.cxf.common.util.ReflectionUtil$11 (file:./lib/cxf-core-3.2.6.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) {code} after I fixed the {code} WARNING: Illegal reflective access by org.apache.cxf.common.util.ReflectionUtil$11 (file:./lib/cxf-core-3.2.6.jar) to field java.net.Authenticator.theAuthenticator {code} And I have a fix on the way... running more test now. Freeman > Remove illegal reflective access in ReflectionUtil > -- > > Key: CXF-7838 > URL: https://issues.apache.org/jira/browse/CXF-7838 > Project: CXF > Issue Type: Task >Reporter: Tim Allison >Assignee: Freeman Fang >Priority: Major > > Apologies if this is a duplicate. We're about to upgrade to 3.2.6 on Apache > Tika, and we're still getting the following when we run our unit tests with > Java 11. > {quote}Illegal reflective access by > org.apache.cxf.common.util.ReflectionUtil$11 > ([file:.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar|file://.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar]) > to field java.net.Authenticator.theAuthenticator > WARNING: Please consider reporting this to the maintainers of > org.apache.cxf.common.util.ReflectionUtil$11 > WARNING: Use --illegal-access=warn to enable warnings of further illegal > reflective access operations > {quote} > Let us know if you need more info to solve this. Thank you! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664861#comment-16664861 ] Freeman Fang commented on CXF-7361: --- Yep, it can pass with {code} WARNING: Illegal reflective access {code} I'm trying to fix the WARNING. CXF-7838 tracked this. I will close this issue for now. > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-7361. --- Resolution: Duplicate > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7361) Java 9,10,11 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-7361: -- Summary: Java 9,10,11 support for CXFAuthenticator (was: Java 9 support for CXFAuthenticator) > Java 9,10,11 support for CXFAuthenticator > - > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory
[ https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665121#comment-16665121 ] ASF GitHub Bot commented on CXF-7883: - gyoetam commented on issue #466: [CXF-7883] fix: handle connectionRequestTimeout in AsyncHTTPConduitFactory URL: https://github.com/apache/cxf/pull/466#issuecomment-433394047 @ffang Thanks for the merge! Do you have a planned release date for 3.2.8 that will include the fix? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Handle connectionRequestTimeout in AsyncHTTPConduitFactory > -- > > Key: CXF-7883 > URL: https://issues.apache.org/jira/browse/CXF-7883 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.6 >Reporter: Györgyey Tamás >Assignee: Freeman Fang >Priority: Major > Labels: pull-request-available > Fix For: 3.3.0, 3.2.7 > > > This issue is a follow-up to CXF-7878. > If connections are contended towards a slow target, it may make sense > to set connectionTimeout and connectionRequestTimeout to values much lower > than > the receiveTimeout. Expected client behavior is to receive an error if a > connection > does not become available within connectionRequestTimeout. Current behavior > however > is that the error is only received after up to receiveTimeout has passed, > when a > current request to the target has finished and the connection is released or > returned > to the pool. > This causes a possible build-up of pending requests in memory for the > duration of receiveTimeout instead of connectionRequestTimeout. > See github PR: [https://github.com/apache/cxf/pull/466] > The reference solution in the PR works well, but it may not be the most > elegant one due to my currently limited understanding of the overall design > of the connection handling code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7884) CXF 3.2.6 creating classes using xjc (WSDL to Java)
Paul Christopher created CXF-7884: - Summary: CXF 3.2.6 creating classes using xjc (WSDL to Java) Key: CXF-7884 URL: https://issues.apache.org/jira/browse/CXF-7884 Project: CXF Issue Type: Task Reporter: Paul Christopher I am trying to figure out how to generate my classes without the JAXBElement and use concreate classes? Loading FrontEnd jaxws ... Loading DataBinding jaxb ... wsdl2java -client -d C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\.cxftmp/src -classdir C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\WebContent\WEB-INF\classes -p http://www.con-way.com/BusinessServices/AP/Invoice/V1=com.xpo.ltl.accountspayable.service.ofsinvoice.ws.client -b C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\api_specification\Schemas\LTLAPI\LTLAccountsPayableAPI\1.0\jaxb-bindings.xml -impl -validate -exsh false -dns false -dex false -wsdlLocation file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl -verbose -fe jaxws -db jaxb -wv 1.1 file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl wsdl2java - Apache CXF 3.2.6 Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped INFO: Operation \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}QueryInvoice cannot be unwrapped, input message must reference global element declaration with same localname as operation Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder checkForWrapped INFO: Operation \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}CreateInvoice cannot be unwrapped, input message must reference global element declaration with same localname as operation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7884) CXF 3.2.6 creating classes using xjc (WSDL to Java)
[ https://issues.apache.org/jira/browse/CXF-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16665736#comment-16665736 ] Freeman Fang commented on CXF-7884: --- Hi Paul, This kind of question should post to us...@cxf.apache.org mailing list but not to jira. Jira ticket is used to track bugs or features. Thanks! Freeman > CXF 3.2.6 creating classes using xjc (WSDL to Java) > --- > > Key: CXF-7884 > URL: https://issues.apache.org/jira/browse/CXF-7884 > Project: CXF > Issue Type: Task >Reporter: Paul Christopher >Priority: Major > > I am trying to figure out how to generate my classes without the JAXBElement > and use concreate classes? > > Loading FrontEnd jaxws ... > Loading DataBinding jaxb ... > wsdl2java -client -d > C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\.cxftmp/src > -classdir > C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\WebContent\WEB-INF\classes > -p > http://www.con-way.com/BusinessServices/AP/Invoice/V1=com.xpo.ltl.accountspayable.service.ofsinvoice.ws.client > -b > C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\api_specification\Schemas\LTLAPI\LTLAccountsPayableAPI\1.0\jaxb-bindings.xml > -impl -validate -exsh false -dns false -dex false -wsdlLocation > file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl > -verbose -fe jaxws -db jaxb -wv 1.1 > file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl > wsdl2java - Apache CXF 3.2.6 > Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder > checkForWrapped > INFO: Operation > \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}QueryInvoice cannot > be unwrapped, input message must reference global element declaration with > same localname as operation > Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder > checkForWrapped > INFO: Operation > \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}CreateInvoice cannot > be unwrapped, input message must reference global element declaration with > same localname as operation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CXF-7884) CXF 3.2.6 creating classes using xjc (WSDL to Java)
[ https://issues.apache.org/jira/browse/CXF-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang closed CXF-7884. - Resolution: Not A Problem > CXF 3.2.6 creating classes using xjc (WSDL to Java) > --- > > Key: CXF-7884 > URL: https://issues.apache.org/jira/browse/CXF-7884 > Project: CXF > Issue Type: Task >Reporter: Paul Christopher >Priority: Major > > I am trying to figure out how to generate my classes without the JAXBElement > and use concreate classes? > > Loading FrontEnd jaxws ... > Loading DataBinding jaxb ... > wsdl2java -client -d > C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\.cxftmp/src > -classdir > C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\WebContent\WEB-INF\classes > -p > http://www.con-way.com/BusinessServices/AP/Invoice/V1=com.xpo.ltl.accountspayable.service.ofsinvoice.ws.client > -b > C:\liberty_development\workspaces\services\CONWAY_SERVICE_ACCOUNTSPAYABLE_REST\api_specification\Schemas\LTLAPI\LTLAccountsPayableAPI\1.0\jaxb-bindings.xml > -impl -validate -exsh false -dns false -dex false -wsdlLocation > file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl > -verbose -fe jaxws -db jaxb -wv 1.1 > file:/C:/liberty_development/workspaces/services/CONWAY_SERVICE_ACCOUNTSPAYABLE_REST/api_specification/Schemas/LTLAPI/LTLAccountsPayableAPI/1.0/OfsInvoicingServices.wsdl > wsdl2java - Apache CXF 3.2.6 > Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder > checkForWrapped > INFO: Operation > \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}QueryInvoice cannot > be unwrapped, input message must reference global element declaration with > same localname as operation > Oct 26, 2018 6:59:00 AM org.apache.cxf.wsdl11.WSDLServiceBuilder > checkForWrapped > INFO: Operation > \{http://www.con-way.com/BusinessServices/AP/Invoice/V1}CreateInvoice cannot > be unwrapped, input message must reference global element declaration with > same localname as operation -- This message was sent by Atlassian JIRA (v7.6.3#76005)