I am not very familiar with the Ubuntu. I have moved a jar file relatd to Blazegraph which I used on my Windows machine to my Ubuntu VM (Ubuntu 18.04 LTS Bionic).
I have also used chmod +x filename to make it executable. But when running the file, I get the following error:
ERROR: Banner.java:160: Uncaught exception in thread
java.lang.NullPointerException at
com.bigdata.rdf.sail.webapp.StandaloneNanoSparqlServer.main(StandaloneNanoSparqlServer.java:142)
Why do I get this message? I also found this thread on GitHub, but seems no one had a chance in fixing it!
Note: The file is blazegraph.jar which acts as a local server for the blazegraph so I can run SPARQL queries on some ontologies. Is this because the file is trying to act as a server and possibly firewall issues? However, the server will be at http://localhost:9999/blazegraph/ which I think shouldn't have to do anything with the firewall (if there is any on Linux).
Seems this is a bug with the Blazegraph.
See these links to read more about the problem: [1] [2].
PS: There have been some ways for getting rid of the problem but they did not work for me or I could't make them work. I initially wanted to remove this question but thought maybe others have the same problem.
Related
I created a Play app for students to use in an assignment for my user interface course. They don't need to modify it, just access it via AJAX. I used "activator dist" to package it up in a JAR file; they download it to their computers, unzip it, and run it locally.
It has worked well for everyone except one student. I'm at my wit's end for debugging and am appealing to the community for ideas.
The exception is:
Exception in thread "main" java.lang.NoSuchMethodError: ch.qos.logback.classic.LoggerContext.getFrameworkPackages()Ljava/util/List;
at play.api.Logger$.configure(Logger.scala:268)
at play.api.Logger$.configure(Logger.scala:232)
at play.api.inject.guice.GuiceApplicationBuilder.applicationModule(GuiceApplicationBuilder.scala:73)
at play.api.inject.guice.GuiceBuilder.injector(GuiceInjectorBuilder.scala:126)
at play.api.inject.guice.GuiceApplicationBuilder.build(GuiceApplicationBuilder.scala:93)
at play.api.inject.guice.GuiceApplicationLoader.load(GuiceApplicationLoader.scala:21)
at play.core.server.ProdServerStart$.start(ProdServerStart.scala:52)
at play.core.server.ProdServerStart$.main(ProdServerStart.scala:27)
at play.core.server.ProdServerStart.main(ProdServerStart.scala)
Things we've checked:
He's running Java 1.8.0_45. It was compiled with Java 1.8.0_66. He has reinstalled Java (which I'm assuming is 1.8.0_66 or greater). No change.
The md5 checksum of the download jar file matches the original.
lib/ch.qos.logback.logback-classic-1.1.3.jar exists and has the same size on his machine as on mine.
We've installed scala/Play/Activator on his machine, copied over the sources and tried compiling from scratch on his machine. Same error.
I've looked in the script prepared by "activator dist". I believe it's calling the same version of java as what we see from the command line. That is, I don't think we're being confused by two copies of the java runtime.
This is on a MacBook Pro (pre-Retina) with El Capitan.
Ideas?
When I launch start-dfs.sh in Hadoop 2.2.0 on Mac OS X, buried in the error messages, I have this:
2014-02-24 14:48:23,448 FATAL org.apache.hadoop.hdfs.server.datanode.DataNode: Exception in secureMain
java.lang.InternalError: Can't connect to window server - not enough permissions.
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1833)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1730)
...
I've dealt with this error before - it happens when Java is trying to access the window server (even though it's a command line program). For security reasons, this isn't allowed without a graphical login. This of course means that if you're running a headless server, you have to physically log in before your daemons run.
Now, without going into a rant about how STUPID Java and/or the developers are for doing this (it seems to be a trend; the only other Java server component I use does the same thing), I found the option:
-Djava.awt.headless=true
which looks like a possible solution. But not only do I have no idea where to pass the option to Hadoop, but I tried it on the other software, and it still gives the error.
I'd appreciate any help.
So I tried it, and it turns out there's two things going on. The option DOES in fact work... for Hadoop. But here's where it gets weird:
Hadoop won't append to a log file... if one exists, it leaves it and silently fails to write any logs. So I was looking at old log files.
The other software still doesn't work, but they said they're aware of the bug and they're fixing it.
I fixed it using:
export HADOOP_OPTS="-Djava.security.krb5.realm=OX.AC.UK -Djava.security.krb5.kdc=kdc0.ox.ac.uk:kdc1.ox.ac.uk -Djava.awt.headless=true"
in my bashrc
I followed the instructions on the Datomic site: http://docs.datomic.com/getting-started.html, but I'm getting this error when trying to start up the datomic shell prompt. I'm using a windows machine. Any suggestions? I tried the same thing on my linux box and did not get this error.
Edit: moved to a different windows machine and it's working. If I have time to troubleshoot this problem and I find a solution I'll report back
I noticed that you cannot run the shell.cmd from within the bin directory, you need to call it with bin\shell.cmd from the parent directory... hope that helps.
In case you are using cygwin/bash and call bin/shell :
The java runtime on windows does not understand classpath with a ":"
but this is what you get from bin/classpath.
Either correct this or use DOS-CMD shell and call bin/shell.cmd inside.
Regards
Some tips for running datomic on Windows (7 at least):
Do not download datomic into Program Files. On startup, it creates logging directories and temp files into its own directories, so unless you run the command prompt as Administrator, you're gonna have screens full of Unable to write to file... errors.
You need to run datomic as such (assuming you extracted the download to C:)
c:\datomic-free-0.x.xxxx>bin\shell.cmd
Note the backslash. Tripped me up forever coming from *nix world.
After that, return to your regularly scheduled datomic tutorials.
I'm running 64-bit OpenSUSE 12.1, today I downloaded the latest Scala 2.9.2 from the official website, after unpacking the tgz and go to scala-2.9.2/bin directory, I executed "scala" and got this error message:
[init] error: error while loading <root>, error in opening zip file
Failed to initialize compiler: object scala not found.
** Note that as of 2.8 scala does not assume use of the java classpath.
** For the old behavior pass -usejavacp to scala, or if using a Settings
** object programatically, settings.usejavacp.value = true.
I attempted to run scala -usejavacp but it doesn't help.
I've been using Scala a lot in many other distros and have never got this error before.
My OpenSUSE installation has OpenJDK 6 installed.
Please suggest your opinions, thank you!
I have made the following attempts to solve the problem:
Install Oracle JDK 1.7 and run scala, confirmed that scala REPL reports running in hotspot JVM 1.7, same error occurs.
Installed sbt and run "console" from sbt, same error occurs.
strace and diff the output between sudo scala and scala as normal user, there is no difference except the error message above.
scala -Ylog-classpath as su and normal user, then diff the output, same as above.
disabled AppArmor and tried again, same error message.
Download other scala versions (all of 2.9x, and 2.10 milestone 4), all of their REPL give the same error message.
Made sure fsc is not running before scala REPL runs
Made sure that the hostname is resolvable
well this is a really interesting problem, I'll definitely post a solution if I can luckily find it.
Thanks a lot for your help!
Last edit:
Thanks for everyone here and on reddit (http://www.reddit.com/r/scala/comments/w5s0m/please_help_scala_only_runs_as_root_user_gives/) who offered very valuable suggestions to help me figure out this very strange issue. See my answer below for the solution.
Do not put sbt-launch.jar in your $SCALA_HOME/lib directory, your project's lib directory, or anywhere it will be put on a classpath.
I have just found out the reason:
A closer examination of the output of "strace -f scala" as normal user yields an interesting output:
[pid 11919] open("/usr/lib64/jvm/java-1.6.0-openjdk-1.6.0/jre/lib/ext/gnome-java-bridge.jar", O_RDONLY) = -1 EACCES (Permission denied)
Soon follow that, is the system call to inform user that scala REPL failed to initialize:
[pid 11919] write(1, "\nFailed to initialize compiler: "..., 260
The gnome-java-bridge.jar has permission 400, I changed it to 444 and problem is solved!
The permission issue seems to have been listed as OpenSUSE bug:
http://lists.opensuse.org/opensuse-bugs/2012-07/msg00920.html
It looks like it's not being able to open `scala-library.jar´, or one of the other jar files required for REPL.
You did not say whether scalac works or not. That might give a clue.
At any rate, I'd make sure all of the jar files are a+r, and the directory they are in, as well as all other parent directories, are a+rx.
This is most probably caused by jdk-xxx/jre/lib/ext containing jars that is not readable. Please look for file starting with "."jar and "._jar" and remove them.
I have installed Openoffice.org3 on our server and it's running in headless
mode. We use it with jodconverter to convert word and excell files.
It used to work fine, but one day it just stopped working and I really
don't understand why.
When I run /usr/local/bin/java -jar
jodconverter-2.2.2/lib/jodconverter-cli-2.2.2.jar
on an .xls file to convert it to a .csv file it just gives me:
Exception in thread "main" com.artofsolving.jodconverter.openoffice.connection.OpenOfficeException: conversion failed: could not save output document; OOo errorCode: 3088
If I run jodconverter on a word file, it just gives me an empty
output file, or an other error code. That depends.
Our server have both openoffice 2.4 and 3.0 installed and neither
of the work now. (They both have the same problem) so it's not
directly a problem with the openoffice install.
I even tried to create a new user on the server, and run openoffice as him
but that don't work either.
So does anyone have any idear about what might be wrong, or how I
do get openoffice.org to produce some kind of log file/console outptu,
so I can se whats going on.
I use
/opt/openoffice.org3/program/soffice.bin -headless -nofirststartwizard -accept="socket,host=localhost,port=8100;urp;" &
Sometimes, the soffice is running, but all conversion attempts fail.
My workaround is to run:
Runtime.getRuntime("killtask /IM soffice.bin /F")
To shutdown the OS process. And after this,
Runtime.getRuntime("c:\\path\\start-openoffice-uno.bat").
For what it's worth I'm using OO 3.3.
Well, I ended up deleting both of my old openoffice installs and
installing a new version, and now it's working again. I still don't understand
why it stopped working but sometimes you just have to accept that a
reinstall is a solution.
For me it started working after cleaning up all the files in /tmp related to OpenOffice