You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Michael Simons <mi...@optitool.de> on 2009/05/25 14:29:45 UTC
... is not a recognized entity or identifier.
Hi,
I've encountered a strange little problem here... When I do the
following locally (in a simple application, not connected to an
Application Server)...
Query query = em.createQuery("select u from LoginUser u where u.login =
:loginname and u.passwd = :pass"); //$NON-NLS-1$
//... setting Parameters...
LoginUser user = null;
try {
user = (LoginUser)query.getSingleResult ();
} catch (NoResultException noResult) {
System.err.println("NoResult");
}
... it works fine, it'll get me the correct "LoginUser" object. But when
I try the same thing in a stateful EJB, the problems start. I'll get the
following error:
<openjpa-1.2.1-r752877:753278 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: An error occurred
while parsing the query filter "select u from LoginUser u where u.login
= :loginname and u.passwd = :pass". Error message: The name "LoginUser"
is not a recognized entity or identifier. Known entity names: []
Funny thing, if I call something like...
LoginUser user = (LoginUser)em.find(LoginUser.class, 1);
...before trying to create the query above, the whole thing will
suddenly work, LoginUser seems to become a recognized Entity (which also
shows, that my classes are correctly enhanced, that the EntityManager
knows them correctly, etc.). It seems, that even though the
EntityManager "knows" the LoginUser Entity (because I can "em.find(...)"
it), it doesn't recognize it in a query.
If I cast the Query to OpenJPAQuery and there set the ResultClass...
if (query instanceof OpenJPAQuery) {
OpenJPAQuery opq = (OpenJPAQuery)query;
opq.setResultClass( LoginUser.class );
}
...it suddenly seems to work. The big question is: Why is this needed?
Is there a setting I can put into the (OpenJPA)EntityManager, that it
will automatically recognize all of its entities in queries? Or do I
really have to cast to OpenJPAQuery everytime I do a query?
Regards,
Michael (The original author Florian did not get a response from the list, after
subscription-verification)
Re: ... is not a recognized entity or identifier.
Posted by Michael Dick <mi...@gmail.com>.
That's more troublesome. I don't have an answer offhand though. Do you have
a JIRA account [1] and if so would you mind opening a bug report? I can open
one on your behalf if you'd rather not register.
[1] https://issues.apache.org/jira/secure/
-mike
On Wed, May 27, 2009 at 7:21 AM, Michael Simons
<mi...@optitool.de>wrote:
> Hello Mike,
>
> Michael Dick schrieb:
> > Does listing the types in persistence.xml also resolve the problem?
> > Specifying them on the MetaDataFactory should exercise the same path as :
> > <persistence-unit name="xxx">
> > <class>net.uniopt.domain.actual.ActualAction</class>
> > . . .
> > </persistence-unit>
> No, that deosn't. We already had that listing, i.e., we now list the
> persistent classes twice -
> once in the <class> tags, and twice in the openjpa.MetaDataFactory property
> of the
> <persistence-unit> tag.
>
> Michael
>
Re: ... is not a recognized entity or identifier.
Posted by Michael Simons <mi...@optitool.de>.
Hello Mike,
Michael Dick schrieb:
> Does listing the types in persistence.xml also resolve the problem?
> Specifying them on the MetaDataFactory should exercise the same path as :
> <persistence-unit name="xxx">
> <class>net.uniopt.domain.actual.ActualAction</class>
> . . .
> </persistence-unit>
No, that deosn't. We already had that listing, i.e., we now list the persistent classes twice -
once in the <class> tags, and twice in the openjpa.MetaDataFactory property of the
<persistence-unit> tag.
Michael
Re: ... is not a recognized entity or identifier.
Posted by Michael Dick <mi...@gmail.com>.
On Tue, May 26, 2009 at 4:51 PM, Pinaki Poddar <pp...@apache.org> wrote:
>
> Hi Mike,
> > We could (should ?) scan the classpath if the alias isn't available and
> > exclude-unlisted-classes == false. It could be expensive but it's better
> > than a misleading error message like this one..
>
> We should. Perhaps with a
> openjpa.ScanClasspathForEntityWhenQueryAliasNotDetecetd=true|false. But
> what
> is the scope of such scan? And what exactly should be the strategy for a
> fast scan?
I'd guess this is why we don't do something like this already - it's not a
trivial solution.
I'd propose something like this (assuming the problem still exists after we
fix the issue Michael Simons mentioned) :
openjpa.UnlistedEntityDetection = none | complete | partial.
none == behavior we have today.
complete == scan all @Entities on the classpath (and anything in orm.xml).
Exception as today if the alias is not found.
partial == scan until we find the missing alias - then stop. Exception as
today if the alias is not found.
We've spoken about initializing the MetaDataRepository eagerly in the past
(1 pass, avoid locking, re-scanning, etc.). This approach wouldn't be the
same but it'd be related.
Also do you know of any place in OpenJPA (or elsewhere) that employs a full
> classpath scan?
>
Not off the top of my head. I would think that the PCEnhancer would do
something similar if no classes were listed in persistence.xml though.
-mike
>
>
> Michael Dick wrote:
> >
> > Does listing the types in persistence.xml also resolve the problem?
> > Specifying them on the MetaDataFactory should exercise the same path as :
> > <persistence-unit name="xxx">
> > <class>net.uniopt.domain.actual.ActualAction</class>
> > . . .
> > </persistence-unit>
> >
> > Possible explanation (more for dev@openjpa than users@openjpa) :
> > Enhanced classes have a static initializer which "registers" the type
> with
> > OpenJPA the first time it's loaded (creating and instance or running
> > em.find()). If the type isn't listed or initialized we don't know where
> > look
> > for the alias in your JPQL query.
> >
> > We could (should ?) scan the classpath if the alias isn't available and
> > exclude-unlisted-classes == false. It could be expensive but it's better
> > than a misleading error message like this one..
> >
> > -mike
> >
> > On Tue, May 26, 2009 at 12:27 PM, Kevin Sutter <kw...@gmail.com>
> wrote:
> >
> >> At least you have verified that the problem is related to the populating
> >> of
> >> the metadata repository. Thanks for the information.
> >>
> >> Kevin
> >>
>
<snip>
>
> -----
> Pinaki Poddar http://ppoddar.blogspot.com/
>
> http://www.linkedin.com/in/pinakipoddar
> OpenJPA PMC Member/Committer
> JPA Expert Group Member
> --
> View this message in context:
> http://n2.nabble.com/...-is-not-a-recognized-entity-or-identifier.-tp2969391p2977501.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>
Re: ... is not a recognized entity or identifier.
Posted by Pinaki Poddar <pp...@apache.org>.
Hi Mike,
> We could (should ?) scan the classpath if the alias isn't available and
> exclude-unlisted-classes == false. It could be expensive but it's better
> than a misleading error message like this one..
We should. Perhaps with a
openjpa.ScanClasspathForEntityWhenQueryAliasNotDetecetd=true|false. But what
is the scope of such scan? And what exactly should be the strategy for a
fast scan?
Also do you know of any place in OpenJPA (or elsewhere) that employs a full
classpath scan?
Michael Dick wrote:
>
> Does listing the types in persistence.xml also resolve the problem?
> Specifying them on the MetaDataFactory should exercise the same path as :
> <persistence-unit name="xxx">
> <class>net.uniopt.domain.actual.ActualAction</class>
> . . .
> </persistence-unit>
>
> Possible explanation (more for dev@openjpa than users@openjpa) :
> Enhanced classes have a static initializer which "registers" the type with
> OpenJPA the first time it's loaded (creating and instance or running
> em.find()). If the type isn't listed or initialized we don't know where
> look
> for the alias in your JPQL query.
>
> We could (should ?) scan the classpath if the alias isn't available and
> exclude-unlisted-classes == false. It could be expensive but it's better
> than a misleading error message like this one..
>
> -mike
>
> On Tue, May 26, 2009 at 12:27 PM, Kevin Sutter <kw...@gmail.com> wrote:
>
>> At least you have verified that the problem is related to the populating
>> of
>> the metadata repository. Thanks for the information.
>>
>> Kevin
>>
>> On Tue, May 26, 2009 at 12:14 PM, Michael Simons <
>> michael.simons@optitool.de
>> > wrote:
>>
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Hello Kevin,
>> >
>> > We are using the current stable version of Geronimo AS.
>> > Yes, we are pre-enhancing your Entities.
>> >
>> > We now solved (or worked-around) the problem by inserting the following
>> in
>> > our persistence.xml:
>> > <property name="openjpa.MetaDataFactory"
>> >
>> >
>> value="jpa(Types=net.uniopt.domain.actual.ActualAction;...;net.uniopt.domain.usrmngmt.LoginUser)"/>
>> >
>> > Hope this helps catching the bug.
>> >
>> > Michael
>> >
>> > Kevin Sutter schrieb:
>> > > Hi Michael,
>> > > I see that you are running with 1.2.x of OpenJPA, so that's good. I
>> > thought
>> > > that the problem you are describing was resolved eons ago. It's one
>> that
>> > I
>> > > hit very early on in my tenure with OpenJPA. So, either the problem
>> > still
>> > > has a window associated with it, or it was accidentally
>> re-introduced.
>> > >
>> > > The problem is that the metadata associated with the Entities in the
>> > query
>> > > is not populated yet. You are forcing this metadata to get populated
>> by
>> > > doing one of your tricks (doing a find before the query, for
>> example).
>> > >
>> > > As I think about it more, maybe the "window" still exists in an
>> > application
>> > > server, but the original problem was resolved in standalone JSE mode.
>> > Not
>> > > sure. What application server are you using? Does it provide the
>> > necessary
>> > > hooks for a JPA provider so that OpenJPA can properly enhance the
>> classes
>> > at
>> > > startup?
>> > >
>> > > I did a quick search in our JIRAs and found this one [1]. But, this
>> > seems
>> > > to be related to MappedSuperClasses and it seems to also fail in JSE.
>> > >
>> > > There are also several postings to our forums with similar results
>> [2],
>> > but
>> > > I'm not sure if these are the exact same scenario as yours. Are you
>> > > pre-enhancing your Entities? Or, are you relying on the container
>> hook
>> > to
>> > > do the dynamic enhancing? Or, are you relying on the runtime
>> enhancement
>> > > (also known as sub-classing)?
>> > >
>> > > More questions than answers, but I really thought this issue was
>> resolved
>> > a
>> > > long time ago...
>> > > Kevin
>> > >
>> > >
>> > > [1] https://issues.apache.org/jira/browse/OPENJPA-1043
>> > > [2]
>> > >
>> >
>> http://n2.nabble.com/Starting-OpenJPA-during-container-startup-td210725.html#a210725
>> > >
>> > >
>> >
>> http://n2.nabble.com/RE%3A-Problem-with-openjpa-enhancer---using-runtime-enhancement-td1608390.html#a1608390
>> > >
>> > > On Mon, May 25, 2009 at 7:29 AM, Michael Simons
>> > > <mi...@optitool.de>wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I've encountered a strange little problem here... When I do the
>> > >> following locally (in a simple application, not connected to an
>> > >> Application Server)...
>> > >>
>> > >> Query query = em.createQuery("select u from LoginUser u where
>> u.login
>> =
>> > >> :loginname and u.passwd = :pass"); //$NON-NLS-1$
>> > >> //... setting Parameters...
>> > >> LoginUser user = null;
>> > >> try {
>> > >> user = (LoginUser)query.getSingleResult ();
>> > >> } catch (NoResultException noResult) {
>> > >> System.err.println("NoResult");
>> > >> }
>> > >>
>> > >> ... it works fine, it'll get me the correct "LoginUser" object. But
>> when
>> > >> I try the same thing in a stateful EJB, the problems start. I'll get
>> the
>> > >> following error:
>> > >>
>> > >> <openjpa-1.2.1-r752877:753278 nonfatal user error>
>> > >> org.apache.openjpa.persistence.ArgumentException: An error occurred
>> > >> while parsing the query filter "select u from LoginUser u where
>> u.login
>> > >> = :loginname and u.passwd = :pass". Error message: The name
>> "LoginUser"
>> > >> is not a recognized entity or identifier. Known entity names: []
>> > >>
>> > >> Funny thing, if I call something like...
>> > >>
>> > >> LoginUser user = (LoginUser)em.find(LoginUser.class, 1);
>> > >>
>> > >> ...before trying to create the query above, the whole thing will
>> > >> suddenly work, LoginUser seems to become a recognized Entity (which
>> also
>> > >> shows, that my classes are correctly enhanced, that the
>> EntityManager
>> > >> knows them correctly, etc.). It seems, that even though the
>> > >> EntityManager "knows" the LoginUser Entity (because I can
>> "em.find(...)"
>> > >> it), it doesn't recognize it in a query.
>> > >>
>> > >> If I cast the Query to OpenJPAQuery and there set the ResultClass...
>> > >>
>> > >> if (query instanceof OpenJPAQuery) {
>> > >> OpenJPAQuery opq = (OpenJPAQuery)query;
>> > >> opq.setResultClass( LoginUser.class );
>> > >> }
>> > >>
>> > >> ...it suddenly seems to work. The big question is: Why is this
>> needed?
>> > >> Is there a setting I can put into the (OpenJPA)EntityManager, that
>> it
>> > >> will automatically recognize all of its entities in queries? Or do I
>> > >> really have to cast to OpenJPAQuery everytime I do a query?
>> > >>
>> > >> Regards,
>> > >>
>> > >> Michael (The original author Florian did not get a response from the
>> > list,
>> > >> after
>> > >> subscription-verification)
>> > >>
>> > >>
>> > >
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.7 (MingW32)
>> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> >
>> > iD8DBQFKHCNx5aNR/9BakrgRAoRaAJ9j0zMzQ27KXLy/9XnwexR0Oz9AtwCdFVLK
>> > B7tHzJkC1V/zYjJTyWJUGCU=
>> > =bRbu
>> > -----END PGP SIGNATURE-----
>> >
>>
>
>
-----
Pinaki Poddar http://ppoddar.blogspot.com/
http://www.linkedin.com/in/pinakipoddar
OpenJPA PMC Member/Committer
JPA Expert Group Member
--
View this message in context: http://n2.nabble.com/...-is-not-a-recognized-entity-or-identifier.-tp2969391p2977501.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: ... is not a recognized entity or identifier.
Posted by Michael Dick <mi...@gmail.com>.
Does listing the types in persistence.xml also resolve the problem?
Specifying them on the MetaDataFactory should exercise the same path as :
<persistence-unit name="xxx">
<class>net.uniopt.domain.actual.ActualAction</class>
. . .
</persistence-unit>
Possible explanation (more for dev@openjpa than users@openjpa) :
Enhanced classes have a static initializer which "registers" the type with
OpenJPA the first time it's loaded (creating and instance or running
em.find()). If the type isn't listed or initialized we don't know where look
for the alias in your JPQL query.
We could (should ?) scan the classpath if the alias isn't available and
exclude-unlisted-classes == false. It could be expensive but it's better
than a misleading error message like this one..
-mike
On Tue, May 26, 2009 at 12:27 PM, Kevin Sutter <kw...@gmail.com> wrote:
> At least you have verified that the problem is related to the populating of
> the metadata repository. Thanks for the information.
>
> Kevin
>
> On Tue, May 26, 2009 at 12:14 PM, Michael Simons <
> michael.simons@optitool.de
> > wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hello Kevin,
> >
> > We are using the current stable version of Geronimo AS.
> > Yes, we are pre-enhancing your Entities.
> >
> > We now solved (or worked-around) the problem by inserting the following
> in
> > our persistence.xml:
> > <property name="openjpa.MetaDataFactory"
> >
> >
> value="jpa(Types=net.uniopt.domain.actual.ActualAction;...;net.uniopt.domain.usrmngmt.LoginUser)"/>
> >
> > Hope this helps catching the bug.
> >
> > Michael
> >
> > Kevin Sutter schrieb:
> > > Hi Michael,
> > > I see that you are running with 1.2.x of OpenJPA, so that's good. I
> > thought
> > > that the problem you are describing was resolved eons ago. It's one
> that
> > I
> > > hit very early on in my tenure with OpenJPA. So, either the problem
> > still
> > > has a window associated with it, or it was accidentally re-introduced.
> > >
> > > The problem is that the metadata associated with the Entities in the
> > query
> > > is not populated yet. You are forcing this metadata to get populated
> by
> > > doing one of your tricks (doing a find before the query, for example).
> > >
> > > As I think about it more, maybe the "window" still exists in an
> > application
> > > server, but the original problem was resolved in standalone JSE mode.
> > Not
> > > sure. What application server are you using? Does it provide the
> > necessary
> > > hooks for a JPA provider so that OpenJPA can properly enhance the
> classes
> > at
> > > startup?
> > >
> > > I did a quick search in our JIRAs and found this one [1]. But, this
> > seems
> > > to be related to MappedSuperClasses and it seems to also fail in JSE.
> > >
> > > There are also several postings to our forums with similar results [2],
> > but
> > > I'm not sure if these are the exact same scenario as yours. Are you
> > > pre-enhancing your Entities? Or, are you relying on the container hook
> > to
> > > do the dynamic enhancing? Or, are you relying on the runtime
> enhancement
> > > (also known as sub-classing)?
> > >
> > > More questions than answers, but I really thought this issue was
> resolved
> > a
> > > long time ago...
> > > Kevin
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/OPENJPA-1043
> > > [2]
> > >
> >
> http://n2.nabble.com/Starting-OpenJPA-during-container-startup-td210725.html#a210725
> > >
> > >
> >
> http://n2.nabble.com/RE%3A-Problem-with-openjpa-enhancer---using-runtime-enhancement-td1608390.html#a1608390
> > >
> > > On Mon, May 25, 2009 at 7:29 AM, Michael Simons
> > > <mi...@optitool.de>wrote:
> > >
> > >> Hi,
> > >>
> > >> I've encountered a strange little problem here... When I do the
> > >> following locally (in a simple application, not connected to an
> > >> Application Server)...
> > >>
> > >> Query query = em.createQuery("select u from LoginUser u where u.login
> =
> > >> :loginname and u.passwd = :pass"); //$NON-NLS-1$
> > >> //... setting Parameters...
> > >> LoginUser user = null;
> > >> try {
> > >> user = (LoginUser)query.getSingleResult ();
> > >> } catch (NoResultException noResult) {
> > >> System.err.println("NoResult");
> > >> }
> > >>
> > >> ... it works fine, it'll get me the correct "LoginUser" object. But
> when
> > >> I try the same thing in a stateful EJB, the problems start. I'll get
> the
> > >> following error:
> > >>
> > >> <openjpa-1.2.1-r752877:753278 nonfatal user error>
> > >> org.apache.openjpa.persistence.ArgumentException: An error occurred
> > >> while parsing the query filter "select u from LoginUser u where
> u.login
> > >> = :loginname and u.passwd = :pass". Error message: The name
> "LoginUser"
> > >> is not a recognized entity or identifier. Known entity names: []
> > >>
> > >> Funny thing, if I call something like...
> > >>
> > >> LoginUser user = (LoginUser)em.find(LoginUser.class, 1);
> > >>
> > >> ...before trying to create the query above, the whole thing will
> > >> suddenly work, LoginUser seems to become a recognized Entity (which
> also
> > >> shows, that my classes are correctly enhanced, that the EntityManager
> > >> knows them correctly, etc.). It seems, that even though the
> > >> EntityManager "knows" the LoginUser Entity (because I can
> "em.find(...)"
> > >> it), it doesn't recognize it in a query.
> > >>
> > >> If I cast the Query to OpenJPAQuery and there set the ResultClass...
> > >>
> > >> if (query instanceof OpenJPAQuery) {
> > >> OpenJPAQuery opq = (OpenJPAQuery)query;
> > >> opq.setResultClass( LoginUser.class );
> > >> }
> > >>
> > >> ...it suddenly seems to work. The big question is: Why is this needed?
> > >> Is there a setting I can put into the (OpenJPA)EntityManager, that it
> > >> will automatically recognize all of its entities in queries? Or do I
> > >> really have to cast to OpenJPAQuery everytime I do a query?
> > >>
> > >> Regards,
> > >>
> > >> Michael (The original author Florian did not get a response from the
> > list,
> > >> after
> > >> subscription-verification)
> > >>
> > >>
> > >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.7 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFKHCNx5aNR/9BakrgRAoRaAJ9j0zMzQ27KXLy/9XnwexR0Oz9AtwCdFVLK
> > B7tHzJkC1V/zYjJTyWJUGCU=
> > =bRbu
> > -----END PGP SIGNATURE-----
> >
>
Re: ... is not a recognized entity or identifier.
Posted by Kevin Sutter <kw...@gmail.com>.
At least you have verified that the problem is related to the populating of
the metadata repository. Thanks for the information.
Kevin
On Tue, May 26, 2009 at 12:14 PM, Michael Simons <michael.simons@optitool.de
> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello Kevin,
>
> We are using the current stable version of Geronimo AS.
> Yes, we are pre-enhancing your Entities.
>
> We now solved (or worked-around) the problem by inserting the following in
> our persistence.xml:
> <property name="openjpa.MetaDataFactory"
>
> value="jpa(Types=net.uniopt.domain.actual.ActualAction;...;net.uniopt.domain.usrmngmt.LoginUser)"/>
>
> Hope this helps catching the bug.
>
> Michael
>
> Kevin Sutter schrieb:
> > Hi Michael,
> > I see that you are running with 1.2.x of OpenJPA, so that's good. I
> thought
> > that the problem you are describing was resolved eons ago. It's one that
> I
> > hit very early on in my tenure with OpenJPA. So, either the problem
> still
> > has a window associated with it, or it was accidentally re-introduced.
> >
> > The problem is that the metadata associated with the Entities in the
> query
> > is not populated yet. You are forcing this metadata to get populated by
> > doing one of your tricks (doing a find before the query, for example).
> >
> > As I think about it more, maybe the "window" still exists in an
> application
> > server, but the original problem was resolved in standalone JSE mode.
> Not
> > sure. What application server are you using? Does it provide the
> necessary
> > hooks for a JPA provider so that OpenJPA can properly enhance the classes
> at
> > startup?
> >
> > I did a quick search in our JIRAs and found this one [1]. But, this
> seems
> > to be related to MappedSuperClasses and it seems to also fail in JSE.
> >
> > There are also several postings to our forums with similar results [2],
> but
> > I'm not sure if these are the exact same scenario as yours. Are you
> > pre-enhancing your Entities? Or, are you relying on the container hook
> to
> > do the dynamic enhancing? Or, are you relying on the runtime enhancement
> > (also known as sub-classing)?
> >
> > More questions than answers, but I really thought this issue was resolved
> a
> > long time ago...
> > Kevin
> >
> >
> > [1] https://issues.apache.org/jira/browse/OPENJPA-1043
> > [2]
> >
> http://n2.nabble.com/Starting-OpenJPA-during-container-startup-td210725.html#a210725
> >
> >
> http://n2.nabble.com/RE%3A-Problem-with-openjpa-enhancer---using-runtime-enhancement-td1608390.html#a1608390
> >
> > On Mon, May 25, 2009 at 7:29 AM, Michael Simons
> > <mi...@optitool.de>wrote:
> >
> >> Hi,
> >>
> >> I've encountered a strange little problem here... When I do the
> >> following locally (in a simple application, not connected to an
> >> Application Server)...
> >>
> >> Query query = em.createQuery("select u from LoginUser u where u.login =
> >> :loginname and u.passwd = :pass"); //$NON-NLS-1$
> >> //... setting Parameters...
> >> LoginUser user = null;
> >> try {
> >> user = (LoginUser)query.getSingleResult ();
> >> } catch (NoResultException noResult) {
> >> System.err.println("NoResult");
> >> }
> >>
> >> ... it works fine, it'll get me the correct "LoginUser" object. But when
> >> I try the same thing in a stateful EJB, the problems start. I'll get the
> >> following error:
> >>
> >> <openjpa-1.2.1-r752877:753278 nonfatal user error>
> >> org.apache.openjpa.persistence.ArgumentException: An error occurred
> >> while parsing the query filter "select u from LoginUser u where u.login
> >> = :loginname and u.passwd = :pass". Error message: The name "LoginUser"
> >> is not a recognized entity or identifier. Known entity names: []
> >>
> >> Funny thing, if I call something like...
> >>
> >> LoginUser user = (LoginUser)em.find(LoginUser.class, 1);
> >>
> >> ...before trying to create the query above, the whole thing will
> >> suddenly work, LoginUser seems to become a recognized Entity (which also
> >> shows, that my classes are correctly enhanced, that the EntityManager
> >> knows them correctly, etc.). It seems, that even though the
> >> EntityManager "knows" the LoginUser Entity (because I can "em.find(...)"
> >> it), it doesn't recognize it in a query.
> >>
> >> If I cast the Query to OpenJPAQuery and there set the ResultClass...
> >>
> >> if (query instanceof OpenJPAQuery) {
> >> OpenJPAQuery opq = (OpenJPAQuery)query;
> >> opq.setResultClass( LoginUser.class );
> >> }
> >>
> >> ...it suddenly seems to work. The big question is: Why is this needed?
> >> Is there a setting I can put into the (OpenJPA)EntityManager, that it
> >> will automatically recognize all of its entities in queries? Or do I
> >> really have to cast to OpenJPAQuery everytime I do a query?
> >>
> >> Regards,
> >>
> >> Michael (The original author Florian did not get a response from the
> list,
> >> after
> >> subscription-verification)
> >>
> >>
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFKHCNx5aNR/9BakrgRAoRaAJ9j0zMzQ27KXLy/9XnwexR0Oz9AtwCdFVLK
> B7tHzJkC1V/zYjJTyWJUGCU=
> =bRbu
> -----END PGP SIGNATURE-----
>
Re: ... is not a recognized entity or identifier.
Posted by Michael Simons <mi...@optitool.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Kevin,
We are using the current stable version of Geronimo AS.
Yes, we are pre-enhancing your Entities.
We now solved (or worked-around) the problem by inserting the following in our persistence.xml:
<property name="openjpa.MetaDataFactory"
value="jpa(Types=net.uniopt.domain.actual.ActualAction;...;net.uniopt.domain.usrmngmt.LoginUser)"/>
Hope this helps catching the bug.
Michael
Kevin Sutter schrieb:
> Hi Michael,
> I see that you are running with 1.2.x of OpenJPA, so that's good. I thought
> that the problem you are describing was resolved eons ago. It's one that I
> hit very early on in my tenure with OpenJPA. So, either the problem still
> has a window associated with it, or it was accidentally re-introduced.
>
> The problem is that the metadata associated with the Entities in the query
> is not populated yet. You are forcing this metadata to get populated by
> doing one of your tricks (doing a find before the query, for example).
>
> As I think about it more, maybe the "window" still exists in an application
> server, but the original problem was resolved in standalone JSE mode. Not
> sure. What application server are you using? Does it provide the necessary
> hooks for a JPA provider so that OpenJPA can properly enhance the classes at
> startup?
>
> I did a quick search in our JIRAs and found this one [1]. But, this seems
> to be related to MappedSuperClasses and it seems to also fail in JSE.
>
> There are also several postings to our forums with similar results [2], but
> I'm not sure if these are the exact same scenario as yours. Are you
> pre-enhancing your Entities? Or, are you relying on the container hook to
> do the dynamic enhancing? Or, are you relying on the runtime enhancement
> (also known as sub-classing)?
>
> More questions than answers, but I really thought this issue was resolved a
> long time ago...
> Kevin
>
>
> [1] https://issues.apache.org/jira/browse/OPENJPA-1043
> [2]
> http://n2.nabble.com/Starting-OpenJPA-during-container-startup-td210725.html#a210725
>
> http://n2.nabble.com/RE%3A-Problem-with-openjpa-enhancer---using-runtime-enhancement-td1608390.html#a1608390
>
> On Mon, May 25, 2009 at 7:29 AM, Michael Simons
> <mi...@optitool.de>wrote:
>
>> Hi,
>>
>> I've encountered a strange little problem here... When I do the
>> following locally (in a simple application, not connected to an
>> Application Server)...
>>
>> Query query = em.createQuery("select u from LoginUser u where u.login =
>> :loginname and u.passwd = :pass"); //$NON-NLS-1$
>> //... setting Parameters...
>> LoginUser user = null;
>> try {
>> user = (LoginUser)query.getSingleResult ();
>> } catch (NoResultException noResult) {
>> System.err.println("NoResult");
>> }
>>
>> ... it works fine, it'll get me the correct "LoginUser" object. But when
>> I try the same thing in a stateful EJB, the problems start. I'll get the
>> following error:
>>
>> <openjpa-1.2.1-r752877:753278 nonfatal user error>
>> org.apache.openjpa.persistence.ArgumentException: An error occurred
>> while parsing the query filter "select u from LoginUser u where u.login
>> = :loginname and u.passwd = :pass". Error message: The name "LoginUser"
>> is not a recognized entity or identifier. Known entity names: []
>>
>> Funny thing, if I call something like...
>>
>> LoginUser user = (LoginUser)em.find(LoginUser.class, 1);
>>
>> ...before trying to create the query above, the whole thing will
>> suddenly work, LoginUser seems to become a recognized Entity (which also
>> shows, that my classes are correctly enhanced, that the EntityManager
>> knows them correctly, etc.). It seems, that even though the
>> EntityManager "knows" the LoginUser Entity (because I can "em.find(...)"
>> it), it doesn't recognize it in a query.
>>
>> If I cast the Query to OpenJPAQuery and there set the ResultClass...
>>
>> if (query instanceof OpenJPAQuery) {
>> OpenJPAQuery opq = (OpenJPAQuery)query;
>> opq.setResultClass( LoginUser.class );
>> }
>>
>> ...it suddenly seems to work. The big question is: Why is this needed?
>> Is there a setting I can put into the (OpenJPA)EntityManager, that it
>> will automatically recognize all of its entities in queries? Or do I
>> really have to cast to OpenJPAQuery everytime I do a query?
>>
>> Regards,
>>
>> Michael (The original author Florian did not get a response from the list,
>> after
>> subscription-verification)
>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFKHCNx5aNR/9BakrgRAoRaAJ9j0zMzQ27KXLy/9XnwexR0Oz9AtwCdFVLK
B7tHzJkC1V/zYjJTyWJUGCU=
=bRbu
-----END PGP SIGNATURE-----
Re: ... is not a recognized entity or identifier.
Posted by Kevin Sutter <kw...@gmail.com>.
Hi Michael,
I see that you are running with 1.2.x of OpenJPA, so that's good. I thought
that the problem you are describing was resolved eons ago. It's one that I
hit very early on in my tenure with OpenJPA. So, either the problem still
has a window associated with it, or it was accidentally re-introduced.
The problem is that the metadata associated with the Entities in the query
is not populated yet. You are forcing this metadata to get populated by
doing one of your tricks (doing a find before the query, for example).
As I think about it more, maybe the "window" still exists in an application
server, but the original problem was resolved in standalone JSE mode. Not
sure. What application server are you using? Does it provide the necessary
hooks for a JPA provider so that OpenJPA can properly enhance the classes at
startup?
I did a quick search in our JIRAs and found this one [1]. But, this seems
to be related to MappedSuperClasses and it seems to also fail in JSE.
There are also several postings to our forums with similar results [2], but
I'm not sure if these are the exact same scenario as yours. Are you
pre-enhancing your Entities? Or, are you relying on the container hook to
do the dynamic enhancing? Or, are you relying on the runtime enhancement
(also known as sub-classing)?
More questions than answers, but I really thought this issue was resolved a
long time ago...
Kevin
[1] https://issues.apache.org/jira/browse/OPENJPA-1043
[2]
http://n2.nabble.com/Starting-OpenJPA-during-container-startup-td210725.html#a210725
http://n2.nabble.com/RE%3A-Problem-with-openjpa-enhancer---using-runtime-enhancement-td1608390.html#a1608390
On Mon, May 25, 2009 at 7:29 AM, Michael Simons
<mi...@optitool.de>wrote:
> Hi,
>
> I've encountered a strange little problem here... When I do the
> following locally (in a simple application, not connected to an
> Application Server)...
>
> Query query = em.createQuery("select u from LoginUser u where u.login =
> :loginname and u.passwd = :pass"); //$NON-NLS-1$
> //... setting Parameters...
> LoginUser user = null;
> try {
> user = (LoginUser)query.getSingleResult ();
> } catch (NoResultException noResult) {
> System.err.println("NoResult");
> }
>
> ... it works fine, it'll get me the correct "LoginUser" object. But when
> I try the same thing in a stateful EJB, the problems start. I'll get the
> following error:
>
> <openjpa-1.2.1-r752877:753278 nonfatal user error>
> org.apache.openjpa.persistence.ArgumentException: An error occurred
> while parsing the query filter "select u from LoginUser u where u.login
> = :loginname and u.passwd = :pass". Error message: The name "LoginUser"
> is not a recognized entity or identifier. Known entity names: []
>
> Funny thing, if I call something like...
>
> LoginUser user = (LoginUser)em.find(LoginUser.class, 1);
>
> ...before trying to create the query above, the whole thing will
> suddenly work, LoginUser seems to become a recognized Entity (which also
> shows, that my classes are correctly enhanced, that the EntityManager
> knows them correctly, etc.). It seems, that even though the
> EntityManager "knows" the LoginUser Entity (because I can "em.find(...)"
> it), it doesn't recognize it in a query.
>
> If I cast the Query to OpenJPAQuery and there set the ResultClass...
>
> if (query instanceof OpenJPAQuery) {
> OpenJPAQuery opq = (OpenJPAQuery)query;
> opq.setResultClass( LoginUser.class );
> }
>
> ...it suddenly seems to work. The big question is: Why is this needed?
> Is there a setting I can put into the (OpenJPA)EntityManager, that it
> will automatically recognize all of its entities in queries? Or do I
> really have to cast to OpenJPAQuery everytime I do a query?
>
> Regards,
>
> Michael (The original author Florian did not get a response from the list,
> after
> subscription-verification)
>
>