I have a Java (6) application which uses Hibernate (V3.3.2) to read data from HSQLDB, which i build and debug/run with Eclipse (V3.5.1), and it works fine.
I then created a GWT (V1.7) Servlet web app, copied my hibernate classes into it, and added the same User Libraries dependencies. However when i run the servlet and try to access a URL which invokes my code i get this:
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:152)
at xxx.daoimpl.DAOSession.initialise(DAOSession.java:40)
where DAOSession.java:40 is :
AnnotationConfiguration config = new AnnotationConfiguration ();
Googling for this error suggests i am missing slf4j-api.jar from the classpath, however if i look at the command line for the Debug properties i can see this jar there:
C:\java\jsedk_6\jre\bin\javaw.exe
-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:54541
-Xmx512m -Dfile.encoding=Cp1252
-classpath
D:\dev\workspace\xxx\src;
D:\dev\workspace\xxx\resources;
D:\dev\workspace\xxx\war\WEB-INF\classes;
C:\java\eclipse\plugins\com.google.gwt.eclipse.sdkbundle.win32_1.7.1.v200909221731\gwt-windows-1.7.1\gwt-user.jar;
C:\java\eclipse\plugins\com.google.gwt.eclipse.sdkbundle.win32_1.7.1.v200909221731\gwt-windows-1.7.1\gwt-dev-windows.jar;
C:\java\hibernate-annotations-3.4.0.GA\hibernate-annotations.jar;
C:\java\hibernate-annotations-3.4.0.GA\lib\ejb3-persistence.jar;
C:\java\hibernate-annotations-3.4.0.GA\lib\hibernate-commons-annotations.jar;
C:\java\hibernate-distribution-3.3.2.GA\hibernate3.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\antlr-2.7.6.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\commons-collections-3.1.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\dom4j-1.6.1.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\javassist-3.9.0.GA.jar;
C:\java\hibernate-distribution-3.3.2.GA\lib\required\jta-1.1.jar;
C:\java\hibernate-validator-4.0.1.GA\hibernate-validator-4.0.1.GA.jar;
C:\java\hibernate-validator-4.0.1.GA\lib\validation-api-1.0.0.GA.jar;
C:\java\hibernate-validator-4.0.1.GA\lib\log4j-1.2.14.jar;
C:\java\hsqldb\lib\hsqldb.jar;
C:\java\restlet-jse-2.0m5\lib\org.restlet.jar;
C:\java\restlet-jee-2.0m5\lib\org.restlet.ext.servlet.jar;
C:\java\restlet-jse-2.0m5\lib\org.restlet.ext.xml.jar;
C:\java\slf4j-1.5.8\slf4j-api-1.5.8.jar;
C:\java\slf4j-1.5.8\slf4j-log4j12-1.5.8.jar
com.google.gwt.dev.HostedMode
...
If i open the jar i can see the LoggerFactory class in there.
Any idea why it isn't being found by the class loader?
Edit 1: If try to access org.slf4j.LoggerFactory from my code, Eclipse compiles it ok, but i get the same error at runtime.
Edit 2: If i add a Test class with a main which calls the same code and run it, it works. So this classpath problem seems specific to the Servlet.
thanks,
jon
It seems that copying the two slf4j jars to the war/WEB-INF/lib sub-project/dir fixed the problem. I'm not really sure why i should need to do this for these two jars and not for all the other Hibernate, Restlet etc jars that the project also uses, though i suppose for consistency i will do that anyway - i guess it will make deployment easier as well.
If someone can provide some sort of explanation as to why this worked and why exactly i need to do it i will select it as the "correct" answer, otherwise i'll select this one.
Can you please reconfirm that you have at least two slf4j.jar files in the classpath, the slf4j-api.jar and exactly one implementation, such as slf4j-jdk14.jar?
You must not have multiple sflj4-implementations in the classpath.
You have a runtime dependency issue so everything compiles fine but the dependency is in your jars. You need to visit the Hibernate site and look at the compatibility matrix and make sure you are matched up correctly then check the dependencies for annotations and core. You log4J jars look fine so it's definitely some quirk.
If it works in Eclipse then logically it's definitely some diff between the 2 runtimes (eclipse and non-eclipse), if the matrix checks out fine then see if you can factor out the commonalities in the 2 then work out the differences -- your answer should be in there.
I had a similar issue except I was using Tomcat and the NoClassDefFound error was on the juli logger. I fixed it by removing the Tomcat dependencies from my classpath when running in hosted mode because hosted mode embeds a Tomcat server that was conflicting. So I would see what happens if you remove some or all of the restlet jars from your classpath to see if they conflict.
Related
This is my first post on stackoverflow, please be indulgent.
Within my project, I use the library commons-digester-1.8.
Following a need, I now use the library gwt-dev-2.3.0.
When launching the application I get this error :
Exception caught while initializing context java.lang.NoSuchMethodError: org/apache/commons/digester/xmlrules/DigesterLoader.createDigester(Lorg/xml/sax/InputSource;)Lorg/apache/commons/digester/Digester;
at fr.cnasea.commons.webfwk.util.config.lecture.XMLDigesterReader.getConfig(XMLDigesterReader.java:157)
at fr.cnasea.commons.webfwk.util.config.CnaseaAppConfigurator.configure(CnaseaAppConfigurator.java:76)
at fr.cnasea.osiris.commons.gwt.server.Config.contextInitialized(Config.java:47)
It turns out that the two libraries have the same class in the same package with the same method:
Same class
Since the use of gwt-dev, it is the method of this library which is called.
I tried to use newer versions of gwt-dev but the environment makes it not possible
How can I fix it?
Thanks for your help :)
(From my answer to your same question on the github project)
The gwt-dev.jar should not be on your server classpath - it is only used to compile your application. The same is true for gwt-user.jar. Only gwt-servlet.jar (and possibly requestfactory-server.jar) should end up on your server classpath, the others are intended only to be present when compiling, either to do the work of compiling, or to provide the compiler the classes you need.
I use eclipse for my optaplanner project development and I am able to execute my code from eclipse without any problem. To make this project as an executable, I exported it as a jar file using eclipse export wizard.
Then I run my jar from terminal using the command java -jar myOptaPlanner.jar, then, I get below error
WARN given scan urls are empty. set urls in the configuration
Exception in thread "main" java.lang.IllegalStateException: The scanAnnotatedClasses
(ScanAnnotatedClassesConfig()) did not find any classes with a PlanningSolution
annotation.
Maybe you forgot to annotate a class with a PlanningSolution annotation.
Maybe you're using special classloading mechanisms (OSGi, ...) and this is a bug.
If you can confirm that, report it to our issue tracker and workaround it by
defining the classes explicitly in the solver configuration.
at org.optaplanner.core.config.domain.ScanAnnotatedClassesConfig.loadSolutionClass(ScanAnnotatedClassesConfig.java:106)
at org.optaplanner.core.config.domain.ScanAnnotatedClassesConfig.buildSolutionDescriptor(ScanAnnotatedClassesConfig.java:86)
at org.optaplanner.core.config.solver.SolverConfig.buildSolutionDescriptor(SolverConfig.java:270)
at org.optaplanner.core.config.solver.SolverConfig.buildSolver(SolverConfig.java:216)
at org.optaplanner.core.impl.solver.AbstractSolverFactory.buildSolver(AbstractSolverFactory.java:57)
at org.roster.app.WorkerRosteringApp.main(WorkerRosteringApp.java:36)
Is this really a bug or am I exporting it wrong?
Update: I tried to export jar using maven-shade-plugin and here also I am getting the same error.
Thanks
scanAnnotatedClasses doesn't seem to work in a jar file. Instead, use following workaround:
<solutionClass>path.to.your.SolutionClass</solutionClass>
<entityClass>path.to.your.EntityClassI</entityClass>
<entityClass>path.to.your.EntityClassII</entityClass>
and delete the scanAnnotatedClasses in your config file.
If you don't want to declare the solution and entity classes manually, including the packages containing the solution and entity classes also works as workaround:
<scanAnnotatedClasses>
<packageInclude>your.package.here</packageInclude>
</scanAnnotatedClasses>
Documentation about <packageInclude> can be found here
I'm using netbeans to generate a web service client from a WSDL doc.
The client works fine until we put it in our production environment. The jars were generated against javax.ws.xxxxx classes from jaxws-api.jar and jaxb-api.jar, which we placed in out production classpath.
In our production environment we have other code that depends on xfire libraries. When we attempt to instantiate SubmissionAPI(), we are getting a NoClassDefFound Exception. I'm pasting the stack trace below.
UBLSoapTest class appears to call the correct 'Service' class, but the 'Service' class
is calling org.codehaus.xfire.jaxws.Provider.
I've checked the source for javax.xml.ws.Service, and it has 'import javax.xml.ws.spi.Provider;'
We've tried assembling the jar with the javax.xxxx classes inside and still get the same result. I suspect we need to set a classpath in the manifest file, but I'm not sure what needs to be there.
FAIL: Exception: java.lang.NoClassDefFoundError: Could not initialize class
org.codehaus.xfire.jaxws.JAXWSHelper
org.codehaus.xfire.jaxws.ServiceDelegate.<init>(ServiceDelegate.java:33)
org.codehaus.xfire.jaxws.ServiceDelegate.<init>(ServiceDelegate.java:53)
org.codehaus.xfire.jaxws.Provider.createServiceDelegate(Provider.java:32)
javax.xml.ws.Service.<init>(Service.java:56)
org.ubl.soap.test.SubmissionAPI.<init>(SubmissionAPI.java:44)
I'm a bit at a loss of even where to look from here.
We've tried setting classpath in the manifest, with little success.
The basic jar structures we've tries are:
/org/xxxx
/META-INF/xxx
and
/org/xxx
/META-INF/xxx
/javax/xxx
and
/org/xxx
/META-INF/xxx
/jaxws-api.jar
/jaxb.jar
It seems that you are missing the impl jar for JAX-WS. If you are relying on Codehaus to provide the impl, you might want to make sure their impl works. According to their site, it's a newly supported component.
The alternative is to provide your own impl jar and put it in the class path so JAX-WS interfaces are found there. But usually the app server where you deploy your web service app should include the impl in its class path.
I get the following error in Endeca:
com.endeca.navigation.ENEException: Navigation Engine not able to process
request `http://myhost:15000/search?terms=remote&rank=0&offset=0&irversion=601`
My MDEX version is 6.3.0
The referenced jar files in my app is:
endeca_navigation.jar : Specification-IR-Version: 6.3.0 (Read from MANIFEST file)
endeca_logging.jar: Specification-Version: 6.1.2 (Read from MANIFEST file)
Even with these referenced jars, why is the request parameter still irversion=601?
I'm using java 1.5 and building my app in eclipse. At first, it was referencing older jar files (601), but i removed those completely and replaced them with the newer jar files listed above. I've rebuilt my app and I still see the parameter irversion=601. I've been trying to find out what the issue is for a few hours, but i'm having no luck.
Any ideas?
If nothing else I think that you need an N=0 parameter for you request to work.
Also if you are using an application server like Weblogic to run you app, it has a tendency of caching referenced jars which may have to be cleared for it to pick up the new versions of the jars.
Finally if all else fails there is a --back_compat 601 parameter on your dgraph which indicated the accepatble navigation.jar versions. You can use this parameter to determine if the issue is the jar version or something else in between.
Good Luck
Additionally to Wiszh's response, it is useful to take a look at the dgraph request query logs (located in /logs/dgraph/Dgraphxx/Dgraphxx.log and .reqlog) which will show a more specific error and the query that caused it.
Do your jars match the version of Endeca server you are querying?
This issue is due to an old navigation api jar in your class path
Check the ToolsAndFrameworks\version\assembler\lib to get the correct version of navigation api jar. That should fix this issue.
correct jar path fixed the issue for me
ToolsAndFrameworks\version\assembler\lib
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...