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!
Related
I get this error when I start the server. I tried everything but still not sure what the cause is . Please help
Thanks
java.lang.IllegalArgumentException: Failed to instantiate class "org.jboss.logmanager.handlers.PeriodicRotatingFileHandler" for handler "FILE"
at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:119)
at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338)
at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291)
at org.jboss.logmanager.config.LogContextConfigurationImpl.commit(LogContextConfigurationImpl.java:300)
at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:542)
at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97)
at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:300)
at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:262)
at java.util.logging.LogManager$3.run(LogManager.java:399)
at java.util.logging.LogManager$3.run(LogManager.java:396)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396)
at java.util.logging.LogManager.access$800(LogManager.java:145)
at java.util.logging.LogManager$2.run(LogManager.java:345)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338)
at java.util.logging.LogManager.getLogManager(LogManager.java:378)
at org.jboss.modules.Main.main(Main.java:438)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at org.jboss.logmanager.config.AbstractPropertyConfiguration$ConstructAction.validate(AbstractPropertyConfiguration.java:117)
... 17 more
Caused by: java.io.FileNotFoundException: C:\Program Files\wildfly-8.0.0.Final\wildfly-8.0.0.Final\standalone\log\boot.log (The system cannot find the path specified)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:206)
at org.jboss.logmanager.handlers.FileHandler.setFile(FileHandler.java:154)
at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.setFile(PeriodicRotatingFileHandler.java:105)
at org.jboss.logmanager.handlers.FileHandler.setFileName(FileHandler.java:192)
at org.jboss.logmanager.handlers.FileHandler.<init>(FileHandler.java:122)
at org.jboss.logmanager.handlers.PeriodicRotatingFileHandler.<init>(PeriodicRotatingFileHandler.java:73)
... 22 more
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
The main error is this one:
Caused by: java.io.FileNotFoundException: C:\Program Files\wildfly-8.0.0.Final\wildfly-8.0.0.Final\standalone\log\boot.log
Check that the file exists and/or there are no permission restrictions which might stop Java from creating that file.
The final line in your question:
22 more Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
Seems to suggest that WildFly 8.0 is not Java 8 certified. That is, it was not designed to run on Java 8 so, while there is every likelihood that it will start under Java 8, there may be some unexpected behaviour.
I would recommend that, if possible, you either upgrade your WildFly to the latest stable release (8.2 as of this date) or if that isn't possible, downgrade your Java version to 7.
Are you using windows 10?
Similar issue with windows10
If so, try starting the server through the Command Prompt (admin) rather than just normal cmd.
To access this, just right click Start and you will see it.
Thanks,
Ben
I just installed Klocwork plugin for Eclipse. But when I start to scan a project, it gives me the following error:
java.lang.UnsatisfiedLinkError: no sqlite_jni in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at com.klocwork.desktopdb.SqliteJniLoader.initDefaultLibraries(SqliteJniLoader.java:28)
at com.klocwork.desktopdb.SqliteAgent.<clinit>(SqliteAgent.java:21)
at com.klocwork.desktopdb.migration.MigrateDesktopDb.<init>(MigrateDesktopDb.java:48)
at com.klocwork.desktopdb.migration.MigrateDesktopDb.migrate(MigrateDesktopDb.java:44)
at com.klocwork.desktopdb.KwlpProblemsStorageUtil.migrateOrCreateStorage(KwlpProblemsStorageUtil.java:32)
at com.klocwork.kwcheck.commands.AbstractCommand.convertToDB(AbstractCommand.java:82)
at com.klocwork.kwcheck.commands.BuildCommand.execute(BuildCommand.java:110)
at com.klocwork.util.CommandLineParser2.parse(CommandLineParser2.java:360)
at com.klocwork.kwcheck.KwCheckMain.main(KwCheckMain.java:22)
kwcheck: WARNING: Exception occured in java application
Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true -Djava.library.path=".;C:\Program Files (x86)\myLib\win32"
Exception in thread "main"
I found several threads with similar issues:
http://thelogofthewook.blogspot.de/2011/12/updating-problems-myproject-no.html
https://developer.klocwork.com/community/forums/klocwork-general/user-tools/eclipse-plugin-error
They all mentioned some 32bit/64bit issue. But I am using 32bit Eclipse + 32bit JVM.
And as I checked, there are 2 different sqlite_jni.dll files existing in the plugin's lib and lib64 folders respectively. So I guess no file is missing.
So what could be wrong?
Currently, I am trying to troubleshoot it in the following ways:
Figure out how a plugin locates its native libraries.
How to configure java.library.path for a plugin.
A little patience pays off...
I read carefully the error message and it clearly says:
Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
-Djava.library.path=".;C:\Program Files (x86)\myLib\win32"
So I suddenly recall that I once set a environmental variable like this:
_JAVA_OPTIONS = -Djava.net.preferIPv4Stack=true -Djava.library.path=".;C:\Program Files (x86)\myLib\win32"
After I changed it to below, things begin to work.
_JAVA_OPTIONS = -Djava.net.preferIPv4Stack=true
And some background reference:
http://examples.javacodegeeks.com/java-basics/java-library-path-what-is-it-and-how-to-use/
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 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 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.