ClientApp, Java:


Query methods, java (note that APP_ID actually represents appId:


Relevant parts of the trace:


every possible thread I've found on this have all been due to mismatch between table and class names, or using a table name instead of a class name, or mispelling, or something that would cause hibernate to not grab the mapping. But my mapping is definitely correct: table is ClientApp and Class is ClientApp, and the query string uses ClientApp. The other solution was making sure you're using javax.persistence.Entity and not the hibernate...Entity package, which I'm also doing.

What else could cause this? It's brain dead simple query...

Thanks, Bill

If I add the full package name to the class in the query string, I get a new exception:



I should mention that this is just a simple jar app; not a web app, and I'm using a generated DAO class from simply reverse engineering the db in eclipse using one of the hibernate plug ins. It appeared to have worked ok, certainly the code generated named and mapped everything ok and it seems consistent with other examples I've seen. Just wanted to mention it in case that could be part of the problem.

and I added the catalog mapping to point to the correct db (using mysql 5.1) which had been missing from the previous table annotation. still no love from hibernate. This is ridiculous

turns out that it wasn't finding hibernate.properties or hibernate.cfg.xml on the classpath, which was due to the default maven build not copying anything but compiled .class files to the build directory. Typical stupid java junk; if you're not fighting with one technology and spending all your time "configuring" crap, you're doing it with another. So, instead of fighting with maven, I decided to load the file from someplace else, but apparently, hibernate doesn't like that either. Still not finding the properties, still not working.

and this is after making sure that there is a hibernate.cfg.xml file on the built classpath. how lame

as a follow up in case somebody else gets jammed up on this, there's a misleading section in the configuration section of the conceptual docs that claims you can set a different file when you do mySessionFactory = cfg.configure("my.hibernate.cfg.xml").buildSessionFactory()

It would seem that this would intelligently take a path to the file, but it doesn't. It does something pretty unhelpful by allowing you to specify a different "name" of the file that it will still expect to find on the default classpath. Additionally, there doesn't appear to be any way to get hibernate to do something smart like load the hibernate.cfg.xml file from someplace else and actually have it configure properly by parsing the xml file that you're forced to configure. No, it just ignores those and instead you have to configure the configuration object with idiotic calls on the cfg file and basically rebuild what it should otherwise be able to configure from the xml file you created in the first place.