I'm using sevenZipJBinding to uncompress a .tar file in dynamic web project i put their jar in my project and when I run it i get this error:
java.lang.NoClassDefFoundError: net/sf/sevenzipjbinding/IInStream
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:111)
What does it mean ?
And how to fix it ?
This means that the method invoke in the class com.sun.faces.facelets.el.TagMethodExpression uses the class or interface net.sf.sevenzipjbinding.IInStream at line 111 of the source file it was compiled from (TagMethodExpression.java), but the classloader is unable to find that class now (it's probably missing), even though it was probably present at compile time (unless someone edited the bytecode manually).
I'm not sure if that's what you wanted to know, but it definitely is what you asked for.
Related
I'm a n00b coder. I found an interesting library and trying to start toying with it. Which is not going great. This library is from 99' and uses JUnit (which I'm unfamiliar with) so there is a lot of confusing stuff. But it seems like the source of my failing even more elementary. Namely I have troubles importing packages.
This library has a test called StandardEvalTest.java. I moved to it to main Java directory and now I'm trying and failing to launch it using JUnit.
This package path org.pokersource.game.Deck goes directly from the directory where the test StandardEvalTest.java sits.
I also added the main java directory to the PATH environmental variable. Which as I assumed will allow import to locate the package.
None of those two things help. Also I was suspecting that maybe Deck.java and Deck.class are not enough and I have to do some work to create a package from it. But as far as I can say from Oracle doc the only thing needed is a package name in the header. Which seems to be present.
So I'm out of moves. Please help!
PS: Some additional info inspired by #Dhrubo 's answer:
The test I'm trying to run indeed sits in the main java folder of the library. (I moved it here hoping that when running from here it would be easier to find the package)
If I'm trying to compile the test instead of running it with JUnit he seem to fail to find JUnit classes and other JUnit related stuff.
[Oh OK I'm an idiot! Dont't mind me]
You should include the package while running StandardEvalTest.java as below
javac -cp [classpath] org.pokersource.game.StandardEvalTest.java
and run it from package root directory, I am assuming it is custom java file that you want to compile. You run directory should be parent of your package directory.
** I also see, you are trying to compile StandardEvalTest.java instead of Deck.java ... then check your StandardEvalTest.java file whether it exists in desired location.
Logback 1.1.7
This was during a "production" run: stack trace from Exception (actually NoClassDefFoundError is an Error):
Exception in thread "main" java.lang.NoClassDefFoundError: ch/qos/logback/core/rolling/helper/TimeBasedArchiveRemover$ArhiveRemoverRunnable
at ch.qos.logback.core.rolling.helper.TimeBasedArchiveRemover.cleanAsynchronously(TimeBasedArchiveRemover.java:231)
at ch.qos.logback.core.rolling.TimeBasedRollingPolicy.rollover(TimeBasedRollingPolicy.java:178)
at ch.qos.logback.core.rolling.RollingFileAppender.attemptRollover(RollingFileAppender.java:204)
at ch.qos.logback.core.rolling.RollingFileAppender.rollover(RollingFileAppender.java:183)
at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:224)
at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:100)
So I looked at the source: that class ArhiveRemoverRunnable does indeed exist in the .java file where it should have been instantiated on l. 231 (with that mis-spelling)...
Then I unpacked the executable jar (logback-core-1.1.7.jar): again, the file TimeBasedArchiveRemover$ArhiveRemoverRunnable.class exists in the package, as does file TimeBasedArchiveRemover.class.
This error is not going to happen that often: it is obviously when the "rolling" logger decides it's time to clean up the directory.
Anyone got any idea why this might happen? Troublingly I find no evidence of anyone else experiencing this...!
Potential workaround (pending):
I thought the answer to this might be to extract the source files for this .jar, edit the offending class, compile and repackage as an executable jar, and then use instead of the downloaded jar. In order to do this I started a new Gradle project in Eclipse, imported the entire source package, etc. The thing compiles (builds) OK in Eclipse-with-Gradle, with no complaints of the "NoClassDef" type...
But I'm having difficulties actually producing this executable jar. It'd be a nice thing to be able to accomplish: ability to tweak and test a downloaded dependency in some way (if really necessary).
Current not so satisfactory workaround:
In fact I have no need for a "time-based" archive remover. I'm quite happy just having archives removed on the basis of the size of all the files in the logging directory. This answer appears to solve this. However, logback is quite a beast: I'm not entirely sure: is "archive removal" the same thing as "rollover"?
If the Error occurs again, of course, I shall have to make a special utility method to log every LOGGER.xxx command within a try...catch.
I want to replace the auto injected log object, which is of type org.apache.commons.logging.Log with an object of type org.slf4j.Logger, so that I can use it properly with Logback.
Therefore I need to create a ...Transformer class (written in Java) - that's what I got from Graeme Rocher over at the "grails-user" mailing list. I'm also aware that I have to pack this ...Transformer class within a plugin and make it a *.jar archive which I can load within the lib/ folder of the plugin. But I guess I'm doing something wrong here as I have the class, along with a META-INF folder which contains the MANIFEST.MF file as well as another folder services which holds the following file org.codehaus.groovy.transform.ASTTransformation which holds just one String: the canonical name of the ...Transformer class.
Now, if I try to do a grails clean everything is fine, BUT if I try to run grails package-plugin the console comes up with a java.lang.ClassNotFoundException.
Clipping from Stacktrace:
| Packaging Grails application...
| Error Fatal error during compilation org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Could not instantiate global transform class my.package.ast.LoggingTransformation specified at jar:file:/C:/Source/MyGrailsAST/lib/replace-logging-logback-ast.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation because of exception java.lang.ClassNotFoundException: my.package.ast.LoggingTransformation
1 error
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
Could not instantiate global transform class my.package.ast.LoggingTransformation specified at jar:file:/C:/Source/MyGrailsAST/lib/replace-logging-logback-ast.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation because of exception java.lang.ClassNotFoundException: my.package.ast.LoggingTransformation
Does anybody have some experience with Grails plugins which handle with AstTransformer and could give me some advice on this? Is there a good tutorial out there which I haven't seen so far?
Please let me know ;)
so, after some research, browsing and finally asking at the Grails Mailing List (see the mailing list archives at: http://grails.1312388.n4.nabble.com/Grails-user-f1312389.html I found a solution.
my goal was to create a Globals ASTTransformation, to inject a org.slf4j.Logger object instead of the usual org.apache.commons.logging.Log object into every Artefact class without annotation.
so, here are the steps:
I created Java class similar to https://github.com/grails/grails-core/blob/master/grails-logging/src/main/groovy/org/codehaus/groovy/grails/compiler/logging/LoggingTransformer.java but with my own implementation of the org.slf4j.Logger object. It is crucial that you place the Java.class under the following package: org.codehaus.groovy.grails.compiler as
Grails scans for classes that are annotated with #AstTransformer in this package. (Graeme Rocher)
and pack it into a JAR along with its MANIFEST.MF file within the META-INF/ folder. A META-INF/services directory with all its stuff is not needed as Graeme Rocher stated:
You do not need the META-INF/services stuff and I would remove it as it is probably complicating matters.
So, I guess this statement was more related to my specific problem as I only have one #AstTransformer class within my plugin, but that's just a guess. And I haven't searched for further informations on this topic. Maybe some other developer here who needs this could do some research and share his solution within this thread...
The JAR should be imported to the plugin and placed under the lib/ directory. After this you should be able to do grails clean, grails compile and grails package-plugin.
If you want to replace the log implementation, as I did, you should exclude the grails-logging and grails-plugin-log4j JARs from your designated project's classpath. This is done in the BuildConfig.groovy file:
inherits("global") {
excludes "grails-plugin-log4j", "grails-logging"
}
Now install your plugin grails install-plugin \path\to\plugin.zip and everthing should work as expected.
Hope this helps...
I am trying to emulate some java.lang and java.io classes, e.g. OutputStream within GWT.
I have created a "super" package in my module and referenced it using super-source.
My package structure looks like
com/example/gwt/client
com/example/gwt/server
com/example/gwt/shared
com/example/gwt/super
com/example/gwt/super/java/io/OutputStream.java
com/example/gwt/mymodule.get.xml
and mymodule.xml contains an entry
<super-source path="super" />
Within Eclipse all of the files within the super folder are in error - to be expected because the package structure is wrong. .class files are being generated in the WEB-INF/classes folder, again with the "wrong" package structure so should be ignored.
When I run my application in development mode I get lots of
unable to resolve class java/lang/Object
errors. What am I doing wrong?
Rename ....get.xml to ....gwt.xml?
You can exclude "super" from the eclipse build path.
Try right-clicking or the build path menu exclusion options..
There was nothing wrong with the approach - just the execution.
I had compile errors in the emulated classes which were being masked by the fact that Eclipse was showing errors because of the "incorrect" package structure. Running the compiler from within Eclipse flushed these out.
It also seems that deleting the gwt-unitCache might have helped. As I was moving code around it seems that there were stale entries in here that were still being referenced.
Greetings,
I'm playing around with mahout, I've written a basic java class which imports some of the libraries. It seems my classpath is correct when compiling, I get no errors or complaints at all.
However when I run the compiled class I get an exception saying...
Exception in thread "main" java.lang.NoClassDefFoundError: Test
Caused by: java.lang.ClassNotFoundException: Test
My guess is that . is not on your classpath. For example, you might be compiling with:
javac -cp foo.jar:bar.jar Test.java
but then to run the code you'd need
java -cp foo.jar:bar.jar:. Test
The code that you're compiling doesn't need to be on the classpath as you're providing the code (so there's nothing to find) - that's why it manages to compile but not run.
That's only a guess, of course - if you could post the commands you're using to compile and run the code, that would help.
I'm now getting an error saying java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
You're missing slf4j-api.jar on your class path. With SLF4J, you always need slf4j-api.jar and another jar to bind a logging framework. And actually, if you don't care about logging, use slf4j-nop.jar instead of slf4j-log12.jar.
Update: Mahout seems to be available in Maven central repository so using Maven could ease the class path setup process. And if you're not into learning Maven, consider using MOP which is a command line launcher to run Java stuff that can transparently download Maven artifacts and their dependencies and setup your classpath.
Compile time classpath sounds right; runtime classpath is wrong.
From the javadocs for that class:
Thrown if the Java Virtual Machine or
a ClassLoader instance tries to load
in the definition of a class (as part
of a normal method call or as part of
creating a new instance using the new
expression) and no definition of the
class could be found.
The searched-for class definition
existed when the currently executing
class was compiled, but the definition
can no longer be found.
Do you see a Test.class file in the current directory? Maybe you compiled it to another path by mistake.
If you are using Mahout, be aware that after you build it with Maven, it will generate "*.job" files in the target/ directory, which contain all dependencies packaged together. It is just a .jar file.