Hi,
I am getting back to use Jm3, and I need to build an very complex GUI.
I am trying to setup an very basic lemour test, and I am getting the following error :
NoClassDefFoundError: org/slf4j/LoggerFactory
I am using the last jm3.1 version, and just added the jars to the project :
LemourProto.jar
guava-master.zip
lemour-1.10.1-javadoc.jar
lemour-1.10.1-sources.jar
lemour-1.10.1.jar
slf4j-1.7.5.zip
The Code :
package mygame;
import com.jme3.app.SimpleApplication;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Geometry;
import com.jme3.scene.shape.Box;
import com.simsilica.lemur.GuiGlobals;
public class Main extends SimpleApplication {
public static void main(String[] args) {
Main app = new Main();
app.start();
}
@Override public void simpleInitApp() {
GuiGlobals.initialize(this);
Box b = new Box(1, 1, 1); Geometry geom = new Geometry("Box", b);
Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
mat.setColor("Color", ColorRGBA.Blue);
geom.setMaterial(mat);
rootNode.attachChild(geom);
}
@Override public void simpleUpdate(float tpf) { }
@Override public void simpleRender(RenderManager rm) { }
}
It’s Lemur and not Lemour
I think you need the slf4logging.jar or how it is called so slf has a Backend.
Should be explained on the slf page actually
But maybe didn’t drill into things like: “slf4j version 1.7.5 or later, plus an adapter for your preferred logging framework. (At minimum, you will need the API jar, something like: slf4j-api-1.7.5.jar)”
Or for gradle setup, you can poke around at these examples:
I think network-basic is probably the simplest example that uses Lemur.
Though actually, now that I think about it, it’s probably more direct to just look at the Lemur examples:
Is that really a zip (containing jars/source/etc), or a misnamed jar? A jar is basically a zip (format), but a zip isn’t a jar.
You’d benefit from stepping back awhile and learning the Java fundamentals at work here. You’ll still learn things by attempting a big project, but you might be less likely to get frustrated if you scale back ambitions at first. No intent to discourage, it just looks like you’re trying to run before you can walk here.
What ??? Have no idea on what you are talking about…
I misstype the zip file, the jars are there in the filepath, still get this error.
Pspeed reply correctly thought, it needs an additional adapter jar of my choice…
It should be something there saying that thought ( like pspeed point out ).
Was pointing out that zips were included in the list above–made it look like you’re using a downloaded zip instead of a jar. Might be a language barrier here, but I’d say the docs look clear enough (if I understand correctly that you’re saying otherwise).
I did an second read in the docs, and you are right, the information was there, I didnt read it properly. I just read the section saying about the slf4j and download it, didnt notice this section mention tat you need additional libraries ( log libs ).
I would recoment to split this thought into 2 secsions to prevent others to get confused, like :
Missing an adapter won’t prevent things from running… you will just get an error about no logging adapters or something… but the app should still run.
If you’re still stuck, I suggest you post a screenshot showing your project’s build path/library config. (Eclipse or NetBeans?)
If you’re dropping your dependencies in a project folder (ex. /lib) yourself, you need to do more than just that. They need to be added to the build path (Build Path context menu option in Eclipse can do it, or “Libraries” category under project properties, in NetBeans.) Sorry, if you already understand this point (I don’t know your familiarity level w/Java so just making sure).
I can’t see the whole stack trace but the part I see is weird. It’s like it partially wants to think it’s using log4j even though it should be agnostic.
Anyway, you got it all working so no worries. But generally leaving out a specific API adapter will only result in an error printed out about missing one.
The slf4j-api jar. This provides the interface that the application codes against, and some startup & dispatching stuff. If this is the only component present at application launch, you get the no logging adapters error on stdout, and the framework defaults to an internal NOP implementation. However, if you want to do logging, you need:
An adapter for your preferred logging framework. Note: you can only have one of these in the classpath at a time, or weird things happen. In turn, the adapter relies upon:
The actual logging framework. The adapter is just a thin wrapper. It takes slf4j logging calls, and translates them into something that the logger will understand. Without the logger, the wrapper is stuck looking for a class that, as far as the JVM knows, does not exist!
This last part is what the OP is missing. He needs to make sure that the log4j library and any required configuration files are in fact on the classpath at application launch.
Or, to have only included the API jar and not the adapter jar. Got it. (Not ideal but it does still mean that the API jar is the only non-optional part… with just the API you will get an error but the app will still run.)
That bit is a deliberate tradeoff. The library was constructed this way deliberately so that the end user has their choice of logging frameworks. This is perhaps not so relevant in a game, but if one were building an enterprise stack, any slf4j compatible libraries can be deployed in tandem with the corporate-approved logger, as long as it has an appropriate adapter. The adapter would be simple to code if one has a special snowflake logging system.
This would be in contrast to libraries that are hard coded against a specific logger. In such a case, one could easily get into a situation where they’re depending on mutually incompatible versions of a logging library.
Yes, I meant “not ideal” because the app wouldn’t produce any logging.
Your background on slf4j is good for other readers but I’m a long-time proponent and have been using it for years in enterprise environments exactly for the reasons you state. (And it bugs the heck out of me that Apache projects tend to hard-code log4j instead. ;))
