openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <ppod...@apache.org>
Subject Re: ... is not a recognized entity or identifier.
Date Tue, 26 May 2009 21:51:41 GMT

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 <kwsutter@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
>> > > <michael.simons@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.


Mime
View raw message