I just installed sunspot gem (latest version) including the embedded solr into my application. When I run "rake sunspot:solr:start" it says the server started, but then I can't connect and I think it dies quietly - I cannot find the log file for it.
So my first question is: Where is the solr log file supposed to be? I checked my app log directory and there was no log there other than the standard development log.
So I did some searching, and ran rake sunspot:solr:run - it throws this error:
java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple
So I did some more searching and everything indicates a classpath issue, but I can't figure out how to fix it, or why it's happening.
Here's the questions that are related:
Exception thrown while using logback/slf4j
Exception thrown while using logback/slf4j/java
I don't have any other entries on the classpath:
$ java -version java version "1.7.0_45" Java(TM) SE Runtime
Environment (build 1.7.0_45-b18) Java HotSpot(TM) 64-Bit Server VM
(build 24.45-b08, mixed mode)
$ echo $CLASSPATH
Prints nothing
and trying to run solr directly didn't give me any more information on where the problem lies:
$ java -jar start.jar -verbose:CLASS --dry-run
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java -verbose:CLASS -Djetty.home=/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr -cp /Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-xml-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/servlet-api-3.0.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-http-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-continuation-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-server-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-security-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-servlet-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-webapp-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-deploy-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-util-8.1.8.v20121106.jar:/Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/lib/jetty-io-8.1.8.v20121106.jar org.eclipse.jetty.xml.XmlConfiguration /var/folders/dm/f2j60c396xl3s7y0jt_mgmvw0000gn/T/start1361372392858055131.properties /Users//.rvm/gems/ruby-2.0.0-p247/gems/sunspot_solr-2.1.0/solr/etc/jetty.xml
Could anyone suggest how to recover from this error?
I found the issue, and it was indeed a classpath problem. Luckily I had an older version of SOLR where it was reporting slf4j was bound twice (but still starting).
So this lead me to where the JAR's were, so I've moved these JAR's out of /Library/Java/Extensions directory which had a copy of them (as well as the lib directory for SOLR I think).
Related
So I am trying out the very very simple spring quickstart. You can find it here.
I have have java 1.8 installed, but am downloading Java 11 in the mean time from the suggested location (AdoptOpenJDK) just to be sure that isn't the problem.
I followed all the instructions, but when running the project, I get... nothing...
~/spring/demo$ java -version
openjdk version "1.8.0_275"
OpenJDK Runtime Environment (build 1.8.0_275-8u275-b01-0ubuntu1~20.04-b01)
OpenJDK 64-Bit Server VM (build 25.275-b01, mixed mode)
~/spring/demo$ ./mvnw spring-boot:run
It has been like this for 30 minutes while I've been typing out this question. There are no logs or anything to suggest what might be wrong.
Any ideas?
UPDATE: I am now getting a zip error within maven. I am still using java 1.8
~/spring/demo$ ./mvnw spring-boot:run
Exception in thread "main" java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:225)
at java.util.zip.ZipFile.<init>(ZipFile.java:155)
at java.util.zip.ZipFile.<init>(ZipFile.java:169)
at org.apache.maven.wrapper.Installer.unzip(Installer.java:169)
at org.apache.maven.wrapper.Installer.createDist(Installer.java:86)
at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:121)
at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:61)
Trenin , Please check whether you have 7Zip/Winzip Software because during startup it looks for these to unzip certain dependencies that it downloads .
I am trying to use Princeton Course specific Java Compiler (javac-algs4) on my windows machine and am seeing this error:
$ javac-algs4
warning: [path] bad path element "/usr/local/lift/lib/algs4.jar": no such file or directory
javac: no source files
This is related to Princeton Algorithms 1 Course. I followed the instructions on installing IntelliJ Idea from https://lift.cs.princeton.edu/java/windows/ and other steps to configure CLASSPATH.
javac and java work ok on HelloWorld programs, but I am expecting javac-algs4 to work for programs that use Course specific libraries.
It seems to me like a Unix Path may be hidden in the JAR file that I`m using in the CLASSPATH, and that may be breaking things for me. (Notice the /usr/local... directory in my error)
What steps could I take to troubleshoot and resolve the error?
Other Version Info:
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-2ubuntu0.18.04.1-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
Javac Version: javac 10.0.2
I have trouble when trying to open my jar files with the following command:
java -jar software.jar
They load until a certain point and then nothing happens.
I deinstalled default-jdk and OpenJDK with synaptic and re-installed it with apt-get, but nothing changed. I had a similar problem one month ago and solved it (apparently only temporarly) by deleting the package gcj-5-jre-lib (5.4.0-6ubuntu1~16.04.4) (Java runtime library for use with gcj (jar files))
The following outputs will help:
java -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11)
OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)
javac -version
1.8.0_131
My variables $JAVA_HOME and $JRE_HOME were correctly added to my $PATH.
I'm on Ubuntu 16.04
EDIT
Here is an example of what I get when I try to start PhyDE.jar
java -jar PhyDE.jar
Welcome to PhyDE 0.9971!
Reading preferences.
Creating PhyDE-Application window
Checking for updates...
You are using the latest version of PhyDE
Done with checking for updates
When checking the core use with the command top I see that the process is active, but the user interface does not open as it usually does. I am located in the folder where the jar file is, and same happens with other jar files.
I built and ran a JAR on machineA as follows:
java -cp /foo/lib/dep1.jar:/foo/lib/dep2.jar:/foo/export/myjar.jar foo.bar.baz.MyMainClass ...
So myjar.jar is the JAR I built and the other two its dependencies. Ran without any issues.
I then wanted to do the same on machineB so I copied the 3 JAR files there, then tried:
/non/default/install/java -cp /bar/dep1.jar:/bar/dep2.jar:/bar/myjar.jar foo.bar.baz.MyMainClass ...
and got Error: Could not find or load main class. (NOTE: /non/default/install/java is a separate java install on machineB that I have to use instead of /usr/bin/java. Reason is "historical", i.e. I have no control over this)
On machineA, java -version gives
java version "1.7.0_91"
OpenJDK Runtime Environment (rhel-2.6.2.2.el6_7-x86_64 u91-b00)
OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)
On machineB, /non/default/install/java -version gives
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
Both machines are running RedHat 6.
Why am I getting the error and how do I fix it?
Thx!
IMPORTANT UPDATE: I ran the commands below from command line on machineA. On machineB I originally ran them using a bash script. This means that I put them into run.bash and then ran bash run.bash from the command line. That's when I got the error. When I reran the same command from command line without using any scripts, it worked. So it seems that the problem had nothing to do with me copying the JAR form one machine to another but rather with the fact that I was invoking them form a script. And so the question really is now: how do I modify run.bash and/or the way I execute it to get rid of the error? (cuz I do need to use a script eventually)
I'm trying to build the new Java bindings of Open MPI (v.openmpi-1.9a1r29661) on Macbook Pro running Mavericks (OSX 10.9). I have the JDK 7 installed:
^_^:examples demirelo $ java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
I configured the OMPI with that command:
./configure --enable-mpi-java --with-platform=optimized --with-jdk-dir=/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home --prefix=/Users/demirelo/libs/openmpi
which is followed by the usual suspect:
make all install
When I tried to run the HelloWorld example, I received the following runtime error:
^_^:examples demirelo $ ../bin/mpijavac Hello.java
^_^:examples demirelo $ ../bin/mpirun -np 1 java Hello
JAVA BINDINGS FAILED TO LOAD REQUIRED LIBRARIES
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
Moreover, the ~/.bash_profile has the correct path to the /lib folder.
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Users/demirelo/libs/openmpi/lib/
It's quite mysterious which libraries failed. Previously, I was able to build slightly older version (openmpi-1.9a1r28578) on Lion and still use it on Mavericks. This time I needed a freshly compiled OMPI but didn't work out. I'm wondering if anyone else had the same issue with Mavericks and was able to fix it.
This appears to be a bug in Open MPI that is comprised of at least two issues:
OMPI is hard-coded to try to dlopen libmpi.so, which is the wrong name on OS X (it should be libmpi.dylib).
Even after I fix that, I'm running into another Java error that I need to run by the Java programmers.
Apparently, we haven't tested the OMPI Java bindings on OS X in a long time. :-(
Such is the life of running against the SVN trunk. Sorry!