I'm rewriting a client/server application using Akka 2.2.0, Java 1.7.0_25 and Eclipse Juno.
I had a sample client and server working with Akka 2.0.2.
I updated to the old stable release 2.1.4 and got everything working once again.
I've just moved to the latest stable release 2.2.0.
I created a new package to add some new functionality, leaving the existing code untouched.
Something changed and now I can't launch my test cases.
Here is the stacktrace I see when I try to create an ActorSystem:
Exception in thread "main" java.lang.ClassNotFoundException: [B
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:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at akka.actor.ReflectiveDynamicAccess.getClassFor(DynamicAccess.scala:94)
at akka.serialization.Serialization$$anonfun$4.apply(Serialization.scala:154)
at akka.serialization.Serialization$$anonfun$4.apply(Serialization.scala:153)
at scala.collection.TraversableLike$WithFilter$$anonfun$map$2.apply(TraversableLike.scala:697)
at scala.collection.immutable.HashMap$HashMap1.foreach(HashMap.scala:178)
at scala.collection.immutable.HashMap$HashTrieMap.foreach(HashMap.scala:347)
at scala.collection.TraversableLike$WithFilter.map(TraversableLike.scala:696)
at akka.serialization.Serialization.<init>(Serialization.scala:153)
at akka.serialization.SerializationExtension$.createExtension(SerializationExtension.scala:15)
at akka.serialization.SerializationExtension$.createExtension(SerializationExtension.scala:12)
at akka.actor.ActorSystemImpl.registerExtension(ActorSystem.scala:644)
at akka.actor.ExtensionId$class.apply(Extension.scala:34)
at akka.serialization.SerializationExtension$.apply(SerializationExtension.scala:12)
at akka.remote.RemoteActorRefProvider.init(RemoteActorRefProvider.scala:77)
at akka.actor.ActorSystemImpl._start(ActorSystem.scala:568)
at akka.actor.ActorSystemImpl.start(ActorSystem.scala:575)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:103)
at akka.actor.ActorSystem$.apply(ActorSystem.scala:98)
at akka.actor.ActorSystem$.create(ActorSystem.scala:64)
at akka.actor.ActorSystem.create(ActorSystem.scala)
Its complaining that it can't class load a byte array via the method descriptor style string "[B".
#som-snytt pointed out two bug reports that exactly describe the error I'm seeing.
#paul-vargas called out -Dsun.lang.ClassLoader.allowArraySyntax=true which re-enables the old loadClass behavior.
The allowArraySyntax flag does make the ClassNotFoundException go away but other errors popped up. The errors lead me to believe that something has gone wrong with my Eclipse/m2e/Scala-ide/Akka setup.
I imported the project into Netbeans 7.3 and did a clean and build and it worked on the first try. I didn't even need to set allowArraySyntax.
May you need add the argument to VM:
-Dsun.lang.ClassLoader.allowArraySyntax=true
This won't be news to everyone:
http://bugs.sun.com/view_bug.do?bug_id=6500212
http://bugs.sun.com/view_bug.do?bug_id=6434149
I only looked that up due to #paul-vargas.
I observe that in trunk, ReflectiveDynamicAccess uses Class.forName as the bug report says is recommended. See the code on master.
Possibly, you'll want to upgrade your Akka together with your Java version.
Or, perhaps your production runtime is stuck on 1.5 but you develop on 1.7.
Old akka and scala jars were on the classpath along with the updated versions. Not sure why it caused the above exception but the problem became obvious once Paul pointed out the allowArraySyntax flag.
Related
I recently--as in, today--became interested in learning to program with clojure. Now after having installed the latest version of java's jdk and downloading the leiningen script, I followed the installation instructions for the latter, specifically those given at: http:/www.lispcast.com/clojure-ubuntu.
Now, after the running lein version and downloading the relevant jar file, the program exits with an error about a class not being found. The error in question reads as follows:
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)>
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForName(RT.java:2177)
at clojure.lang.RT.loadClassForName(RT.java:2196)
at clojure.lang.RT.load(RT.java:443)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn__5677.invoke(core.clj:5893)
at clojure.core$load.invokeStatic(core.clj:5892)
at clojure.core$load.doInvoke(core.clj:5876)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core__init.load(Unknown Source)
at clojure.core__init.(Unknown Source)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForName(RT.java:2177)
at clojure.lang.RT.loadClassForName(RT.java:2196)
at clojure.lang.RT.load(RT.java:443)
at clojure.lang.RT.load(RT.java:419)
at clojure.lang.RT.doInit(RT.java:461)
at clojure.lang.RT.(RT.java:331)
at clojure.main.(main.java:20)
Caused by: java.lang.ClassNotFoundException: java/sql/Timestamp
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:375)
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForNameNonLoading(RT.java:2181)
at clojure.instant$loading__5569__auto____6869.invoke(instant.clj:9)
at clojure.instant__init.load(Unknown Source)
at clojure.instant__init.(Unknown Source)
... 23 more
My java 9 jdk is installed in /usr/lib/jvm/java-9-oracle/bin/java, with my JAVA_HOME variable set to /usr/lib/jvm/java-9-oracle but I tried /usr/lib/jvm/java-9-oracle/bin as well, just in case. I am running xubuntu 16.04.3, if this is of any importance. I did try setting the default java jdk back to the openjdk which is bundled with xubuntu but this also was to no avail.
As an aside, the entire problem originated because I tried running the REPL
in intellij after installing the cursive plugin, which didn't work. I then surmised that it might be because I had not installed leiningen beforehand (I thought that the IDE and cursive would have this bundled along). However, the actual information on what intellij and clojure require to run successfully has eluded me, since much of the information is rather 'scattered' and I'm not sure whether I missed something along the way.
In any case, I am having quite a hard time of getting everything to work--probably because I'm not yet that savvy when it comes to these kinds of issues, having only been on a linux distro for a short while as well as being completely unfamiliar with clojure. If I'm missing something obvious, I apologize, but it stands to reason that something can only be obvious once it is shown to be so.
Any and all suggestions will be greatly appreciated.
That looks like a problem caused by Java 9's new concept of "modules": Clojure expects to be able to access java.sql.Timestamp, but it can't. I haven't kept up with Java development or Clojure development, so I can't say for sure that's your problem, but it looks that way to me. Try with an earlier JDK.
If you cant downgrade your JAVA version, run lein upgrade 2.8.1 or the latest Leiningen would do. Leiningen has been updated to include support for Java 9.
When I'm trying to uninstall weblogic in console mod (failure at uninstallation with GUI mode before !) with this command
sh uninstall.sh -mode=console
Below is the exception that I got:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/Layout
at com.bea.plateng.common.util.logging.LogFactory.newLogInstance(LogFactory.java:102)
at com.bea.plateng.common.util.logging.LogFactory.getLog(LogFactory.java:87)
at com.bea.plateng.wizard.WizardController.setupWizardLog(WizardController.java:325)
at com.bea.plateng.wizard.WizardController.<init>(WizardController.java:168)
at com.bea.plateng.wizard.WizardHelper.invokeWizard(WizardHelper.java:161)
at com.bea.plateng.wizard.WizardHelper.invokeWizardAndWait(WizardHelper.java:42)
at com.bea.plateng.wizard.WizardController.main(WizardController.java:933)
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Layout
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 sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
I took google search many times but no luck.
Many thanks for helping me solve this issue.
If your end target is to just uninstall weblogic, you may opt to just manually delete relevant directories. If you wish to stick to script or GUI , you might try to solve log4j issue logically,
Place log4j jar in $DOMAIN_NAME/lib
If uninstall script is looking for log4j that means a java process might be getting called from some other nested script and that is trying to use log4j to write logs. Try to provide log4j jar via -cp command to that process
Do your startWeblogic & stopWeblogic scripts able to use log4j successfully? if yes, try to provide log4j path to uninstall in same way as done in those scripts
You have to mainly figure out as why your uninstall.sh is looking for log4j.
Its hard to answer precisely since these issues are very much machine specific. If you are going with manual delete option, google for steps specific to your OS.
I'm getting the following exception when attempting to use Naming.lookup() to create an RMI object:
java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: project.server.data.RmiMainObjImpl_Stub
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:101)
... 2 more
Caused by: java.lang.ClassNotFoundException: project.server.data.RmiMainObjImpl_Stub
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 sun.rmi.server.LoaderHandler$Loader.loadClass(LoaderHandler.java:1206)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at sun.rmi.server.LoaderHandler.loadClassForName(LoaderHandler.java:1219)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:452)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:185)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:214)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
... 4 more
Curiously, this error only happens under Linux and AIX, but never under Windows. The error happens consistently, but seemingly works under some versions of Java:
The original jar was built with 1.6.0u30 on a Windows machine
The original jar will not work under Linux using 1.7.0u60, but will work with 1.6.0u24
The original jar will not work under AIX using 1.6 64-bit, but will work with 32-bit
Building the jar on a Linux machine using 1.7.0u60 will actually not work with the same runtime on that machine
My policy file seems to be set up correctly and is being recognized (though, I'm guessing I'd have a different error if it was not):
grant {
permission java.security.AllPermission "", "";
};
I'm executing java with a command line similar to this:
java -cp ./.:./JProjApi.jar:./MyRMI.jar -Djava.security.policy=./policy.all com/project/rmi/Main
And the code looks like this:
System.setSecurityManager(new RMISecurityManager());
rmiObj = (project.server.data.RmiMainObj_1_0) Naming.lookup("rmi://172.17.44.45/RMIMain");
I do not have access to the server-side (and I'm consuming a jar that has the necessary client-side interfaces as well).
Any ideas on what might be going wrong?
the stub class [is] not in the client-side jar.
The stub class must be in the client JAR file, unless you're using the codebase feature.
why does the Windows version work?
If it's working on one platform and not others, the stub class is clearly in the CLASSPATH on the platforms where it works, and not in the platforms where it doesn't. Or, if you're using the codebase feature, which you haven't said anything about, the codebase URL isn't accessible from all the platforms.
Figuring this out became a much lower priority, but it came back.
Network scanning showed nothing unusual.
It turned out that it did, in fact, have at least something to do with the Java version or new settings on newer Java versions.
This:
-Djava.rmi.server.useCodebaseOnly=false
Had to be added to the command line and it now works for those machines it didn't previously work on.
I'm getting following exception when open my GWT app in development mode. the exact same code can compile successfully using mvn gwt:compile
Caused by: java.lang.ArrayIndexOutOfBoundsException: 3667 at
com.google.gwt.dev.asm.ClassReader.readClass(ClassReader.java:1976)
at com.google.gwt.dev.asm.ClassReader.accept(ClassReader.java:464)
at com.google.gwt.dev.asm.ClassReader.accept(ClassReader.java:420)
at
com.google.gwt.dev.shell.rewrite.HasAnnotation.hasAnnotation(HasAnnotation.java:45)
at
com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:1100)
at
com.google.gwt.dev.shell.CompilingClassLoader.loadClass(CompilingClassLoader.java:1203)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at
java.lang.Class.forName0(Native Method) at
java.lang.Class.forName(Class.java:247) at
com.google.gwt.dev.shell.ModuleSpace.loadClassFromSourceName(ModuleSpace.java:665)
at
com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:468)
at
com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:49)
at com.google.gwt.core.shared.GWT.create(GWT.java:57) at
com.google.gwt.core.client.GWT.create(GWT.java:85) at ...
I overdid ModuleSpace.java and printed out the class name at line 665 before Class.forName() which points out it is trying to load the generated GinjectorImpl.java
I found out my generated GinjectorImpl.java is about 9MB and with 100K+ lines of code.
When I randomly remove some modules from my GWT app it works again, so I'm guessing it is too large for ASM to compile.
Any suggestions? Thanks
Environment:
GWT 2.5.0, GIN 1.5.0, gwt-maven-plugin 2.5.0, Java 6 SE
Try deleting the gwt-unitCache folder and run a gwt-compile again. This fixed it for me.
Upgrade GIN to 2.0.0 fixed my problem
size of the generated Ginjector.java shrink from 110K+ lines to 23 lines :)
I've got a Java web application (using Spring), deployed with Jetty. If I try to run it on a Windows machine everything works as expected, but if I try to run the same code on my Linux machine, it fails like this:
[normal startup output]
11:16:39.657 INFO [main] org.mortbay.jetty.servlet.ServletHandler$Context.log>(ServletHandler.java:1145) >16> Set web app root system property: 'webapp.root' = [/path/to/working/dir]
java.lang.reflect.InvocationTargetException
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.mortbay.start.Main.invokeMain(Main.java:151)
at org.mortbay.start.Main.start(Main.java:476)
at org.mortbay.start.Main.main(Main.java:94)
Caused by: java.lang.ExceptionInInitializerError
at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:129)
at org.springframework.web.util.Log4jConfigListener.contextInitialized(Log4jConfigListener.java:51)
at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.http.HttpServer.doStart(HttpServer.java:708)
at org.mortbay.util.Container.start(Container.java:72)
at org.mortbay.jetty.Server.main(Server.java:460)
... 7 more
Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category) (Caused by org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category))
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at org.springframework.util.SystemPropertyUtils.(SystemPropertyUtils.java:42)
... 14 more
Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log constructor [Ljava.lang.Class;#15311bd for org.apache.commons.logging.impl.Log4JLogger (Caused by java.lang.NoClassDefFoundError: org/apache/log4j/Category)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:413)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 18 more
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Category
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
... 19 more
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Category
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 24 more
[shutdown output]
I've run the app with java -verbose:class, and according to that output, org.apache.log4j.Category is loaded from the log4j JAR in my /WEB-INF/lib, just before the first exception is thrown.
Now, the Java versions on the two machines are slightly different. Both the machines have Sun's java, the Linux machine has 1.6.0_10, while the Windows machine has 1.6.0_08, or maybe 07 or 06, I can't remember the exact number right now, and don't have the machine at hand. But even though the minor versions of the Javas are slightly different, the code shouldn't break like this. Does anyone understand what's wrong here?
You must understand that a classloader can't see everything; they can only see what a parent classloader has loaded or what they have loaded themselves. So if you have two classloaders, say one for Jetty and another for your webapp, your webapp can see log4j (since the JAR is the WEB-INF/lib) but Jetty's classloader can't.
If you manage to make a class available to Jetty (for example something in the DB layer) which uses log4j but which ends up running in the context (and classloader) of Jetty, you will get an error.
To debug this, set a breakpoint in org.springframework.web.util.Log4jWebConfigurer.initLogging(). If you can, copy the source of this class into your project (don't forget to delete it afterwards) and add this line:
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Have a look at the cl object in your debugger. That should give you some information who created it. My guess is that this is the classloader from Jetty.
[EDIT] Note that you get in a different mess if you have log4j in both classloaders: In this case, you will have two classes with the same name which create objects which are not assignment compatible! So make sure there is only a single instance of this jar or that instances of log4j will never be passed between the two contexts (which is usually not possible).
This seems like a classic classloader problem. It could be due to another web app being loaded first which also uses log4j but a version that is different to the one used by the app you are testing. The classloader uses the first version of the class it finds. The server class loading policy can usually be changed in the config files. Sorry I am a bit rusty on this but maybe it can point you in the correct direction.
Make sure there are no other installed apps on the web server,
Make sure the log4j being loaded is the correct version,
Make sure you don't have a log4j lurking somewhere in the classpath of the server.
HTH
You're using the same WAR on both machines? Have you checked if the WAR files are identical (no transfer errors occured)?
Some random things to consider:
(1) Check if there are any other versions of log4j floating around on the linux instance, outside of the web-app directories?
(2) Is apache commons logging being used at all? You might want to consider SLF4J instead?
(3) Did the JAR/WAR become corrupt in some way - was it FTP'ed in ASCII or Binary?
(4) Print out the classloader hierarchy in each case, just to see if there are any discrepancies?
Even though the original problem was solved for the asker, I'll point out that a common source of problems when running the same code on Windows vs Linux (or Unix) is case-sensitivity issues. Windows ignores case while Linux or Unix is case-sensitive. This has bitten me more than once.
So if you specify a jar or directory on the classpath, but it isn't the right case then it will fail on Linux but succeed on Windows. This can also be the source of FileNotFoundExceptions.
Had the same problem and found an easy solution/workaround:
In Eclipse in Preferences > Java > Installed JREs, select the JRE > Edit and Add External JARs... and browse to your log4j.jar.
The other workaround is to add log4j.jar to every launch definition in Classpath tab.