From rodgerskatie@example.net Fri Jun 01 09:53:23 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 75625 invoked from network); 1 Jun 2007 09:53:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 09:53:21 -0000 Received: (qmail 18397 invoked by uid 500); 1 Jun 2007 09:22:36 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 18257 invoked by uid 500); 1 Jun 2007 09:22:36 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 18233 invoked by uid 500); 1 Jun 2007 09:22:36 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 18229 invoked by uid 99); 1 Jun 2007 09:22:36 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 02:22:36 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of rodgerskatie@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO ik-out-1112.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 02:22:29 -0700 Received: by ik-out-1112.google.com with SMTP id c30so452802ika for <rodgerskatie@example.net>; Fri, 01 Jun 2007 02:22:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=dUPVzu28X8z41WwIGsV44rdVdtXl9H64sohqiAurRuLKNmzo3R0iGw7D+um+CEiAkKPdxWbX2rMdjVMpXt8JZK6zJGk4ur0+eHXlhyWd0N61Z5a74SqtXk3/p51dYXgRNl/kyH5bZz/6IimT6cyTlrYAnumk1V/K7HmeOP/gTRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SjRpVyxW5+ioyR2UNcEXguIpZniT7WwJtVPvPKuaxLmm903s4etG1Q/bN930AvQv6rrHzoJJezdKeHApT0htCfZ/k8aTo4ubWwxgR6XDDGTIUfjEmElU9dHVTXohNDc5Y41VIagV7Bucaazepk/Kugb04BQC6GvdO2Z+n8P/VdU= Received: by 83.161.120.155 with SMTP id z11mr706691qbq.1180689727574; Fri, 01 Jun 2007 02:22:07 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Fri, 1 Jun 2007 02:22:07 -0700 (PDT) Message-ID: <rodgerskatie@example.net> Date: Fri, 1 Jun 2007 16:22:07 +0700 From: "Joshua Jackson" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: Injecting Entity Manager to POJO/Form Bean MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org Dear all, How do I get the EntityManager injected to my web Form Bean / POJO? Currently I'm deploying my apps that uses openjpa as the persistence implementation on an appserver, but I still can not get the EntityManager injected in my POJO. Where can I find the reference regarding this? Thanks in advance -- YM!: thejavafreak Blog: http://www.nagasakti.or.id/roller/joshua/ From rodgerskatie@example.net Fri Jun 01 12:40:50 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 22363 invoked from network); 1 Jun 2007 12:40:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 12:40:37 -0000 Received: (qmail 14752 invoked by uid 500); 1 Jun 2007 12:40:41 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 14708 invoked by uid 500); 1 Jun 2007 12:40:40 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 14699 invoked by uid 500); 1 Jun 2007 12:40:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 14696 invoked by uid 99); 1 Jun 2007 12:40:40 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:40:40 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:40:35 -0700 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 93796714180 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 05:40:15 -0700 (PDT) Message-ID: <4391076.1180701615580.JavaMail.jira@brutus> Date: Fri, 1 Jun 2007 05:40:15 -0700 (PDT) From: "Daniel Gajdos (JIRA)" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: [jira] Created: (OPENJPA-249) problem using enum with @Enumerated annotation in Query MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org problem using enum with @Enumerated annotation in Query ------------------------------------------------------- Key: OPENJPA-249 URL: https://issues.apache.org/jira/browse/OPENJPA-249 Project: OpenJPA Issue Type: Bug Components: query Affects Versions: 0.9.7 Environment: Windows XP, WAS 6.1 Reporter: Daniel Gajdos Situation description: @Entity public class Application { ... @ManyToOne(optional = false) @JoinColumn(name = "C_APPLICATION_STATUS", nullable = false) @ForeignKey(name = "FK_APPLICATION__APPLICATION_S") private ApplicationStatus applicationStatus; ...} @Entity public class ApplicationStatus { public static enum Code { created } @Id @Column(name = "C_CODE") @Enumerated(EnumType.STRING) private Code code; } And now the problem: When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = :package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From rodgerskatie@example.net Fri Jun 01 12:42:37 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 24814 invoked from network); 1 Jun 2007 12:42:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 12:42:36 -0000 Received: (qmail 22283 invoked by uid 500); 1 Jun 2007 12:42:38 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 22248 invoked by uid 500); 1 Jun 2007 12:42:38 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 22239 invoked by uid 99); 1 Jun 2007 12:42:38 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:42:38 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [83.161.120.155] (HELO sca-es-mail-1.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:42:31 -0700 Received: from fe-sfbay-09.sun.com ([83.161.120.155]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l51CgBQ9023116 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 05:42:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <rodgerskatie@example.net> (original mail from rodgerskatie@example.net) for rodgerskatie@example.net; Fri, 01 Jun 2007 05:42:11 -0700 (PDT) Received: from [83.161.120.155] (host-87-74-63-191.bulldogdsl.com [83.161.120.155]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <rodgerskatie@example.net>; Fri, 01 Jun 2007 05:42:10 -0700 (PDT) Date: Fri, 01 Jun 2007 05:42:07 -0700 From: Craig L Russell <rodgerskatie@example.net> Subject: Re: Injecting Entity Manager to POJO/Form Bean In-reply-to: <rodgerskatie@example.net> Sender: rodgerskatie@example.net To: rodgerskatie@example.net Cc: rodgerskatie@example.net Message-id: <rodgerskatie@example.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-229-531064775; micalg=sha1 References: <rodgerskatie@example.net> X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-229-531064775 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Joshua, The only POJOs that you can inject are server components, e.g. ManagedBean or SessionBean. You can find the complete list in the EJB 3 specification. Regular POJOs cannot be injected. Craig On Jun 1, 2007, at 2:22 AM, Joshua Jackson wrote: > Dear all, > > How do I get the EntityManager injected to my web Form Bean / POJO? > > Currently I'm deploying my apps that uses openjpa as the persistence > implementation on an appserver, but I still can not get the > EntityManager injected in my POJO. Where can I find the reference > regarding this? > > Thanks in advance > > -- > YM!: thejavafreak > Blog: http://www.nagasakti.or.id/roller/joshua/ Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo (901)896-3412 mailto:rodgerskatie@example.net P.S. A good JDO? O, Gasp! --Apple-Mail-229-531064775 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7 16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt /CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6 eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+ hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjAxMTI0MjA4WjAjBgkqhkiG9w0B CQQxFgQUyA+nBpulXlv0s86FYNNVzzEYoBswgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG 9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAAeowNJgTG+qV3hdD+yvYZLSvWtYmp00 CajK72wYj7ruF6meCMydt8kb6TFalc+aykqkk2Ao2h7JD0QRrG47w5IDt33NfZp1T9nBqJsXcA1V 3kv2restTSBetERYFAw/FzH0sjnLN0rFZClva4SNcv/cV62qPCSRm9xhrkGVi1Pbka6mITY/GGWQ vRvap+pRpgvmd4Aki/YvTTDY25t/6RIr5eV/TN8eGhjy+twA3hJBYrQ7EQSUtdoIC0S0nU119qIR A2C5qLxWU+1Q6VAYs/Uv0d75ze/+wLAF79wCNRkI/eoYPFnzb/5l6xF0D65Zj7F3HttYsh8GCgol 3NLVbmkAAAAAAAA= --Apple-Mail-229-531064775-- From rodgerskatie@example.net Fri Jun 01 12:42:38 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 24842 invoked from network); 1 Jun 2007 12:42:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 12:42:36 -0000 Received: (qmail 22449 invoked by uid 500); 1 Jun 2007 12:42:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 22393 invoked by uid 500); 1 Jun 2007 12:42:39 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 22326 invoked by uid 500); 1 Jun 2007 12:42:38 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 22276 invoked by uid 99); 1 Jun 2007 12:42:38 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:42:38 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [83.161.120.155] (HELO sca-es-mail-2.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:42:31 -0700 Received: from fe-sfbay-09.sun.com ([83.161.120.155]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l51CgBoB007232 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 05:42:11 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <rodgerskatie@example.net> (original mail from rodgerskatie@example.net) for rodgerskatie@example.net; Fri, 01 Jun 2007 05:42:11 -0700 (PDT) Received: from [83.161.120.155] (host-87-74-63-191.bulldogdsl.com [83.161.120.155]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <rodgerskatie@example.net>; Fri, 01 Jun 2007 05:42:10 -0700 (PDT) Date: Fri, 01 Jun 2007 05:42:07 -0700 From: Craig L Russell <rodgerskatie@example.net> Subject: Re: Injecting Entity Manager to POJO/Form Bean In-reply-to: <rodgerskatie@example.net> Sender: rodgerskatie@example.net To: rodgerskatie@example.net Cc: rodgerskatie@example.net Message-id: <rodgerskatie@example.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-229-531064775; micalg=sha1 References: <rodgerskatie@example.net> X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-229-531064775 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Joshua, The only POJOs that you can inject are server components, e.g. ManagedBean or SessionBean. You can find the complete list in the EJB 3 specification. Regular POJOs cannot be injected. Craig On Jun 1, 2007, at 2:22 AM, Joshua Jackson wrote: > Dear all, > > How do I get the EntityManager injected to my web Form Bean / POJO? > > Currently I'm deploying my apps that uses openjpa as the persistence > implementation on an appserver, but I still can not get the > EntityManager injected in my POJO. Where can I find the reference > regarding this? > > Thanks in advance > > -- > YM!: thejavafreak > Blog: http://www.nagasakti.or.id/roller/joshua/ Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo (901)896-3412 mailto:rodgerskatie@example.net P.S. A good JDO? O, Gasp! --Apple-Mail-229-531064775 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7 16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt /CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6 eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+ hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjAxMTI0MjA4WjAjBgkqhkiG9w0B CQQxFgQUyA+nBpulXlv0s86FYNNVzzEYoBswgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG 9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAAeowNJgTG+qV3hdD+yvYZLSvWtYmp00 CajK72wYj7ruF6meCMydt8kb6TFalc+aykqkk2Ao2h7JD0QRrG47w5IDt33NfZp1T9nBqJsXcA1V 3kv2restTSBetERYFAw/FzH0sjnLN0rFZClva4SNcv/cV62qPCSRm9xhrkGVi1Pbka6mITY/GGWQ vRvap+pRpgvmd4Aki/YvTTDY25t/6RIr5eV/TN8eGhjy+twA3hJBYrQ7EQSUtdoIC0S0nU119qIR A2C5qLxWU+1Q6VAYs/Uv0d75ze/+wLAF79wCNRkI/eoYPFnzb/5l6xF0D65Zj7F3HttYsh8GCgol 3NLVbmkAAAAAAAA= --Apple-Mail-229-531064775-- From rodgerskatie@example.net Fri Jun 01 12:44:44 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 26280 invoked from network); 1 Jun 2007 12:44:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 12:44:41 -0000 Received: (qmail 27509 invoked by uid 500); 1 Jun 2007 12:44:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 27427 invoked by uid 500); 1 Jun 2007 12:44:40 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 27408 invoked by uid 500); 1 Jun 2007 12:44:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 27400 invoked by uid 99); 1 Jun 2007 12:44:40 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:44:40 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:44:35 -0700 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id DC85B714184 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 05:44:15 -0700 (PDT) Message-ID: <25954256.1180701855900.JavaMail.jira@brutus> Date: Fri, 1 Jun 2007 05:44:15 -0700 (PDT) From: "Daniel Gajdos (JIRA)" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: [jira] Updated: (OPENJPA-249) problem using enum with @Enumerated annotation in Query In-Reply-To: <4391076.1180701615580.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gajdos updated OPENJPA-249: ---------------------------------- Description: Situation description: @Entity public class Application { ... @ManyToOne(optional = false) @JoinColumn(name = "C_APPLICATION_STATUS", nullable = false) private ApplicationStatus applicationStatus; ...} @Entity public class ApplicationStatus { public static enum Code { created } @Id @Column(name = "C_CODE") @Enumerated(EnumType.STRING) private Code code; } And now the problem: When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = :package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 was: Situation description: @Entity public class Application { ... @ManyToOne(optional = false) @JoinColumn(name = "C_APPLICATION_STATUS", nullable = false) @ForeignKey(name = "FK_APPLICATION__APPLICATION_S") private ApplicationStatus applicationStatus; ...} @Entity public class ApplicationStatus { public static enum Code { created } @Id @Column(name = "C_CODE") @Enumerated(EnumType.STRING) private Code code; } And now the problem: When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = :package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 > problem using enum with @Enumerated annotation in Query > ------------------------------------------------------- > > Key: OPENJPA-249 > URL: https://issues.apache.org/jira/browse/OPENJPA-249 > Project: OpenJPA > Issue Type: Bug > Components: query > Affects Versions: 0.9.7 > Environment: Windows XP, WAS 6.1 > Reporter: Daniel Gajdos > > Situation description: > @Entity > public class Application { > ... > @ManyToOne(optional = false) > @JoinColumn(name = "C_APPLICATION_STATUS", > nullable = false) > private ApplicationStatus applicationStatus; > ...} > @Entity > public class ApplicationStatus { > public static enum Code { > created > } > @Id > @Column(name = "C_CODE") > @Enumerated(EnumType.STRING) > private Code code; > } > And now the problem: > When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. > But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = :package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". > Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From rodgerskatie@example.net Fri Jun 01 12:58:33 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 36325 invoked from network); 1 Jun 2007 12:58:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 12:58:32 -0000 Received: (qmail 63830 invoked by uid 500); 1 Jun 2007 12:58:36 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 63800 invoked by uid 500); 1 Jun 2007 12:58:36 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 63791 invoked by uid 99); 1 Jun 2007 12:58:36 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:58:36 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [83.161.120.155] (HELO sca-es-mail-1.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 05:58:31 -0700 Received: from fe-sfbay-10.sun.com ([83.161.120.155]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l51CwAc8023620 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 05:58:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <rodgerskatie@example.net> (original mail from rodgerskatie@example.net) for rodgerskatie@example.net; Fri, 01 Jun 2007 05:58:10 -0700 (PDT) Received: from [83.161.120.155] (host-87-74-63-191.bulldogdsl.com [83.161.120.155]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <rodgerskatie@example.net> for rodgerskatie@example.net; Fri, 01 Jun 2007 05:58:10 -0700 (PDT) Date: Fri, 01 Jun 2007 05:58:08 -0700 From: Craig L Russell <rodgerskatie@example.net> Subject: New alias Sender: rodgerskatie@example.net To: rodgerskatie@example.net Message-id: <rodgerskatie@example.net> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: multipart/signed; protocol="application/pkcs7-signature"; boundary=Apple-Mail-232-532026233; micalg=sha1 X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-232-532026233 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Now that the new alias is in place, we should avoid using the old alias so as not to confuse... Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo (901)896-3412 mailto:rodgerskatie@example.net P.S. A good JDO? O, Gasp! --Apple-Mail-232-532026233 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7 16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt /CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6 eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+ hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNjAxMTI1ODA5WjAjBgkqhkiG9w0B CQQxFgQUTDK+eGtDIs11f46fe8+pG/PjC5QwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG 9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAB70Zisn0yyTB/1iiNukQLTHm1FFY7VM egaQh2qAk/mfv2SU3SZDRcy6XRG9TtwD06wHL41if9fHokGeDOC0iH1Fhflfn166jqm00wpEbkVS CkWSoYLcB2+uMIvXfIBYUD8uIA8Nq1khs2TEYTEX5UxqHgpXcJiXrY2DvPcCuoRQb14xZylrvZH+ H6E0f/WRDAOY4Ky9pjSQQI4kaETQOFwwAyEZcyCdJmYIjKkMQ6Vfaa+nBNk1dSHGXL5F71YqIbOa VIXudspiF9xv9PKcgGiCbiqm26LikWUM2yV7kbb4SmxJzCWRxR/A5ietTbO9Yz0ywbObGaUdmFQD 5hgHXZgAAAAAAAA= --Apple-Mail-232-532026233-- From rodgerskatie@example.net Fri Jun 01 13:26:03 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 53196 invoked from network); 1 Jun 2007 13:26:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 13:26:02 -0000 Received: (qmail 8802 invoked by uid 500); 1 Jun 2007 13:26:05 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 8763 invoked by uid 500); 1 Jun 2007 13:26:05 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 8754 invoked by uid 500); 1 Jun 2007 13:26:05 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 8750 invoked by uid 99); 1 Jun 2007 13:26:05 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:26:05 -0700 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (herse.apache.org: transitioning domain of rodgerskatie@example.net does not designate 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO outmail128159.authsmtp.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:26:00 -0700 Received: from outmail128182.authsmtp.co.uk (outmail128182.authsmtp.co.uk [83.161.120.155]) by punt2.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id l51DPa2B068386 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 14:25:37 +0100 (BST) Received: from [83.161.120.155] (cpe-(901)896-3412.maine.res.rr.com [83.161.120.155]) (authenticated bits=0) by mail.authsmtp.com (8.13.8/8.13.8/Kp) with ESMTP id l51DPS29084727 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 14:25:33 +0100 (BST) Message-ID: <rodgerskatie@example.net> Date: Fri, 01 Jun 2007 09:25:26 -0400 From: "David Ezzio (asmtp)" <rodgerskatie@example.net> User-Agent: Thunderbird 83.161.120.155 (Windows/20070221) MIME-Version: 1.0 To: rodgerskatie@example.net Subject: Re: Comparison Metrics for OpenJPA's ConcurrentHashMap References: <rodgerskatie@example.net> <rodgerskatie@example.net> <rodgerskatie@example.net> In-Reply-To: <rodgerskatie@example.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Server-Quench: 93acf828-1043-11dc-a443-001185d377ca X-AuthRoute: OCdyYw0VAlZZQRYI CyQsBiJJDw4iIwtL GRIFaAlCKR8FWBp5 M0BRM1BaLFoGA1hB UjVTDkoLEgo/WWJq EU8PcgddYk1eXgFg Uk1DQVYcEwF2Bhkf Bx4eTBh7dxpEfWFw KxpnXwQ7P0ZzdU55 RUxTW2sPYWMuYWNO AxZQdQtJcQNOfQJE awQsSSIJZWYaZnph Rl9uM2tuYj5WPh5Y EEkmKlcKSFwKBTk6 DzUPAS8uFlZNSSIp Zzs+J1g+JG9eKQ0Z Nl0qREgCPhkOKgRF H2REGEcg X-Authentic-SMTP: 61633133353031.squirrel.dmpriest.net.uk:671/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Checked: Checked by ClamAV on apache.org Hi Marc, I still was not able to get HighScaleLib to work. It produces a SecurityException when attempting to get the Unsafe object. I decided to avoid changing the relevant security policy. On the other hand, I did test Emory University's backport of the java.util.concurrent package. This provides to Java 1.4 a ConcurrentHashMap implementation that is compatible with the one found in Java 5 and 6. I also realized that I could get another metric from my numbers, the percentage of time the threads were suspended during the metered operations. Then I reran the tests for Emory's backport using fewer threads. In the classic pattern of an overloaded CPU, the higher thread count both lowers throughput and increases response time. (Throughput is yet another number I haven't extracted from the data, although it is obvious when running the tests.) All of the previous tests were run with 5 writing and 10 reading threads. Only backport was additionally tested with 2 writing and 4 reading threads. The suspended percentage is approximate since the adding and updating tests have slightly different numbers. Implementation Add Remove Update Find-a Find-r Find-u Suspended --------------+------+-------+-------+-------+-------+-------+--------- synchronized 103 35 50 40 37 54 concurrent 13.2 6.4 6.1 0.6 0.3 1.1 OpenJPA 29.8 26.6 27.9 0.6 0.6 0.6 Backport (5/10) 43.2 36.8 40.4 0.3 0.2 0.5 62% Backport (2/4) 6.1 3.1 3.3 0.3 0.2 0.3 4% David David Ezzio (asmtp) wrote: > Hi Marc, > > I did plug it in, but it failed straightaway on a security issue. I > should probably read its documentation. :) I'll try it again along with > the backport lib done by Emory U. > > David > > > Marc Prud'hommeaux wrote: >> David- >> >> That is very interesting. >> >> Did you also take a look at the one at >> http://sourceforge.net/projects/high-scale-lib ? They say its >> performance only shines for high thread/cpu counts, but it might be >> interesting to see where its numbers lie in the range. >> >> >> >> On May 29, 2007, at 11:01 AM, David Ezzio (asmtp) wrote: >> >>> Recently, I did some testing of Map implementations under concurrency. >>> >>> My primary purpose was to verify the reliability of OpenJPA's >>> ConcurrentHashMap implementation. As I got into it, I saw the >>> opportunity to get some performance metrics out of the test. >>> >>> The biggest part of my task was coming up with a reliable and useful >>> testing framework. I design it with the following two factors in >>> mind: First, I wanted to test the edge conditions where an entry had >>> just been added or removed or where a key's value had just been >>> updated. The idea is that a number of threads add, remove, and update >>> entries, while other threads check to see if these recent >>> modifications are visible (or in the case of removals, not visible). >>> Second, I wanted the testing framework itself to be free of >>> synchronization. If the testing framework used synchronization then >>> it would tend to serialize the readers and writers and thereby mask >>> concurrency issues in the map implementation under test. >>> >>> The testing framework uses a non-synchronizing, non-blocking FIFO >>> queue as the mechanism for the writing threads to communicate their >>> recent modifications to the reading threads. >>> >>> To prevent writing threads from overwriting recent modifications >>> before they could be read and verified, the testing framework walks >>> the hash map keys in in a linear (or in the case of updates, >>> circular) order. By using a hash map with a large enough capacity, >>> readers have the time to verify the recent modifications before the >>> writer threads come back to modify that part of the key space again. >>> >>> Using an adapter for the map implementation, the testing framework >>> starts five writer threads and ten reader threads at the same time. >>> These threads run wide open for 30 seconds, except that the readers >>> will give up their time slice if they find nothing on the queue. The >>> HashMaps were all sized for the needed capacity upon creation, so no >>> resizing occurred during testing. >>> >>> I got some interesting results. >>> >>> Four implementations were tested, Java's unsynchronized HashMap >>> implementation, Java's synchronized HashMap implementation, Java's >>> ConcurrentHashMap implementation, and OpenJPA's ConcurrentHashMap >>> implementation. >>> >>> Only Java's unsynchronized HashMap failed, as expected, under test. >>> Under test, this implementation demonstrates its inability to handle >>> concurrency. The other three implementations worked flawlessly under >>> test. >>> >>> The java.util.concurrent.ConcurrentHashMap implementation (available >>> with Java 5 and 6) was the fastest implementation tested. >>> >>> Java's synchronized wrapper for the HashMap implementation is one to >>> two orders of magnitude slower than Java's ConcurrentHashMap >>> implementation. >>> >>> OpenJPA's ConcurrentHashMap compares equally with Java's >>> ConcurrentHashMap in find operations and is 2-4 times slower in >>> mutating operations. >>> >>> Implementation Add Remove Update Find-a Find-r Find-u >>> ---------------+------+-------+--------+-------+-------+------ >>> synchronized 103 35 50 40 37 54 >>> concurrent 13.2 6.4 6.1 0.6 0.3 1.1 >>> OpenJPA 29.8 26.6 27.9 0.6 0.6 0.6 >>> >>> >>> Legend: >>> >>> synchronized: >>> java.util.Collections.synchronizedMap(new java.util.HashMap()) >>> concurrent: java.util.concurrent.ConcurrentHashMap >>> OpenJPA: org.apache.openjpa.lib.util.concurrent.ConcurrentHashMap >>> >>> Add: time for average add operation >>> Remove: time for average remove operation >>> Update: time for average update of new value for existing key >>> Find-a: time to find a recent addition >>> Find-r: time to NOT find a recent removal >>> Find-u: time to find a recent update >>> >>> These times (in microseconds) are representative, but are not the >>> average of several runs. The tests were run on a Dell Dual Core >>> laptop under Windows. The performance meter was pegged during the tests. >>> >>> David Ezzio >>> >>> >> >> > > From rodgerskatie@example.net Fri Jun 01 13:44:01 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 61015 invoked from network); 1 Jun 2007 13:44:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 13:44:00 -0000 Received: (qmail 36480 invoked by uid 500); 1 Jun 2007 13:44:04 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 36445 invoked by uid 500); 1 Jun 2007 13:44:04 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 36433 invoked by uid 99); 1 Jun 2007 13:44:04 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:44:04 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of rodgerskatie@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO nz-out-0506.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:43:59 -0700 Received: by nz-out-0506.google.com with SMTP id n1so451865nzf for <rodgerskatie@example.net>; Fri, 01 Jun 2007 06:43:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ce04bLjeb65UUg1kUJ9nLIgKgyMPeF7NVYv1St8D/3TaBOW31bjc1LIoOqOMa7bNLO601137Ydxr3phvJOtZkW0uSd8OHI9AwEsN8F9wkzIidInphDYm7i6b2VPkI1uGFDRvgUl6KI0BBUqBIf8zO/AEUC3c9mQteC92h/QczC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=rZCUpR2NtxrI1DEuln57nBxjdTlw/d69XYLUkrLHWHBoLWaSf3eNHW52Xw1jRk5PfPJ2rfG18ou6j7CFKn2IJZKkauUB+hIY6rEFKu98pWcOSex2hAcD3p2aoUgnOHUuLcr5JCnk/2EfqZE4MCovYpQqcq+1DAWJNBAZ65SwjiI= Received: by 83.161.120.155 with SMTP id f19mr1752982wac.1180705417439; Fri, 01 Jun 2007 06:43:37 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Fri, 1 Jun 2007 06:43:37 -0700 (PDT) Message-ID: <rodgerskatie@example.net> Date: Fri, 1 Jun 2007 08:43:37 -0500 From: "Kevin Sutter" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: Re: New alias In-Reply-To: <rodgerskatie@example.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6084_3334736.1180705417413" References: <rodgerskatie@example.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_6084_3334736.1180705417413 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Good reminder, Craig. Thanks! (I know I was still using the old alias due to my gmail type-ahead...) On 6/1/07, Craig L Russell <rodgerskatie@example.net> wrote: > > Now that the new alias is in place, we should avoid using the old > alias so as not to confuse... > > Craig > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > (901)896-3412 mailto:rodgerskatie@example.net > P.S. A good JDO? O, Gasp! > > > ------=_Part_6084_3334736.1180705417413-- From rodgerskatie@example.net Fri Jun 01 13:51:51 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 65335 invoked from network); 1 Jun 2007 13:51:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 13:51:49 -0000 Received: (qmail 60516 invoked by uid 500); 1 Jun 2007 13:51:41 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 60476 invoked by uid 500); 1 Jun 2007 13:51:41 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 60455 invoked by uid 500); 1 Jun 2007 13:51:41 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 60449 invoked by uid 99); 1 Jun 2007 13:51:40 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:51:40 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:51:36 -0700 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id AE3F5714062 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 06:51:15 -0700 (PDT) Message-ID: <11783056.1180705875693.JavaMail.jira@brutus> Date: Fri, 1 Jun 2007 06:51:15 -0700 (PDT) From: "Daniel Gajdos (JIRA)" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: [jira] Updated: (OPENJPA-249) problem using enum with @Enumerated annotation in Query In-Reply-To: <4391076.1180701615580.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gajdos updated OPENJPA-249: ---------------------------------- Description: Situation description: @Entity public class Application { ... @ManyToOne(optional = false) @JoinColumn(name = "C_APPLICATION_STATUS", nullable = false) private ApplicationStatus applicationStatus; ...} @Entity public class ApplicationStatus { public static enum Code { created } @Id @Column(name = "C_CODE") @Enumerated(EnumType.STRING) private Code code; } And now the problem: When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 was: Situation description: @Entity public class Application { ... @ManyToOne(optional = false) @JoinColumn(name = "C_APPLICATION_STATUS", nullable = false) private ApplicationStatus applicationStatus; ...} @Entity public class ApplicationStatus { public static enum Code { created } @Id @Column(name = "C_CODE") @Enumerated(EnumType.STRING) private Code code; } And now the problem: When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = :package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 I solved it with "SELECT a FROM Application a WHERE a.applicationStatus.code = package.ApplicationStatus$Code.created ". It looks like it's using compiled class name. > problem using enum with @Enumerated annotation in Query > ------------------------------------------------------- > > Key: OPENJPA-249 > URL: https://issues.apache.org/jira/browse/OPENJPA-249 > Project: OpenJPA > Issue Type: Bug > Components: query > Affects Versions: 0.9.7 > Environment: Windows XP, WAS 6.1 > Reporter: Daniel Gajdos > > Situation description: > @Entity > public class Application { > ... > @ManyToOne(optional = false) > @JoinColumn(name = "C_APPLICATION_STATUS", > nullable = false) > private ApplicationStatus applicationStatus; > ...} > @Entity > public class ApplicationStatus { > public static enum Code { > created > } > @Id > @Column(name = "C_CODE") > @Enumerated(EnumType.STRING) > private Code code; > } > And now the problem: > When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. > But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". > Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From rodgerskatie@example.net Fri Jun 01 13:51:51 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 65345 invoked from network); 1 Jun 2007 13:51:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 13:51:49 -0000 Received: (qmail 60531 invoked by uid 500); 1 Jun 2007 13:51:41 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 60479 invoked by uid 500); 1 Jun 2007 13:51:41 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 60456 invoked by uid 500); 1 Jun 2007 13:51:41 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 60450 invoked by uid 99); 1 Jun 2007 13:51:41 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:51:40 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 06:51:36 -0700 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 3DF62714190 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 06:51:16 -0700 (PDT) Message-ID: <4665144.1180705876251.JavaMail.jira@brutus> Date: Fri, 1 Jun 2007 06:51:16 -0700 (PDT) From: "Daniel Gajdos (JIRA)" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: [jira] Closed: (OPENJPA-249) problem using enum with @Enumerated annotation in Query In-Reply-To: <4391076.1180701615580.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Gajdos closed OPENJPA-249. --------------------------------- Resolution: Won't Fix Problem solved using $ in class name > problem using enum with @Enumerated annotation in Query > ------------------------------------------------------- > > Key: OPENJPA-249 > URL: https://issues.apache.org/jira/browse/OPENJPA-249 > Project: OpenJPA > Issue Type: Bug > Components: query > Affects Versions: 0.9.7 > Environment: Windows XP, WAS 6.1 > Reporter: Daniel Gajdos > > Situation description: > @Entity > public class Application { > ... > @ManyToOne(optional = false) > @JoinColumn(name = "C_APPLICATION_STATUS", > nullable = false) > private ApplicationStatus applicationStatus; > ...} > @Entity > public class ApplicationStatus { > public static enum Code { > created > } > @Id > @Column(name = "C_CODE") > @Enumerated(EnumType.STRING) > private Code code; > } > And now the problem: > When executing query "SELECT a FROM Application a WHERE a.applicationStatus = :status" with parameter q.setParameter("status", ApplicationStatus status); everything works fine. > But when trying to call the query like "SELECT a FROM Application a WHERE a.applicationStatus.code = package.ApplicationStatus.Code.created " it fails with: Attempt to query field "package.ApplicationStatus.Code.waiting" from non-entity class "null". > Is there any way to create a query with built in enum value? I found a similar issue on http://forums.oracle.com/forums/thread.jspa?threadID=506389&tstart=45 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From rodgerskatie@example.net Fri Jun 01 16:03:55 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 17173 invoked from network); 1 Jun 2007 16:03:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 16:03:54 -0000 Received: (qmail 11014 invoked by uid 500); 1 Jun 2007 16:03:58 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 10976 invoked by uid 500); 1 Jun 2007 16:03:57 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 10967 invoked by uid 99); 1 Jun 2007 16:03:57 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 09:03:57 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [83.161.120.155] (HELO smtp105.plus.mail.sp1.yahoo.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 01 Jun 2007 09:03:52 -0700 Received: (qmail 6194 invoked from network); 1 Jun 2007 16:03:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=TMWtOMi/AlHbw6ZzxUUG+b+EjktTIuJ5LcmRgcS4PnZeuB7YMNFwS8WLnBqGVC2LvaRtbzq/O2DYbKQCNP0athT7fFrlrh9SGAOc6pAOLklrjxQfeqyNCncrXt0a+eVTepr80qlRnwSdAEqxMoEpL2gF9srF1JFE79oe9wp5Pl0= ; Received: from unknown (HELO ?83.161.120.155?) (rodgerskatie@example.net with plain) by smtp105.plus.mail.sp1.yahoo.com with SMTP; 1 Jun 2007 16:03:31 -0000 X-YMail-OSG: R7H2aPQVM1kikM7Tw6E7FDovbDtnBoRC381F55EwTsFfFAn6hbfGZ3MUQbb4z1K0oGJfcUnnmdpbrd4Zcl3YPr9sm77JC7FRk4Tl3c_Pmx2Gib0JrA-- Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <rodgerskatie@example.net> References: <rodgerskatie@example.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <rodgerskatie@example.net> Content-Transfer-Encoding: 7bit From: David Jencks <rodgerskatie@example.net> Subject: Re: Injecting Entity Manager to POJO/Form Bean Date: Fri, 1 Jun 2007 09:03:56 -0700 To: rodgerskatie@example.net X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org Support for this is completely part of the appserver and not part of openjpa. Are you sure your appserver is completely javaee5 compliant? A couple of comments.... you use a PersistenceContextRef annotation or the equivalent xml the object the EntityManager is to be injected into can't be some arbitrary class, it has to be managed in some way by the app server, such as an EJB class, servlet, app client main class, app client CallbackHandler, or jsf managed bean. Furthermore the container has to create it, not your code. thanks david jencks On Jun 1, 2007, at 2:22 AM, Joshua Jackson wrote: > Dear all, > > How do I get the EntityManager injected to my web Form Bean / POJO? > > Currently I'm deploying my apps that uses openjpa as the persistence > implementation on an appserver, but I still can not get the > EntityManager injected in my POJO. Where can I find the reference > regarding this? > > Thanks in advance > > -- > YM!: thejavafreak > Blog: http://www.nagasakti.or.id/roller/joshua/ From rodgerskatie@example.net Fri Jun 01 16:16:14 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 21973 invoked from network); 1 Jun 2007 16:16:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 16:16:13 -0000 Received: (qmail 28024 invoked by uid 500); 1 Jun 2007 16:16:16 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 27995 invoked by uid 500); 1 Jun 2007 16:16:16 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 27986 invoked by uid 99); 1 Jun 2007 16:16:16 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 09:16:16 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of rodgerskatie@example.net designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO wx-out-0506.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 09:16:11 -0700 Received: by wx-out-0506.google.com with SMTP id h26so531708wxd for <rodgerskatie@example.net>; Fri, 01 Jun 2007 09:15:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=phOpgCP4DTYfhvwzONwRWEC9RRwQDbGaNAZWQ59nYNSZ39Nzd5UGi4SBRnsez3SyLNCsx6xLUvw3D5/TW2Bu0vE623w4JL7XRxuzC7uVJLt7GT2cm28pJEHsKAvSXDdZuXDNsdwY4ARrXXOzNblRXZyt473cOQYguWpb8MxYBbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=cFmLTi+9M+khvtN/RUEQgVQM3I5SPWWPiy/0RSvDV15u4tgAIE2smjjzE+omsoC/37KL0HAd3t5bWpWfRoOHxvAnpHa3l8Ij8iLmYpdtouvH0RiO0jwPl9m882xfKjd4RhAqi4rlqLfdmWbZpwVNvBamZWC3xPVbBrnyHBYCiMY= Received: by 83.161.120.155 with SMTP id f8mr3009908wxa.1180714548848; Fri, 01 Jun 2007 09:15:48 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Fri, 1 Jun 2007 09:15:48 -0700 (PDT) Message-ID: <rodgerskatie@example.net> Date: Sat, 2 Jun 2007 00:15:48 +0800 From: "Philippe Alexis" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: Re: [jira] Commented: (OPENJPA-231) Incorrect handling of cascading bidirectional collections during merge/attach In-Reply-To: <rodgerskatie@example.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5250_6946633.1180714548795" References: <22866639.1177981695494.JavaMail.jira@brutus> <27308434.1178136075518.JavaMail.jira@brutus> <rodgerskatie@example.net> <rodgerskatie@example.net> <rodgerskatie@example.net> <rodgerskatie@example.net> <rodgerskatie@example.net> <rodgerskatie@example.net> <rodgerskatie@example.net> <rodgerskatie@example.net> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_5250_6946633.1180714548795 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Gokhan, I've read your reply to Reece in the thread about the 2nd take at the SQL reordering patch. I generally agree with all that you say. I'll also trust that the more seasoned developers have good reasons for not responding to this JIRA-231 issue; which hopefully wil= l become clearer to me through further acquaintance with the way things work. J-Philippe. On 6/1/07, Gokhan Ergul <rodgerskatie@example.net> wrote: > > Philippe Alexis wrote: > > Hi Gokhan, > > > > On 5/23/07, Gokhan Ergul < rodgerskatie@example.net> wrote: > > > > Philippe Alexis wrote: > > > >> The question is.. Why does OpenJPA expect, even force, the users to > >> > allocate for cascading from child to parent regardless of whether > they > >> mean to or not? > >> > >> I don't think that's the intention, but it's just a glitch. > > > > > > In the source code, the Deity "relations" example has the following: > > > > @OneToOne(cascade=3DCascadeType.ALL) > > private Deity mother; > > > > @OneToOne(cascade=3DCascadeType.ALL) > > private Deity father; > > > > > > The way I see it, OpenJPA is telling users that *they* are doing > > something > > wrong when they merge > > a new parent entity that cascades to its child (also a new entity) whic= h > > doesn't annotate its parent > > with cascade. > > I don't follow you here --it's just an example which illustrates a > certain usage pattern. I'm sure there are other examples where child > entities do not cascade to parent entities. And the fact of the matter > is, it works just fine for one generation (A to B), just not beyond one > generation (A to B to C). > > > > > > There's that, and regarding your mentioning "catching free-riders" > > > >> The way I see it, the intent of "Encountered new object B@..." > >> exception is to catch freeriders, iow, to prevent attaching new object= s > >> where there's no defined cascade-merge relation from (the set of) > >> currently attached object(s). > > > > here's what the JPA specification has got to say: > > ____________________________________________________________________ > > 83.161.120.155 Merging Detached Entity State > > > > =95 If X is a new entity instance, a new managed entity instance X' is > > created > > and the state of X is > > copied into the new managed entity instance X'. > > > > =95 If X is an entity merged to X', with a reference to another entity = Y, > > where cascade=3DMERGE > > or cascade=3DALL is not specified, then navigation of the same associat= ion > > from X' yields a > > reference to a managed object Y' with the same persistent identity as Y= . > > ____________________________________________________________________ > > > > According to the implementation, in the latter case, Y would > > necessarily be > > detached; > > the use-case presented by you shows that it needs not be. > As you point out, spec defines the expected behavior when Y has a > persistent identity, not the case when Y doesn't have it. So the latter > case is left to implementations (or better, a new version of the spec > which covers that as well). Throwing an exception in that case is a > sensible choice imho, except I'm trying to prove that the restriction > should not apply in that particular use-case due to the fact that the > "new" object is already attached. > > > > > Based on the specification, if a new entity B as parent didn't cascade > to > > its new child C, > > and the user attempted a merge(b), the problem shouldn't be about that > > there's no cascading > > specified, but that there's no managed entity C' . > > The advice about cascading would then be just that, an advice. > Well, I wouldn't exactly call that advice, since you'd fail the TCK > tests if you don't follow it ;) > > As I mentioned above, we don't have a problem with what the spec says, > but rather with what it doesn't say. > > > > > J-Philippe. > > > > ------=_Part_5250_6946633.1180714548795-- From rodgerskatie@example.net Fri Jun 01 17:15:38 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 46874 invoked from network); 1 Jun 2007 17:15:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 17:15:37 -0000 Received: (qmail 71227 invoked by uid 500); 1 Jun 2007 17:15:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 71203 invoked by uid 500); 1 Jun 2007 17:15:40 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 71194 invoked by uid 500); 1 Jun 2007 17:15:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 71191 invoked by uid 99); 1 Jun 2007 17:15:40 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 10:15:40 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 10:15:36 -0700 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id B86BA714062 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 10:15:15 -0700 (PDT) Message-ID: <765299.1180718115686.JavaMail.jira@brutus> Date: Fri, 1 Jun 2007 10:15:15 -0700 (PDT) From: "Gokhan Ergul (JIRA)" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: [jira] Commented: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations In-Reply-To: <16358846.1178303115756.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500765 ] Gokhan Ergul commented on OPENJPA-235: -------------------------------------- Marcus, I'm not familiar with the specifics of Reece's patch (yet), but to answer your question from a theoretical point of view: As your example demonstrates, not-nullable FKs are not the only reason for such dependencies. The real issue with ordering statements is not about nullable/not-nullable constraints, but rather with whether the target database supports deferred constraints or not (constraints enforced at transaction commit time, as opposed constraints enforced after each statement). If the target database supports deferred constraints, we'd have no need to reorder statements --assuming that resulting set of rows (or lack of them) at transaction commit do not violate any constraints. Otherwise the transaction will fail anyway, irrespective of if/how you order the statements. On a related note, since you have access to TCK tests, is there any chance you can apply the patch I posted to see if it breaks anything? If we could take that detached testcase out of the picture I'll go ahead mark OPENJPA-231 resolved, since the issue with attached testcase is the same with this one. Thanks, Gokhan. > SQL reordering to avoid non-nullable foreign key constraint violations > ---------------------------------------------------------------------- > > Key: OPENJPA-235 > URL: https://issues.apache.org/jira/browse/OPENJPA-235 > Project: OpenJPA > Issue Type: Improvement > Components: kernel > Reporter: Reece Garrett > Assignee: Patrick Linskey > Fix For: 0.9.8 > > Attachments: merge-detached.patch, merge-multigen-collection-testcase.zip, openjpa-235-test.jar, openjpa-235-test1.jar, sqlreorder.patch, sqlReorder2.patch > > > OpenJPA does not do any SQL statement re-ordering in order to resolve foreign key constraints. Instead, objects are always inserted in the order in which the user persists the instances. When you persist in an order that would violate foreign key constraints, OpenJPA attempts to insert null and then update the foreign key value in a separate statement. If you use non-nullable constraints, though, you must persist your objects in the correct order. > This improvement re-orders SQL statements as follows: > 1. First, all insert statements execute. Inserts which have foreign keys with non-nullable constraints execute AFTER the foreign keys which they depend on have been inserted since no deferred update is possible. > 2. Next, all update statements execute. No reordering is necessary. > 3. Finally, all delete statements execute. Like inserts, deletes execute in an order which does not violate non-nullable foreign key constraints. > If a circular foreign key reference is found during the re-ordering process then re-ordering halts and the remaining unordered statements are left as is. There is nothing that can be done about the circular reference (other than fixing the schema) and the resulting SQL statements will not succeed. > The net effect is that users do not need to worry about the persistence order of their objects regardless of non-nullable foreign key constraints. The only class modified was org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager. I have included a patch which includes my modifications to OperationOrderUpdateManager and test cases. The test cases I have provided fail on the current trunk but pass with my modifications. I have also verified that I did not break anything by using maven to run all test cases with my modifications in place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From rodgerskatie@example.net Fri Jun 01 17:21:38 2007 Return-Path: <rodgerskatie@example.net> Delivered-To: rodgerskatie@example.net Received: (qmail 48025 invoked from network); 1 Jun 2007 17:21:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Jun 2007 17:21:37 -0000 Received: (qmail 78090 invoked by uid 500); 1 Jun 2007 17:21:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 78069 invoked by uid 500); 1 Jun 2007 17:21:40 -0000 Mailing-List: contact rodgerskatie@example.net; run by ezmlm Precedence: bulk List-Help: <mailto:rodgerskatie@example.net> List-Unsubscribe: <mailto:rodgerskatie@example.net> List-Post: <mailto:rodgerskatie@example.net> List-Id: <dev.openjpa.apache.org> Reply-To: rodgerskatie@example.net Delivered-To: mailing list rodgerskatie@example.net Received: (qmail 78056 invoked by uid 500); 1 Jun 2007 17:21:40 -0000 Delivered-To: rodgerskatie@example.net Received: (qmail 78053 invoked by uid 99); 1 Jun 2007 17:21:40 -0000 Received: from herse.apache.org (HELO herse.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 10:21:40 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 10:21:35 -0700 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id A9C61714186 for <rodgerskatie@example.net>; Fri, 1 Jun 2007 10:21:15 -0700 (PDT) Message-ID: <7780128.1180718475691.JavaMail.jira@brutus> Date: Fri, 1 Jun 2007 10:21:15 -0700 (PDT) From: "Reece Garrett (JIRA)" <rodgerskatie@example.net> To: rodgerskatie@example.net Subject: [jira] Commented: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations In-Reply-To: <16358846.1178303115756.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500768 ] Reece Garrett commented on OPENJPA-235: --------------------------------------- Markus, That is great news! Thanks for running those test and getting back to me. Dereferenced means that a persistence capable object was either nulled or replaced. I need to capture this information because the dereference may cause a delete. If that is the case, then by the time the code gets to OperationOrderUpdateManager there is no way to calculated the dependency between the delete and the update which caused it without knowing who dereferenced who. As a concrete example: A has a non-nullable reference to B and no one else refers to B. You replace B with B2 thus dereferencing B. B is now orphaned and will be deleted. You get three rows generated: Row 1: insert B2 Row 2: update A to point to B2 Row 3: delete B So, row 2 depends on row 1 and row 3 depends on row 2. But, without knowing that the state manager for row 2 was responsible for dereferencing the state manager for row 3 (thus causing the delete) there is no way to know that row 3 depends on row 2. Without having that dependency row 3 could be run before row 2 and would violate the foreign key constraint. As for your second question, no, non-nullable foreign keys are not the only reason for constraint dependencies. Unique key constraints also cause dependencies. With unique keys an insert can depend on an update or delete and an update can depend on another update or delete. I mentioned earlier that I have a plan for dealing with this but decided that it would be best complete my patch for foreign keys first and then tackle uniques. I have a post on the mailing list where I get into a bit more detail. The post was placed on May 22nd and is titled "SQL ordering and unique constraints". Hope that all made sense. If you have any more questions please ask away. Gokhan, I'm sorry but I have not had a chance to apply your patch and try my code with it yet. I'll try my best to get to it but assuming your patch corrects the problem I was running into I see no reason why it won't work. I'm being lazy by not looking but have you posted your issue as a bug
{'source': 'Apache Software Foundation Public Mail Archives'}