Hi Hubert,
I thought the abstract schema type in the FROM clause should be the
entity name. In your example the entity name defaults to AccessToken
while you have Acctoken in your queries.
If you implicitly name your entity (@Entity(name="Acctoken")), won't
that take care of the TOPLINK-8034 error?
Regards,
Dies
Hubert Le Van Gong wrote:
> Greetings,
>
> I have been working on a web application that I’m deploying using
> Glassfish. The web app also
> leverages the Jersey framework and the Java Persistence API to store
> objects in a DB. For all this,
> I’m using NetBeans tools to create a Persistence Unit and the entities I
> have to manage
> (from a DB schema). NetBeans also creates the appropriate mapping of the
> entities and their
> Java classes. For each entity, I end up with java classes that look
> something like this:
>
> @Entity
> @Table(name = "ACCTOKEN")
> @NamedQueries({_at_NamedQuery(name = "Acctoken.findAll", query = "SELECT a
> FROM Acctoken a"),
> @NamedQuery(name = "Acctoken.findById", query = "SELECT a FROM Acctoken
> a WHERE a.id = :id"),
> @NamedQuery(name = "Acctoken.findByAcctUri", query = "SELECT a FROM
> Acctoken a WHERE a.acctUri = :acctUri")
> /... more queries .../ })
>
> public class AccessToken implements Serializable { /.../ }
>
>
> The code above compiles fine and I can deploy the generated war file
> with Glassfish. However,
> and this is where I could use suggestions from anyone, I see a weird
> behaviour when hitting on
> of the exposed endpoints:
> The very first time I do a POST (or a GET), the web application throws
> an exception that looks like:
>
> Exception [TOPLINK-8034] (Oracle TopLink Essentials - 2.0.1 (Build
> b04-fcs (04/11/2008))):
> oracle.toplink.essentials.exceptions.EJBQLException Exception
> Description: Error compiling
> the query [Acctoken.findByAcctVal: SELECT a FROM Acctoken a WHERE
> a.acctVal = :acctVal].
> Unknown abstract schema type [Acctoken]. at
> oracle.toplink.essentials.exceptions.
> EJBQLException.unknownAbstractSchemaType (EJBQLException.java:494)
>
> What’s funny is that this does not happen in any subsequent access to
> those URLs, the web
> app behaves properly. Because subsequent calls are fine I know the
> mapping does happen
> and is correct. I thus don’t really have to explicitly list the classes
> in the persistence.xml file
> and instead I have the
> <exclude-unlisted-classes>false</exclude-unlisted-classes> tag.
> However listing the classes will not help. I have verified this in both
> Glassfish 2.2 and
> Glassfish 3: same behaviour.
> It really looks like Glassfish (what else?) adopts a “lazy” approach for
> the mapping to happen
> and is basically not ready for the 1st call. I already have the
> <load-on-startup /> tag set in my
> web.xml and this didn’t help.
>
> Any idea what might cause this?
>
> Hubert
>
>
>
>
>
> --
> Hubert A. Le Van Gong
> Identity Architect
> Sun microsystems, Inc.