I am trying to solve a VRP using google or tools. I use java for my program and everything works fine locally.
After deploying the program on lambda I get an error
java.lang.IllegalArgumentException: Path component should be '/'
2021-08-13T12:40:59.915+04:00 at java.base/sun.nio.fs.UnixFileSystemProvider.checkUri(Unknown Source)
2021-08-13T12:40:59.915+04:00 at java.base/sun.nio.fs.UnixFileSystemProvider.newFileSystem(Unknown Source)
2021-08-13T12:40:59.915+04:00 at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source)
2021-08-13T12:40:59.915+04:00 at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source)
2021-08-13T12:40:59.916+04:00 at com.google.ortools.Loader.unpackNativeResources(Loader.java:88)
2021-08-13T12:40:59.916+04:00 at com.google.ortools.Loader.loadNativeLibraries(Loader.java:106)
this is caused by Loader.loadNativeLibraries() method call.
I built the jar package using maven with shade plugin.
I am using Ubuntu 20.04 if that is related.
I use com.google.ortools:ortools-java
Thank you in advance.
UPDATE :
I manually downloaded native library files and put the full path with System.load(path) . This gave the following error when executing on Lambda
Can't load library: /var/task/src/main/resources/darwin-x86-64/libjniortools.so: java.lang.UnsatisfiedLinkError
java.lang.UnsatisfiedLinkError: Can't load library: /var/task/src/main/resources/darwin-x86-64/libjniortools.so
Related
Current jetty version is 9.4.6, I tried to upgrade 9.4.44, I got the error. Could you please help me?
WebAppContext:554 -Failed startup of context o.e.j.w.WebAppContext#163f1cd{passwd-change,/passwd-change,file:///run/opt/corp/gsec/7.0.0/java-service/gsec-jetty-base/temp/jetty-gsec-2443-passwd-change.war-_passwd-change-any-6326268666909012254.dir/webapp/,UNAVAILABLE}{/passwd-change.war}
Caused by: java.lang.IllegalAccessError: tried to access method org.eclipse.jetty.server.handler.ContextHandler$StaticContext.createInstance(Ljava/lang/Class;)Ljava/lang/Object; from class jetty.webapp.StandardDescriptorProcessor
at org.eclipse.jetty.webapp.StandardDescriptorProcessor.newListenerInstance(StandardDescriptorProcessor.java:1945) ~[apacheds-service-2.0.0-M24.jar:2.0.0-M24]
at org.eclipse.jetty.webapp.StandardDescriptorProcessor.visitListener(StandardDescriptorProcessor.java:1900) ~[apacheds-service-2.0.0-M24.jar:2.0.0-M24]
The jetty files in your apacheds-service-2.0.0-M24.jar needs to be upgraded as well.
List the contents of the apacheds-service-2.0.0-M24.jar file and you'll see classes in the org.eclipse.jetty. namespace.
Those are conflicting with your efforts to upgrade Jetty via the jetty-distribution zip.
I had a different setup that triggered a similar stacktrace: using cargo-maven2-plugin 16.1 in a spring 5 project, mvn cargo:run would fail because of a conflict with javafx.base-11.0.0-SNAPSHOT.jar files.
Upgrading to cargo-maven3-plugin 1.9.9 fixed the matter.
I'd encourage who ever uses cargo-maven2-plugin to migrate to cargo-maven3-plugin as the doc states:
Please be aware that the Maven 2 / Maven 3 plugin of Codehaus Cargo has been retired with our version 1.9.0 and has been superseded by a Maven 3 only plugin.
I have same EAR deployed in JBoss EAP 6.4 in windows and linux env. I am getting below exception in windows but not in linux.
Caused by: java.lang.NoClassDefFoundError: com/bp/gp/addfilters/CMnAddQueryConverter
at com.bp.dw.sales.datacache.CMnDataCacheHelper.getDataSourceCriterion(CMnDataCacheHelper.java:649)
com.bp.dw.sales.datacache.CMnDataCacheHelper.applyFiltersToDataCache(CMnDataCacheHelper.java:429)
com.bp.dw.sales.datacache.CMnDataCacheHelper.applyFiltersToDataCache(CMnDataCacheHelper.java:407)
com.bp.dw.sales.datacache.CMnBaseDataCacheMgr.initiateDataCachePopulate(CMnBaseDataCacheMgr.java:211)
com.bp.dw.sales.datacache.CMnPopulateDataCacheCommand.execute(CMnPopulateDataCacheCommand.java:199)
at com.bp.gp.wb.CMnWorkbookPriceCommand.executeUnit(CMnWorkbookPriceCommand.java:76)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.spawnCache(CMnDataCachePoolMgr.java:628)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.processCache(CMnDataCachePoolMgr.java:571)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.processCache(CMnDataCachePoolMgr.java:537)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:466)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:461)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:456)
com.bp.dw.sales.datacache.pool.CMnDataCachePoolMgr.initiateIncrementalCache(CMnDataCachePoolMgr.java:451)
com.ac.gp.wb.CMnWorkbookWizardComp.actionFinishHook(CMnWorkbookWizardComp.java:367)
com.ui.wizard.CMnWizardComp$4.actionPerformed(CMnWizardComp.java:500)
com.ui.fw.CMnBaseWidgetComp.fireActionListeners(CMnBaseWidgetComp.java:699)
com.ui.fw.CMnBaseRequestComp.fireActionListeners(CMnBaseRequestComp.java:422)
com.ui.fw.CMnBaseWidgetComp$1.clientEvent(CMnBaseWidgetComp.java:92)
com.ui.fw.client.CMnFormClientEventDispatcher.dispatch(CMnFormClientEventDispatcher.java:97)
... 22 more
Caused by: java.lang.ClassNotFoundException: com.bp.gp.addfilters.CMnAddQueryConverter from [Module "deployment.pharma.ear.pharma.war:main" from Service Module Loader]
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
... 41 more
I have jaxb-api.jar, jaxb-impl.jar and jaxb-xjc.jar getting loaded from code but not from JBoss default modules as they are getting used in my code.
Any pointer for the possible cause of this exception?
Regards,
I had two folder with same name in different case and hence the issue.
My EAR had folder structure like:
com.bp.gp.addfilters and com.bp.gp.addFilters.
Looks like, JBoss uses underlying OS's search method to look for folder.
Linux search is case sensitive by default, hence it never gave this error.
Since windows search is case insensitive by default, it was always trying to search inside com.bp.gp.addFilters package whereas the class was present in com.bp.gp.addfilters package.
I am learning Hadoop using the Hadoop for Dummies. I have successfully run thr first steps like installation, creating HDFS and storing Data, running Pig scripts etc.
I have created the FlightsByCarries.jar File.
When I run the code as given in the book, I am getting an error:
[root#localhost totalmiles]# hadoop jar /home/tom/Desktop/totalmiles/FlightsByCarrier.jar FlightsByCarrier /user/root/airline-data/2008.csv /user/root/output/flightsCount
Exception in thread "main" java.lang.ClassNotFoundException: FlightsByCarrier
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:274)
at org.apache.hadoop.util.RunJar.main(RunJar.java:205)
Could someone please help me correct this?
it is because your compiler is not getting your main method in the jar FlightsByCarrier. may be you haven't copy the file to hdfs or your file path is not appropriate...check once..and then try
You JAR file is unable to locate the main class name, if you are using any package name in your main class then specify complete name along with package while running the program.
Ex:
hadoop jar FlightsByCarrier.jar com.dev.FlightsByCarrier /input /output
You can also include main class while creating JAR file.
While creating a JAR file after selecting the path then click next --> asks for selecting main class --> browse the name and select --> click OK
Run the command without class name in this case.
hadoop jar FlightsByCarrier.jar /input /output
Hope this solves your problem.
I'm using the javax.mail library to send emails that may or may not contain attachments.
I'm also using Groovy 2.0.6 for writing this script and am developing it in Eclipse and running unit tests using Gradle 1.5. The script I'm writing will be deployed in a jar to many different locations in the future. Therefore, the javax.mail needs to be referenced to from my script and not just manually added to the machine's classpath.
To do this, I am using the following statements in my script:
#GrabConfig(systemClassLoader=true)
#Grab(group='javax.mail', module='mail', version='1.4.7')
My issue is that I am unable to run unit tests with Gradle while the #GrabConfig statement is included. It runs fine with just the #Grab statement but fails when the #GrabConfig is in there. The error message I'm receiving is:
:compileJava UP-TO-DATE
:compileGroovy
startup failed:
General error during conversion: No suitable ClassLoader found for grab
java.lang.RuntimeException: No suitable ClassLoader found for grab
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:190)
at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:181)
at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown Source)
at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:247)
at groovy.grape.Grape.grab(Grape.java:141)
at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:312)
at org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:319)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:903)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:566)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:542)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:519)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:498)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:118)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:39)
at org.gradle.api.internal.tasks.compile.daemon.CompilerDaemonServer.execute(CompilerDaemonServer.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
1 error
:compileGroovy FAILED
FAILURE: Build failed with an exception.
According to No suitable classloader found for grab , #GrabConfig makes code untestable.
Is there any alternative to #GrabConfig for my situation?
You can use the gradle-one-jar plugin to package your own and third-party code into a single executable Jar. Alternatively, you can use Gradle's application plugin to create a Zip distribution with start scripts.
You can disable grapes in build.gradle like so:
test {
systemProperty 'groovy.grape.enable', 'false'
}
compileGroovy {
groovyOptions.forkOptions.jvmArgs = [ '-Dgroovy.grape.enable=false' ]
}
compileTestGroovy {
groovyOptions.forkOptions.jvmArgs = [ '-Dgroovy.grape.enable=false' ]
}
I am new in jetty. I am trying to run Jetty with IKVM. However, it throws exception. I am not sure what should I do.
alex#AlexUbuntu:/usr/share/jetty$ ikvm -jar start.jar
5 [main] INFO org.mortbay.log - Logging to org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Method.java:
at org.mortbay.start.Main.invokeMain(Main.java:179)
at org.mortbay.start.Main.start(Main.java:508)
at org.mortbay.start.Main.start(Main.java:439)
at org.mortbay.start.Main.main(Main.java:99)
Caused by: cli.System.TypeLoadException: Could not load type 'org.apache.xerces.util.NamespaceSupport' from assembly 'ikvm_dynamic_assembly__40326550, Version=2011.611.1039.16726, Culture=neutral, PublicKeyToken=null'.
at org.apache.xerces.parsers.XIncludeAwareParserConfiguration.<init>(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Constructor.java:517)
at java.lang.Class.newInstance0(Class.java:333)
at java.lang.Class.newInstance(Class.java:320)
at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
at org.mortbay.xml.XmlParser.setValidating(XmlParser.java)
at org.mortbay.xml.XmlParser.<init>(XmlParser.java:68)
at org.mortbay.xml.XmlConfiguration.initParser(XmlConfiguration.java)
at org.mortbay.xml.XmlConfiguration.<init>(XmlConfiguration.java:105)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:958)
... 5 more
It seems that I need to install some external libraries in order to make it works. But what should I need to install.
The environment is fresh and clean:
Ubuntu 11.04
IKVM 0.40.0.1
Java 1.6.0_22
Mono 2.6.7
Update on 28 June 2010
I think I make it works. But I haven't try loading .NET classes in jetty. By the way, I used a dirty method that I replaced /usr/bin/java and /usr/lib/jvm/default-jvm/java with ikvm.exe. So everytime when I type java that actually is IKVM.
I will try to load .NET classes in jetty. But I am not familiar with jetty so I may take sometime.
Update on 1 July 2010
I have tried to load a .NET class. However, finally I got an error message.
HTTP ERROR 500
Problem accessing /hello/servlet. Reason:
ikvmstub generated stubs can only be used on IKVM.NET
Caused by:
java.lang.UnsatisfiedLinkError: ikvmstub generated stubs can only be used on IKVM.NET
at cli.CSharpClass.<init>(Unknown Source)
at HelloServlet.doPost(HelloServlet.java:28)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Can you run Jetty with 'java -jar start.jar'?
I suspect you need at least a few base JAR files for jetty even if it's classloader dynamically loads everything that is needed. It looks like it is failing in the log initialization.
Add the xerces JAR file to the classpath when running IKVM.
ikvm -cp .:xerces.jar -jar startup.jar
Update
I just looked through jetty.sh and there are a few things the script file sets up. You'll need to go through that file and determine what you need out of it, or replace all the instances of java with ikvm and be aware that Jetty also uses tools.jar
The jar files that you generate with ikvmstub are only for the java compiler and not for the runtime. The java compiler can nor work with .NET dlls. For the runtime you need to use the dlls directly.
We use the jetty without problems with IKVM but we use a newer version 0.46. The simplest is you build all jar files in one step with a shared classloader. See the ikvm wiki for details.