2

I have the following query that works under Hibernate but not under eclipse:

select o from Organisation o where o.code=:code and o.type=:type

It is not clear to me why this is the case, I was hoping someone else could elaborate for us. The error being returned is:

Caused by: java.lang.IllegalArgumentException: An exception occurred while creating a query in EntityManager: 
Exception Description: Error compiling the query [select o from Organisation o where  o.code=:code and o.type=:type]. Unknown entity type [Organisation].

We have made no other changes apart from switching the provider class in the persistence.xml file to indicate we are now using eclipselink.

James Brown
  • 95
  • 5

1 Answers1

1

Looks like EclipseLink is not scanning the portion of your JAR files/classes that contain the Organisation class. Declare it explicitly in persistence.xml and see what happens:

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
             version="2.0">
<persistence-unit name="YourPersUnit">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

    <class>foo.bar.Organisation</class>
</persistence-unit>
</persistence>
Behrang
  • 46,888
  • 25
  • 118
  • 160
  • We have multiple jar files with different sets of persistable objects. It turns out hibernate handles this situation differently than eclipse, the easiest way out was to turn on `false` – James Brown Nov 22 '10 at 01:08
  • I believe Hibernate adds annotated @Entity classes that are in the classpath by default unless you tell it not to. That's probably why it worked before. Ninja's answer is right, but an alternative might be to find an equivalent property for EclipseLink that tells it to find all @Entity classes at runtime. I'm assuming that there is one. – Jim Tough Nov 22 '10 at 01:11
  • 1
    Note that exclude-unlisted-classes is not intended for use in J2SE environments (as per the spec), although some implementations do make use of it there ... likely why you see different behaviour that is not covered by the spec. You don't mention which env you're using – DataNucleus Nov 22 '10 at 08:04