Return-Path: 
 <users-return-4678-apmail-openjpa-users-archive=openjpa.apache.org@openjpa.apache.org>
Delivered-To: apmail-openjpa-users-archive@minotaur.apache.org
Received: (qmail 32627 invoked from network); 26 May 2009 18:05:02 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 26 May 2009 18:05:02 -0000
Received: (qmail 44926 invoked by uid 500); 26 May 2009 18:05:14 -0000
Delivered-To: apmail-openjpa-users-archive@openjpa.apache.org
Received: (qmail 44870 invoked by uid 500); 26 May 2009 18:05:14 -0000
Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@openjpa.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@openjpa.apache.org>
List-Post: <mailto:users@openjpa.apache.org>
List-Id: <users.openjpa.apache.org>
Reply-To: users@openjpa.apache.org
Delivered-To: mailing list users@openjpa.apache.org
Received: (qmail 44860 invoked by uid 99); 26 May 2009 18:05:14 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 May 2009 18:05:14 +0000
X-ASF-Spam-Status: No, hits=2.2 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of michael.d.dick@gmail.com
 designates 209.85.220.174 as permitted sender)
Received: from [209.85.220.174] (HELO mail-fx0-f174.google.com)
 (209.85.220.174)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 May 2009 18:05:04 +0000
Received: by fxm22 with SMTP id 22so4031057fxm.9
        for <users@openjpa.apache.org>; Tue, 26 May 2009 11:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:message-id:subject:from:to:content-type;
        bh=WEJ/Iq9gkfC8FtIjqp1ZDWGK4grzjZJVhepmPqIC1xw=;
        b=vFlbAb2EnLOeQLy3MIdXEfCO17+irIWZhFqEhmA/rr/9bzggzmFieCVrOSJe1rtbz+
         ZlR31nulodfo9nKdEWw3ycnGZ69g9xYxSKZD1bLsyiHZyOTvKZ5fkUf2MhGrgdwrrPQo
         0STDGSzleNUflpIm48ahYVLVsyQxznxhHVjbA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=M9RhBF8j5w69oOCZWO1ro2w0EaeNKVte965ONGSJbjuP5zaqgL2hNi0BhKq5wV6CJX
         QirVHbSNTPKiMGtQuKA9SJemg0J4kOnuD6rsvVXiCGh08b7BWL7/kxw8JPpw5UKOI6SG
         O9SBRY80VIPt733NBrcHl8AIsLprgzwKE2CVo=
MIME-Version: 1.0
Received: by 10.223.103.194 with SMTP id l2mr4613468fao.55.1243361082550;
 Tue,
	26 May 2009 11:04:42 -0700 (PDT)
In-Reply-To: <89c0c52c0905261027l47f9754cx550e03df37c87d5a@mail.gmail.com>
References: <4A1A8F39.7030309@optitool.de>
	 <89c0c52c0905260846q6e717157k66ce59d0f50f13b3@mail.gmail.com>
	 <4A1C2371.1080902@optitool.de>
	 <89c0c52c0905261027l47f9754cx550e03df37c87d5a@mail.gmail.com>
Date: Tue, 26 May 2009 13:04:42 -0500
Message-ID: <72c1350f0905261104yd79b21cl63b73b1932e7e831@mail.gmail.com>
Subject: Re: ... is not a recognized entity or identifier.
From: Michael Dick <michael.d.dick@gmail.com>
To: users@openjpa.apache.org
Content-Type: multipart/alternative; boundary=00504502d7e8a72a23046ad48fa5
X-Virus-Checked: Checked by ClamAV on apache.org

--00504502d7e8a72a23046ad48fa5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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-----
> >
>

--00504502d7e8a72a23046ad48fa5--