I began looking into lisp recently, and installed Counterclockwise with Eclipse.
Then, hating the fact that the 1.2 version is built in, I manually linked the 1.3 library into it (not very difficult honestly)...
Then I noticed that each time I run a new REPL session, the first command always makes a bunch of errors show up, with no effect on the session itself. At the same time, all following commands work fine.
It's only a minor annoyance, but still pretty unnerving. I've tested it with 1.2 (built in version) by reversing the changes I made, but that didn't help.
Here is the long list of Eclipse Console output (there are 6 more, but eclipse didn't write them, I might go and try to simulate the same inside of a cmd, but please tell me if it's necessary 1st)
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at clojure.tools.nrepl$handle_response.invoke(nrepl.clj:265)
at clojure.tools.nrepl$message_dispatch$fn__181.invoke(nrepl.clj:305)
at clojure.lang.AFn.call(AFn.java:18)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at clojure.core$refer.doInvoke(core.clj:3775)
at clojure.lang.RestFn.applyTo(RestFn.java:139)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$load_lib.doInvoke(core.clj:5252)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:602)
at clojure.core$load_libs.doInvoke(core.clj:5271)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:604)
at clojure.core$use.doInvoke(core.clj:5363)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.main$repl.doInvoke(main.clj:258)
at clojure.lang.RestFn.invoke(RestFn.java:1096)
at clojure.tools.nrepl$handle_request.invoke(nrepl.clj:240)
at clojure.lang.Var.invoke(Var.java:409)
at clojure.tools.nrepl$message_dispatch$fn__181$fn__184.invoke(nrepl.clj:302)
... 6 more
Edit: There's a chance this may be linked to namespaces
(ns Something)
even if nothing in the file is actually used.
Post an issue on the google code page here: http://code.google.com/p/counterclockwise/issues/list
and send email to the google group here: http://groups.google.com/group/clojuredev-users?pli=1
It looks like a namespace name problem.
I can generate this error easily on ccw 0.5.0.STABLE002:
1) I create a new project using wizard: File->New->Project..->Clojure Project
2) I create file core.clj in src folder
3) I change namespace name.
After running REPL for the file core.clj I get the same exception.
I found this problem after creating project with lein with the name containing HYPEN "-"
When I use project name with hypen then package names are created with underscore "_". After calling lein eclipse (:dev-dependencies [[lein-eclipse "1.0.0"]]) project clould be imported properly to eclipse. REPL works perfect. But it is not possible to compile project with lein. For this hypen in namespace name have to be changed to underscore. After the change compilation with lein became possible but REPL in ccw started generating not well described exception enclosed by you in the question.
My advice after this experience do not use hypens or underscores in project names.
Related
I know this might be difficult to answer, but I have tried everything and cannot get a solution. I am trying to create a web project in Java for the first time, using Eclipse and Jetty and JSF, and everything works well until I introduce a Java class. I write in HTMl/XHTML and run the programs, but when I add a Java class - even with nothing in the class, I get the following exceptions:
java.lang.RuntimeException: Error scanning file C:\Users\****\eclipse-workspace\donationFinder\target\classes\com\testingClass\Test.class
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:783)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:876)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:165)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:552)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.base/java.lang.Thread.run(Thread.java:835)
Caused by:
java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.objectweb.asm.ClassReader.<init>(Unknown Source)
at org.eclipse.jetty.annotations.AnnotationParser.scanClass(AnnotationParser.java:986)
at org.eclipse.jetty.annotations.AnnotationParser.parseDir(AnnotationParser.java:777)
at org.eclipse.jetty.annotations.AnnotationParser.parse(AnnotationParser.java:876)
at org.eclipse.jetty.annotations.AnnotationConfiguration$ParserTask.call(AnnotationConfiguration.java:165)
at org.eclipse.jetty.annotations.AnnotationConfiguration$1.run(AnnotationConfiguration.java:552)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.base/java.lang.Thread.run(Thread.java:835)
Does anyone know what might be causing this? Thanks in advance.
The version of asm you are using is too old for your JVM runtime.
For Jetty 9.4.x you should be using (at least) asm-7.1.jar if you want to scan bytecode produced for Java 8 thru Java 13.
Use asm-7.2.jar if you want to scan bytecode produced for Java 8 thru 14.
Use asm-7.3.1.jar if you want to scan bytecode produced for Java 8 thru 15.
See prior answer for details.
https://stackoverflow.com/a/26496604/775715
All I did was download wildfly-8.1.0.CR2 and extract it. standalone.bat and add-user.bat work but jboss-cli.bat does not.
F:\wildfly-8.1.0.CR2\bin>jboss-cli
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no jansi64-1.9 in
java.library.path, no jansi-1.9 in java.library.path, no jansi in java.library.path,
D:\pgarner\AppData\Local\Temp\jansi-64-1.9.dll: The application has failed to start
because its side-by-side configuration is incorrect. Please see the application event
log or use the command-line sxstrace.exe tool for more detail]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:184)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:142)
at org.fusesource.jansi.internal.Kernel32.<clinit>(Kernel32.java:37)
at org.fusesource.jansi.WindowsAnsiOutputStream.<clinit>(WindowsAnsiOutputStream.java:52)
at org.jboss.aesh.terminal.WindowsTerminal.init(WindowsTerminal.java:53)
at org.jboss.aesh.console.Console.setTerminal(Console.java:193)
at org.jboss.aesh.console.Console.reset(Console.java:154)
at org.jboss.aesh.console.Console.<init>(Console.java:105)
at org.jboss.aesh.console.Console.<init>(Console.java:101)
at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:85)
at org.jboss.as.cli.impl.Console$Factory.getConsole(Console.java:78)
at org.jboss.as.cli.impl.CommandContextImpl.initBasicConsole(CommandContextImpl.java:349)
at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:296)
at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76)
at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:273)
at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.jboss.modules.Module.run(Module.java:312)
at org.jboss.modules.Main.main(Main.java:460)
Press any key to continue . . .
When I start up Wildfly using standalone.bat I see the following entry for java.library.path in server.log:
java.library.path = F:\Java\jdk1.7.0_45\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;F:\WANdisco\uberSVN\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;F:\GnuPG\pub;F:\7-Zip;"E:\WebTest\build\bin";F:\WANdisco\uberSVN\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;F:\GnuPG\pub;F:\7-Zip;.
The following file does indeed appear on my file system when I attempt to run jboss-cli:
D:\pgarner\AppData\Local\Temp\jansi-64-1.9.dll
I also tried using wildfly-8.0.0.Final instead of wildfly-8.1.0.CR2 and the same exact problem happened.
How to resolve this problem? I assumed the CLI should just work right out of the box after extracting all the files out of the zip file.
We're facing the same error and the problem is due to the jansi dll dependencies. In fact you need to install the Microsoft Visual C++ 2008 Redistributable Package corresponding to your platform. For x64, you can follow this link :
http://www.microsoft.com/en-US/download/details.aspx?id=2092
Have a similar problem. I can start Wildfly and deploy my application without errors, but everytime I redeploy my application, I get the following error:
Caused by:
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no
jansi64-1.9 in java.library.path, no jansi-1.9 in java.library.path,
no jansi in java.library.path, Native Library
C:\Users\zb\AppData\Local\Temp\jansi-64-1.9.dll already loaded in
another classloader]
It seems this jansi library is stuck after deploy.
Restarting the server helps temporarily.
I am trying to run Scalding sample word count example. I have followed this github link for steps:-
https://github.com/twitter/scalding/wiki/Getting-Started
But I am getting ClassNotFoundException. Below is my StackTrace:-
[cloudera#localhost scalding-develop]$ **sudo scripts/scald.rb --local WordCount --input input.txt --output ./someOutputFile.tsv**
can not find /root/.sbt/boot/scala-2.9.3/lib/scala-library.jar appending SBT_VERSION [0.12.0] to SBT_HOME
scripts/scald.rb:139: warning: already initialized constant SBT_HOME
scripts/scald.rb:140: warning: already initialized constant SCALA_LIB_DIR
Exception in thread "main" java.lang.Throwable: If you know what exactly caused this error, please consider contributing to GitHub via following link.
https://github.com/twitter/scalding/wiki/Common-Exceptions-and-possible-reasons#javalangclassnotfoundexception
at com.twitter.scalding.Tool$.main(Tool.scala:146)
at com.twitter.scalding.Tool.main(Tool.scala)
Caused by: java.lang.ClassNotFoundException: WordCount
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:188)
at com.twitter.scalding.Job$.apply(Job.scala:39)
at com.twitter.scalding.Tool.getJob(Tool.scala:49)
at com.twitter.scalding.Tool.run(Tool.scala:69)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
at com.twitter.scalding.Tool$.main(Tool.scala:132)
... 1 more
Please let me know where exactly is the issue?
Thanks.
Check if your JDK's bin directory is there in your PATH. I had a similar issue and I had use update-alternatives to install java but had not included /usr/lib/jvm/jdk-1.7.0/bin in my PATH.
Check - Running your Scalding jobs in Eclipse article at
http://hokiesuns.blogspot.co.uk/2012/07/running-your-scalding-jobs-in-eclipse.html
Using Maven for Scalding should be your first step into this new brave world.
After a few months give sbt a try and see if you like it
Don't go directly to sbt as its usage is not that trivial
I suggest not using scald.rb.
Instead use sbt, check this github repo, https://github.com/deanwampler/activator-scalding. It includes all the necessary basic setup.
I am learning the Jena API and I want to use Schemagen to create the classes that look like in the package com.hp.hpl.jena.vocabulary for my own vocabulary;
I donwloaded Jena at http://www.apache.org/dist/incubator/jena/apache-jena-2.7.0-incubating/. Once downloaded I unzipped it and leave it as it is.
C:\Users\moi\NetBeansProjects\apache-jena-2.7.0-incubating\apache-jena-2.7.0-incubating
is the folder where there is the bat folder, the bin folder, the javadoc-arq folder etc.
I tested Jena in one of my project using all the libraries in C:\Users\moi\NetBeansProjects\apache-jena-2.7.0-incubating\apache-jena-2.7.0-incubating\lib with a relative link, and it works.
To make it simple to use in the command line I moved my file "MyKnowledgeBase.rdf" in the lib folder.
I tried from the lib folder
java jena.schemagen -i "myKnowledgeBase.rdf"
and get this
Exception in thread "main" java.lang.NoClassDefFoundError: jena/schemagen
Caused by: java.lang.ClassNotFoundException: jena.schemagen
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: jena.schemagen. Program will exit.
So I tried to set the classpath :
C:\Users\moi\NetBeansProjects\apache-jena-2.7.0-incubating\apache-jena-2.7.0-incubating\lib>
set CLASSPATH=commons-codec-1.5.jar;httpclient-4.1.2.jar;httpcore-4.1.3.jar;icu4j3.4.4.jar;jena.arq-2.9.0-incubating.jar;jena.core-2.7.0-incubating.jar;jena.iri0.9.0-incubating.jar;log4j-1.2.16.jar;slf4j-api-1.6.4.jar;slf4j-log4j12-1.6.4.jar;xercesImpl-2.10.0.jar; xml-apis-1.4.01.jar;
But I have still the same error. I also tried with
java -cp commons-codec-1.5.jar;httpclient-4.1.2.jar;httpcore-4.1.3.jar;icu4j3.4.4.jar;jena.arq-2.9.0-incubating.jar;jena.core-2.7.0-incubating.jar;jena.iri0.9.0-incubating.jar;log4j-1.2.16.jar;slf4j-api-1.6.4.jar;slf4j-log4j12-1.6.4.jar;xercesImpl-2.10.0.jar; xml-apis-1.4.01.jar; jena.schemagen -i myKnowledgeBase.rdf
when I do
echo %CLASSPATH%
I get what I entered
I tried to use set CLASSPATH with the absolute path for each jar and it doesn't work too.
So now I don't know what to do.
In Jena I found the schemagen.class in the package "jena" from the jena-core-2.7.0-incubating.jar (with netbeans)
With explorer I didn't find the class file.
I already run several projects in the command line doing java -jar so java and the command line is ok
Thank you for your help
Edit :
I removed the space between the argument -classpath and %CLASSPATH% and I get something different \o/ still doesn't work but it's in progress !
"Unrecognized option" and "Could not create the java virtual machine"
Edit2 :
As I was unable to solve this I created a new project with netbeans. I created a copy of schemagen class, put it as the main class, include all the jar as libraries.
and then :
java -jar "C:\Users\moi\NetBeansProjects\MyJena\dist\MyJena.jar" -i "myKnowledgeBase.rdf" -o "C:\Users\moi\NetBeansProjects\apache-jena-2.7.0-incubating\apache-jena-2.7.0-incubating\lib" --ontology
In all recent releases, including Jena 2.7.0, Linux shell and Windows batch scripts are provided for all of the Jena command line tools. These scripts set the CLASSPATH appropriately. Since you seem to be using Windows, you should use bat\schemagen.bat.
I had the same problem.I 'm using Jena 3.10
if anyone having the same problem , the solution for this is using schemagen bat file that located in the bat folder.
I used this command line for generating the vocabulary
C:\Jena\apache-jena-3.10.0\bat\schemagen.bat -i "FileName"
I'm on windows XP using eclipse and the datanucleus enhancer for a gwt + gae app. When I run the enhancer, I get an error:
Error
Thu Oct 21 16:33:57 CDT 2010
Cannot run program "C:\Program Files\Java\jdk1.6.0_18\bin\javaw.exe" (in directory "C:\ag\dev"): CreateProcess error=87, The parameter is incorrect
java.io.IOException: Cannot run program "C:\Program Files\Java\jdk1.6.0_18\bin\javaw.exe" (in directory "C:\ag\dev"): CreateProcess error=87, The parameter is incorrect
at java.lang.ProcessBuilder.start(Unknown Source)
at com.google.gdt.eclipse.core.ProcessUtilities.launchProcessAndActivateOnError(ProcessUtilities.java:213)
at com.google.appengine.eclipse.core.orm.enhancement.EnhancerJob.runInWorkspace(EnhancerJob.java:154)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.io.IOException: CreateProcess error=87, The parameter is incorrect
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.<init>(Unknown Source)
at java.lang.ProcessImpl.start(Unknown Source)
... 5 more
I've had this problem before, and it was due to a long classpath. I just spent an hour and a half shortening my classpath by moving libraries around and even moving my eclipse install, but with no luck.
Any ideas about where I should start to look for an answer? The error message doesn't include any information about what directory it's in or anything. It's kind of infuriating! Is it possible to make the output of javaw more verbose? Is it possible to get around this class-path size bug?
Aha!
Under Project properties > Google > App Engine > ORM I found that all of my classes were being enhanced, which was leading to a command line that was too long - nothing to do with the classpath, apparently. I just configured that property page to only enhance a subset of my classes (only like 5% need enhancing), and now, not only does it work again, but the build process is WAY FASTER!