Re: Mapping of "empty" Embeddables

[Jeremy Bauer]

Tobias,

A feature[1] was added to OpenJPA 2.2.1 (and later) that *may* provide the
behavior you are looking for.  It allows embeddable entities to be treated
as true null references if they are marked lazy.  One difference is that
they are lazy, so if you detach the entity it will not load the embeddable
when you try to access it.  You need to use a custom annotation or
OpenJPA's ORM extensions to get this behavior.  Check out the commits
associated with the JIRA if you need an example of how to use this feature
with ORM extensions.  WebSphere allows the use of OpenJPA annotations for
application usage so unless you have a policy against using non-spec APIs,
using annotations is much simpler than creating a custom orm file.

example:

import org.apache.openjpa.persistence.Persistent;
...
@Persistent(fetch=FetchType.LAZY, embedded=true)
private MyEmbeddable myEmbed;

The @Persistent annotation is used instead of @Embedded.

I'm not sure if this will give you exactly what you are looking for, but I
think it is worth checking out.  I'm afraid that if you need to access the
embeddable, which will trigger a load, you could end up with the same
behavior you have now.  I don't recall the exact behavior of the feature,
though.

-Jeremy

[1] https://issues.apache.org/jira/browse/OPENJPA-2141

On Tue, Aug 6, 2013 at 10:59 AM, Meyer, Tobias
wrote:

>  Hi,
>
>
>
> I am migrating an application from Glassfish/EclipseLink to
> WebSphere/OpenJPA 2.2.2 and I have to following problem.
>
> Eclipselink and OpenJPA handle “empty” Embeddables (i.e. Embeddables with
> all fields null) differently.
>
> OpenJPA’s default assumption is that an Embeddable is always “non-null”,
> but EclipseLink does the opposite, meaning if all persistent members are
> null, the whole Embeddable is null.
>
>
>
> The application heavily uses validation annotations on the members of the
> embeddables and @NotNull is one of them.
>
> Now think of an entity that contains an embeddable which may be null.
> There is no problem in persisting the entity. There is also no problem when
> you try to load that entity from the database. But when you modify some
> attribute of the entity and OpenJPA tries to update it in the database,
> then you get a javax.validation.ConstraintViolationException because
> OpenJPA validated the “empty” embeddable it created when it loaded the
> entity from the database and there is a @NotNull annotation on a member of
> the embeddable which is now null.
>
>
>
> I know this isn’t a bug of OpenJPA since JPA does not specify what to
> expect when all members of an Embeddable are null.
>
> But my question is: *Is there a way to configure OpenJPA (globally) to
> behave like eclipselink in the case of “empty” embeddables*, without the
> need to use OpenJPA specific annotations in the code like
> “@EmbeddedMapping(nullIndicatorColumnName=”xyz”)?
>
> The java code has to be strictly JPA provider neutral, because the
> application (EAR) has to work on both platforms. Provider specific
> properties in persistence.xml or other configuration files, which don’t
> interfere with EclipseLink would be okay.
>
>
>
> Thanks for your help,
>
> Tobias
>
>
>
> ___
>
> [image: Email_CBE.gif]*Tobias Meyer*
>
> Custom Solution Development | Application Services
>
>
>
> Capgemini | Hamburg
>
> Phone: +4940254491291 – Mobile: +4915140250554
>
> e-mail: tobias.me...@capgemini.com
>
> www.de.capgemini.com
>
>
>
> Luebecker Strasse 128, D-22087 Hamburg, Germany
>
> *People matter, results count.*
>
> ___
>
>
>
> --
>
> Firma: Capgemini Deutschland GmbH
> Geschäftsführer: Dr. Michael Schulte (Sprecher) • Dr. Uwe Dumslaff • Josef
> Ranner
> Aufsichtsratsvorsitzender: Antonio Schnieder
> Amtsgericht Berlin-Charlottenburg, HRB 98814
>  This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient, you
> are not authorized to read, print, retain, copy, disseminate, distribute,
> or use this message or any part thereof. If you receive this message in
> error, please notify the sender immediately and delete all copies of this
> message.
>

Re: record delete during flo

[Jeremy Bauer]

Glad to hear you were able to resolve this issue.  Thanks for replying back
to the list.

-Jeremy

On Mon, Jul 15, 2013 at 5:54 PM, mysakjs  wrote:

> Update:   This turned out to be a code issue.The managed entity was
> being
> updated in an unexpected location and when the transaction was committed
> the
> associated db rows were deleted.   So this does not appear to be a JPA
> issue,  but a code issue.
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/record-delete-during-flo-tp7584399p7584424.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

[CVE-2013-1768] Apache OpenJPA security vulnerability

[Jeremy Bauer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
CVE-2013-1768: Apache OpenJPA security vulnerability

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:

OpenJPA 1.0.0 to 1.0.4
OpenJPA 1.1.0
OpenJPA 1.3.0
OpenJPA 1.2.0 to 1.2.2
OpenJPA 2.0.0 to 2.0.1
OpenJPA 2.1.0 to 2.1.1
OpenJPA 2.2.0 to 2.2.1

Description: Deserialization of a maliciously crafted OpenJPA object can
result in an executable file being written to the file system. An
attacker needs to discover an unprotected server program to exploit the
vulnerability.  It then needs to exploit another unprotected server
program to execute the file and gain access to the system.  OpenJPA
usage by itself does not introduce the vulnerability.

Mitigation: Users of OpenJPA using a release based upon the JPA 1.0
specification level should upgrade to the OpenJPA 1.2.3 release.  Users
of OpenJPA using a release based upon the JPA 2.0 specification level
should upgrade to the OpenJPA 2.2.2 release.  Users needing to stay on
their current release should get the latest code from svn for the
corresponding branch level or apply a source patch and build a new
binary package.  Nightly snapshots of the latest source builds are also
available for many branches.

OpenJPA release branch levels and corresponding fix revisions:

OpenJPA 1.0.x revision 1462558:
http://svn.apache.org/viewvc?view=revision&revision=1462558
OpenJPA 1.1.x revision 1462512:
http://svn.apache.org/viewvc?view=revision&revision=1462512
OpenJPA 1.2.x revision 1462488:
http://svn.apache.org/viewvc?view=revision&revision=1462488
OpenJPA 1.3.x revision 1462328:
http://svn.apache.org/viewvc?view=revision&revision=1462328
OpenJPA 2.0.x revision 1462318:
http://svn.apache.org/viewvc?view=revision&revision=1462318
OpenJPA 2.1.x revision 1462268:
http://svn.apache.org/viewvc?view=revision&revision=1462268
OpenJPA 2.2.1.x revision 1462225:
http://svn.apache.org/viewvc?view=revision&revision=1462225
OpenJPA 2.2.x revision 1462076:
http://svn.apache.org/viewvc?view=revision&revision=1462076

Example: An attacker creates a customized serialization of an OpenJPA
object.  The attacker exploits an unprotected server program to execute
the object.  The object includes logic that results in malicious trace
being written to a file, such as a JSP.  The file containing malicious
commands is written to a potentially vulnerable area of the system.  The
attacker exploits a second unprotected server program to execute the
file and gain access to the system.

Credit: This issue was discovered by Pierre Ernst of IBM Corporation.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
iQIcBAEBAgAGBQJRuMz9AAoJEALD36U3PPjRdzMQAKYkGuFQ/jT6Txy5UemN7oC3
bAUsJRlAsV11uZTnTNo4hgtZVA9Q9fN2NbswjcWFS+/U1MljgrF9lqHspm/SV9o5
Yi4S39AtMKva0eBMGaRGBpARhu7QbMOxD7D9dqp79bHcgxfZROG71bwx4dTL3q3Z
3dxOEnkqPUM9vZFm3zrMKF4Hy3q/TuMIJtFtj/B5KuNtlJFXUe908wzoQyQjm9Al
M7xZhWGdGnVwD1ynlrG5exWZ8xlQ5W4TGeK/h3zJ05kYQHXIwhgiympApNfIYCQZ
1zexnGv7pWQI/NVXPv8XaxtZ6HYUn+1GpZ8ipF4nCoXy0KTfLJmd9wcpxU8b+4c1
tguzC8rYbol7TxkMy/HpAgHTavIfDXFZyjl5/z2X6e+s6YtP+TRCN8Jy7fpg0AuU
OFQp+LoY06vFJmoJiL0+TiNeotcZuH1l8OL6PuvXHF/4saAUfADNHqJIR5xBTdPY
rIy8gtS06IM6aOhSbCrJphIpSOk5qQQV5Uhzfo5NXFeglBxP+YEPFq5sBmVIPEOG
IL6u6CAclmMKg+vqXUeY1EsmV2lrhqshyBh7umTSSm7YWNgoQJJxUn/8phxATJ3K
DlaZWId//mmnz36349m9HF2hc5iPea01MDcWHUwe2a0d0Wmwz6CXlvWuBNtTmZoV
7iGIxMiN7yJ14RZoDsKw
=LVgy
-END PGP SIGNATURE-

Re: FieldStrategy found

[Jeremy Bauer]

I'm very glad to hear you got this working.  If you don't mind and can
share the root issue and solution, we may be able to improve OpenJPA and/or
it may help someone with the same or similar issue.  Regardless, thanks for
the follow-up!

-Jeremy


On Tue, Jun 4, 2013 at 8:43 AM, rwheeler  wrote:

> Thanks for all of the help I finally got this working
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/FieldStrategy-not-found-tp7584021p7584069.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: FieldStrategy found

[Jeremy Bauer]

It looks like the strategy you've defined isn't being picked up on the
annotation scan.  If it were a problem related to loading your
handler/strategy class, you see an exception from createEntityManager().
The most common cause is a missing OSGi bundle import.  I've also seen
cases where this issue is caused by having multiple copies of OpenJPA
binaries in the environment, each being loaded by different classloaders.
That can result in the @Strategy class being scanned by the runtime !=
@Strategy class used by the application.  Beyond that, you might look into
using the OSGi console, if possible, to determine whether your bundle is
able to resolve the import.

-Jeremy


On Fri, May 24, 2013 at 1:36 PM, rwheeler  wrote:

> Sorry yes I am in OSGI enviroment.  I do have
> org.apache.openjpa.persistence.jdbc being imported.  This is what I have
> from my trace log for that particular field 39598  camel  TRACE  [Camel
> (557-camel-32) thread #19 - timer://myTimer] openjpa.MetaData - "id"
> has
> mapping strategy
> "org.apache.openjpa.jdbc.meta.strats.HandlerFieldStrategy".
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/FieldStrategy-not-found-tp7584021p7584023.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: FieldStrategy found

[Jeremy Bauer]

Hi,

Are you in an OSGi environment?  If so, make sure you have a package import
for the org.apache.openjpa.
persistence.jdbc package.  Otherwise, the Strategy annotation won't be
visible from the classloader.  OpenJPA will not find the annotation when it
scans the entity class.  If you are not using OSGi or have the import, the
next step would be to take an openjpa trace via:



The trace will show which strategy is used for each field mapping.
Minimally, you'll be able to see whether the strategy you've defined is
being used.

Also, you likely don't need to implement a field strategy from zero.
Instead, you can extend one of the OpenJPA handlers.   This blog may help:
http://www.webspherepersistence.blogspot.com/2009/04/custom-orm-with-openjpa.html

hth,
-Jeremy


On Fri, May 24, 2013 at 12:45 PM, rwheeler  wrote:

> I am trying to implement a @Strategy using the FieldStrategy interface.
>  The
> problem I am having is that when I go to persist my object it is always
> going with the default handlers. I am not receiving any exceptions until it
> goes to do the insert.  I am wondering if I have done this correctly or not
> so any feedback is appreciated.
>
> package test.openjpa.entity;
>
> import java.io.Serializable;
> import java.util.UUID;
> import javax.persistence.Column;
> import javax.persistence.Entity;
> import javax.persistence.Id;
> import javax.persistence.PrePersist;
> import org.apache.openjpa.persistence.jdbc.Strategy;
>
> @Entity
> public class Company implements Serializable   {
> /**
>  *
>  */
> private static final long serialVersionUID = 6741913908217906576L;
>
> @Id
> @Strategy("test.openjpa.entity.OpenUuid")
> protected UUID id;
>
> @Column(name="name")
> private String companyName;
>
> public String getCompanyName() {
> return companyName;
> }
>
> public void setCompanyName(String companyName) {
> this.companyName = companyName;
> }
>
>
> @Override
> public String toString() {
> StringBuilder sb = new StringBuilder();
> sb.append("Id = ").append(id).append(" - ");
> sb.append("Name = ").append(companyName);
> return sb.toString();
> }
>
>
> public UUID getId() {
> return id;
> }
> public void setId(UUID id) {
> this.id = id;
> }
> @PrePersist
> public void assignUUID(){
> this.setId(UUID.randomUUID());
> }
> }
>
> package test.openjpa.entity;
>
> import java.sql.SQLException;
> import java.util.UUID;
> import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
> import org.apache.openjpa.jdbc.kernel.JDBCStore;
> import org.apache.openjpa.jdbc.meta.FieldMapping;
> import org.apache.openjpa.jdbc.meta.FieldStrategy;
> import org.apache.openjpa.jdbc.sql.Joins;
> import org.apache.openjpa.jdbc.sql.Result;
> import org.apache.openjpa.jdbc.sql.RowManager;
> import org.apache.openjpa.jdbc.sql.SQLBuffer;
> import org.apache.openjpa.jdbc.sql.Select;
> import org.apache.openjpa.jdbc.sql.SelectExecutor;
> import org.apache.openjpa.kernel.OpenJPAStateManager;
> import org.apache.openjpa.persistence.jdbc.Strategy;
>
>
> public class OpenUuid implements FieldStrategy {
>
> /**
>  *
>  */
> private static final long serialVersionUID = -7313412704454986736L;
>
>
> public class PostgresUuid extends org.postgresql.util.PGobject {
> public static final long serialVersionUID = 89469482L;
>
> public PostgresUuid(UUID u) throws java.sql.SQLException {
> super();
> this.setType("uuid");
> this.setValue(u.toString());
> }
>
> public PostgresUuid() throws java.sql.SQLException {
> super();
> this.setType("uuid");
> this.setValue(null);
> }
> }
>
> @Override
> public String getAlias() {
> // TODO Auto-generated method stub
> return null;
> }
>
> @Override
> public void map(boolean adapt) {
> // TODO Auto-generated method stub
>
> }
>
> @Override
> public void initialize() {
> // TODO Auto-generated method stub
>
> }
>
> @Override
> public void insert(OpenJPAStateManager sm, JDBCStore store,
> RowManager rm)
> throws SQLException {
> System.out.println("I am inside the insert");
>
> }
>
> @Override
> public void update(OpenJPAStateManager sm, JDBCStore store,
> RowManager rm)
> throws SQLException {
> // TO

[ANNOUNCE] OpenJPA 1.2.3 Released

[Jeremy Bauer]

The Apache OpenJPA community is proud to announce the release of OpenJPA
1.2.3.

Please visit our project website to learn more about Apache OpenJPA and
how to download or include our persistence provider in your builds.

http://openjpa.apache.org/

Apache OpenJPA PMC

Re: generate jpa entities without schema name included in @Table annotation

[Jeremy Bauer]

Hi,

The reverse mapping tool can operate over multiple schemas so the table
annotation includes the schema name to ensure that the mappings match.  I
checked the code and config and didn't spot any way to change this behavior
with the existing configuration options.

The only option that came to mind is to write a custom MetaDataFactory
plugin that supplies a custom AnnotationPersistenceMappingSerializer.  Your
custom serializer would then need to override the
serializeClassMappingContent method.  This method calls the (private)
serializeTable method to create the @Table annotation that is used in the
generated Java source.  You could easily write your own version of
serializeTable to eliminate the schema name from the annotation.  A little
tedious and a little extra configuration, but doable...

This seems like a useful general feature for the reverse mapping tool,
though.  A switch to disable adding the schema name to the mapping should
be fairly simple to add.  You could open a JIRA for the feature request -
https://issues.apache.org/jira/browse/OPENJPA.  If you come up with a patch
you could contribute it to the project or someone else in the community may
pick up the JIRA and code up the feature.

-Jeremy


On Mon, Apr 1, 2013 at 3:57 PM, mysakjs  wrote:

> Is there an option for org.apache.openjpa.jdbc.meta.ReverseMappingTool that
> will effectively avoid adding the schema name for the @Table annotation on
> generated entities?
>
> I want to remove the schema name so the jpa entities don't have to be
> updated in order to target an alternate set of schemas.  (instead we'll use
> openjpa.jdbc.Schema to set the default schema in persistence.xml ).
>
> -useSchemaName=false doesn't seem to help, as it only affects whether or
> not
> the schema name is included in the generated class name.
>
> Is there another property I can set for this, e.g. to avoid having to
> post-process the entities to remove the schema name from the @Table
> annotation?
>
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/generate-jpa-entities-without-schema-name-included-in-Table-annotation-tp7583310.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: AW: OpenJPA transactions

[Jeremy Bauer]

I'm not very familiar with how transaction management works within
Aries, but for JPA in general, if you are using JTA transactions you
should not use em.getTransaction().begin().  That API should only be
used for resource local transactions (non-JTA, direct to the
database).  It looks like the Aries site has some good JPA related
information here:  http://aries.apache.org/modules/jpaproject.html.
In particular, take a look at incidentDAO.  That bean has a
container-managed transactional element specified.  I suspect you'll
need to do something similar in your application.

hth,
Jeremy

On Wed, Mar 28, 2012 at 11:54 AM, javidelgadillo  wrote:
> Bobitz,
>
> Thanks for the suggestion, but that didn't make a difference.
>
> As an FYI, here's the output when I start Karaf:
> 31  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.Runtime -
> Setting the following properties from "?" into configuration:
> {javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl,
> openjpa.RuntimeUnenhancedClasses=unsupported,
> javax.persistence.sharedCache.mode=UNSPECIFIED,
> openjpa.Log=DefaultLevel=TRACE, PersistenceVersion=1.0,
> openjpa.Id=metadataPersistenceUnit, openjpa.ConnectionFactoryMode=managed,
> openjpa.ConnectionFactory=org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource@556aa9,
> javax.persistence.validation.mode=AUTO,
> openjpa.jdbc.SynchronizeMappings=buildSchema,
> openjpa.ManagedRuntime=jndi(TransactionManagerName=osgi:service/javax.transaction.TransactionManager),
> openjpa.TransactionMode=managed,
> openjpa.MetaDataFactory=jpa(Types=MetadataEntity),
> openjpa.ClassResolver=org.apache.openjpa.persistence.PersistenceUnitInfoImpl$ClassResolverImpl@157c76a,
> openjpa.ConnectionFactory2=org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource@1cdbaf7}
> 46  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.Runtime - No
> cache marshaller found for id
> org.apache.openjpa.conf.MetaDataCacheMaintenance.
> 202  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.MetaData -
> Scanning resource "META-INF/orm.xml" for persistent types.
> 202  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.MetaData -
> The persistent unit root url is "null"
> 202  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.MetaData -
> parsePersistentTypeNames() found [MetadataEntity].
> 202  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.MetaData -
> Found 1 classes with metadata in 15 milliseconds.
> 0  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.Runtime -
> Setting the following properties from "?" into configuration:
> {openjpa.BrokerFactory=jdbc,
> javax.persistence.provider=org.apache.openjpa.persistence.PersistenceProviderImpl,
> openjpa.RuntimeUnenhancedClasses=unsupported,
> javax.persistence.sharedCache.mode=UNSPECIFIED,
> openjpa.Log=DefaultLevel=TRACE, PersistenceVersion=1.0,
> openjpa.Id=metadataPersistenceUnit, openjpa.ConnectionFactoryMode=managed,
> openjpa.ConnectionFactory=org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource
> @556aa9, javax.persistence.validation.mode=AUTO,
> openjpa.jdbc.SynchronizeMappings=buildSchema,
> openjpa.ManagedRuntime=jndi(TransactionManagerName=osgi:service/javax.transaction.TransactionManager),
> openjpa.TransactionMode=managed, openjpa.BrokerImpl=non-finalizing,
> openjpa.MetaDataFactory=jpa(Types=MetadataEntity),
> openjpa.ClassResolver=org.apache.openjpa.persistence.PersistenceUnitInfoImpl$ClassResolverImpl@157c76a,
> openjpa.ConnectionFactory2=org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource@1cdbaf7}
> 109  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.Runtime - Not
> creating a ValidatorImpl because this app is using the JPA 1.0 Spec
> 203  metadataPersistenceUnit  TRACE  [FelixStartLevel] openjpa.Runtime -
> org.apache.openjpa.persistence.PersistenceProviderImpl@1f543bb creating
> container org.apache.openjpa.persistence.EntityManagerFactoryImpl@131cfec
> for PU metadataPersistenceUnit.
>
>
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/OpenJPA-transactions-tp7411924p7414446.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: CLOB loading - query per row

[Jeremy Bauer]

Hi Simon,

What database are you using?  Each DB/JDBC driver handles retrieving
lob data differently (although, that is continually getting better and
more standardized with new rev's of JDBC).  Some DBs allow inlining,
sometimes they requires a separate fetch or vendor specific API.
Normally, this via DB/driver specific code is isolated in the DB
dictionaries.  It is odd that OpenJPA is behaving differently with one
path vs. another, though.  Any chance you could post a very simple
testcase?

-Jeremy

On Mon, Feb 6, 2012 at 6:19 PM, Simon Droscher
 wrote:
> Hi.
>
> Just wondering if anyone had encountered a similar issue to us with CLOB
> loading and/or can explain the behaviour:
>
> When we have entities with CLOB fields and do a EntityManager.get() of one
> of those objects, OpenJPA will load the CLOBs with the rest of the data as
> part of a single query. But when we load the same object using a named
> query, for example "SELECT t FROM Thing t WHERE t.code = ?1", OpenJPA
> generates a separate SQL query for each CLOB row after it has loaded the
> rest of the data for that object. We see this behaviour even when we are
> only querying for a single field of the object (not even the CLOB field).
> This is having a big impact on performance for us as it involves a lot more
> roundtrips to the DB.
>
> FYI we are running OpenJPA 1.2.1
>
>
>
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/CLOB-loading-query-per-row-tp7260505p7260505.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.

Re: may be OpenJPA limitation

[Jeremy Bauer]

Based on the SQLCODE, it looks like the table USER in schema DBSCHEMA
does not exist.  Is that table located in a different schema than the
default?  If so, you have a few options - specify the schema on the
@Table annotation, use the openjpa.jdbc.Schema property, or depending
on the driver and platform, specify a different default schema on the
connection URL[2].  Or, if possible, define the table in DBSSCHEMA.

[1] 
http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_schema_def.html
[2] 
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.apdv.java.doc/doc/cjvcfgpr.htm

-Jeremy

On Tue, Jun 7, 2011 at 6:45 PM, Pinaki Poddar  wrote:
> Right now I do not have a computing environment to give you a definite
> answer. But if you do not mind, please try passing a Long (not long).
>
> Why did you think that the application connects to multiple DBs could be
> relevant in this context?
> Given rather straightforward nature of the use case, I am thinking whether
> something else is causing the reported failure.
>
> -
> Pinaki
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/may-be-OpenJPA-limitation-tp6450246p6451867.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: The name "A" is not a recognized entity or identifier. Perhaps you meant ....

[Jeremy Bauer]

Another thing to verify is whether you have ProfileAuditDetail listed
as a  in your persistence.xml.  I've forgotten that simple
detail or mistyped a package or class name a time or ten.

-Jeremy

On Tue, Jun 7, 2011 at 10:34 AM, infinity2heaven
 wrote:
> openjpa build time enhancement
> http://openjpa.208410.n2.nabble.com/openjpa-build-time-enhance-using-maven-plugin-DOESN-T-WORK-td6446547.html#a6450082
> does'nt work as specified  and I'm aware that RuntimeEnhancement
> http://openjpa.208410.n2.nabble.com/Externalizer-in-1-0-1-does-not-work-on-persist-td216632.html#a6436083
> doesn't work all the time  either. But right now, we need to get a build for
> our deployment environment so I've temporarily enabled Runtime enhancement.
> It seems to work most of the time.
>
> Here's the complete stacktrace.
>
> 
> org.apache.openjpa.persistence.ArgumentException: An error occurred while
> parsing the query filter "DELETE FROM ProfileAuditDetail". Error message:
> The name "ProfileAuditDetail" is not a recognized entity or identifier.
> Perhaps you meant ProfileAudit, which is a close match. Known entity names:
> [xxx, yyy, ProfileAudit, ErrorCode, ProfileLoadError]
>        at
> org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:118)
>        at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:177)
>        at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:150)
>        at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:225)
>        at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:195)
>        at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:188)
>        at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$600(JPQLExpressionBuilder.java:69)
>        at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:1756)
>        at 
> org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:56)
>        at
> org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:153)
>        at 
> org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:658)
>        at
> org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:639)
>        at
> org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:605)
>        at
> org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:667)
>        at 
> org.apache.openjpa.kernel.QueryImpl.getOperation(QueryImpl.java:1492)
>        at
> org.apache.openjpa.kernel.DelegatingQuery.getOperation(DelegatingQuery.java:123)
>        at
> org.apache.openjpa.persistence.QueryImpl.executeUpdate(QueryImpl.java:325)
>        at xxx.tcms.profile.dao.JPAProfileDao.deleteAll(JPAProfileDao.java:204)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39)
>        at java.lang.reflect.Method.invoke(Method.java:612)
>        at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>        at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>        at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>        at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)
>        at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>        at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
>        at $Proxy19.deleteAll(Unknown Source)
>        at
> xxx.profile.service.ProfileServiceImpl.deleteProfileData(ProfileServiceImpl.java:429)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:59)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:39)
>        at java.lang.reflect.Method.invoke(Method.java:612)
>        at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
>        at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>        at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>        at
> org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)

Re: JEE 5: Bean Validation API and JPA 2.0

[Jeremy Bauer]

Hi Chintan,

The WebSphere Version 8 Beta documentation in the IBM infocenter has a
good writeup on migration considerations for bean validation[1] when
moving to a full EE6 app server.  The short answer is that you'll no
longer need to set a system property to point to the validation API
and you'll no longer have to include a bean validation provider in
your application or shared library.  The application server will
provide both the API classes and a default provider.  The easiest way
to verify your application continues to work the full EE 6 environment
may be to download the V8 beta[2] and give it a try.

-Jeremy

[1] 
http://publib.boulder.ibm.com/infocenter/wasinfo/beta/topic/com.ibm.websphere.nd.doc/info/ae/ae/cdat_beanvaljpamigration.html

[2] 
https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/wsasoa/index.shtml

On Wed, May 25, 2011 at 3:53 PM, chintan4181  wrote:
> Thanks Kevin, Jeremy.
>
> One more question. If i use OSGi/JPA 2.0 feature pack with Apache Bean
> Validation in Websphere  7.0 and in future if i migrate to JEE 6, are there
> any migration issue in terms of Bean Validation usage?
>
> Chintan
>
>
>
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/JEE-5-Bean-Validation-API-and-JPA-2-0-tp6403780p6404442.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: JEE 5: Bean Validation API and JPA 2.0

[Jeremy Bauer]

Chintan,

While Bean Validation is one of the Java EE 6 specifications, each
provider will have its own Java SE version requirements.  For example,
Apache BVAL[1] can be used with Java SE 1.5.  Some/most Java EE 5
application servers will most likely allow you to use a "Java 1.5
compatible" Bean Validation provider using JSE-style APIs.  You'll
lack EE6 features like JNDI lookup of validation factories and
integration with other technologies such as JPA, JSF, and JCA.

An exception is that the WebSphere Version 7.0 Feature Pack for
OSGi/JPA 2.0 provides a mechanism to support bean validation
integration with JPA 2.0 in an EE 5 + JPA 2.0 environment.  If you are
interested, I wrote up a blog post several months ago that provides a
step-by-step procedure to do the enablement.[2]  It is a bit out of
date as far as versions go, though.  You'll want to use the new 0.3
version of BVAL instead 0.1.

-Jeremy

[1] http://incubator.apache.org/bval/cwiki/index.html
[2]http://webspherepersistence.blogspot.com/2010/07/using-bean-validation-with-osgijpa-20.html

On Wed, May 25, 2011 at 12:53 PM, chintan4181  wrote:
> Hi,
>
> We are running on JEE 5 stack and using JPA 2.0 for persistence layer. In
> our application architecture, we have following layers Service, BC(Business
> Component) and DAC(Data Access component). As per secure coding guideliens,
> each layer should be responsible of doing validation. considering that
> approach, Our business rule validation will be done in BC layer. and Data
> type, constraint will be done in DAC layer.
>
> For data validation at DAC layer, i can think of Bean Validation API (JSR
> 303) however it's part of JEE 6. can i use in JEE 5 ?
>
> Thanks
> Chintan
>
> --
> View this message in context: 
> http://openjpa.208410.n2.nabble.com/JEE-5-Bean-Validation-API-and-JPA-2-0-tp6403780p6403780.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Issues with GeneratedValue and SequenceGenerator

[Jeremy Bauer]

I agree.  The OpenJPA documentation is confusing/contradictory.

1.2.  Final

Entity classes may not be final. No method of an entity class can be final.

*Note*

OpenJPA supports final classes and final methods.

I wonder if the distinction is "Entity" vs. a plain old class?  Either
way, I think the note should be removed from the documentation.

-Jeremy

On Mon, Apr 11, 2011 at 2:35 PM, Rick Curtis  wrote:
> 1.2.  Final
>
> Entity classes may not be final. No method of an entity class can be final.
> Note
>
> OpenJPA supports final classes and final methods.
> Confusing? Perhaps. It seems pretty clear that we don't support final
> Entities or final Entity methods. I'm not sure what the "Note" is referring
> to though.
>
> If you want, open a JIRA and I can remove that Note. It's more confusing
> than anything.
>
> Thanks,
> Rick
>
> On Mon, Apr 11, 2011 at 2:23 PM, realdepp  wrote:
>
>> I'm not sure about that - the final modifier seems to be the cause for the
>> problem.
>>
>> The JPA spec sais:
>> "Entity classes may not be final. No method of an entity class can be
>> final."
>>
>> BUT the OpenJPA docs say:
>> "OpenJPA supports final classes and final methods."
>>
>> http://openjpa.apache.org/builds/2.1.0/apache-openjpa-2.1.0/docs/manual/jpa_overview_pc.html#jpa_overview_pc_final
>>
>> So this is either an implementation bug or a documentation bug
>

Re: @PersistenceContext is null

[Jeremy Bauer]

Hi Chintan,

Which application server are you using?  Regardless of the server type, I'd
start by checking the server logs.  They may show some sort of injection
failure due to a data source or some other configuration problem.

-Jeremy

On Thu, Apr 7, 2011 at 6:42 PM, chintan4181  wrote:

> Hi,
>
> I am trying to access JPA entities using Stateless EJBs, Earlier i have one
> Stateless EJB which was injecting PersistenceContext using annotation. It
> is
> working fine. Since Stateless EJB is haveing data access code, I have
> introduced DAO mechanism to separate data access from EJB. For that I have
> added below classes
>
> GenericeDAO:
> public interface GenericDAO {
>
>void persist(E entity);
>void remove(E entity);
>E findById(K id);
>
> }
>
> ApplicationDAO: defined DAO as Stateless EJB
> @Stateless
> public class ApplicationDAO implements
> GenericDAO {
>
>protected Class entityClass;
>
>@PersistenceContext(name = "MIApplicationJPA", unitName =
> "MIApplicationJPA")
>public EntityManager entityManager;
>
>@SuppressWarnings("unchecked")
>public ApplicationDAO() {
>ParameterizedType genericSuperclass = (ParameterizedType)
> getClass().getGenericSuperclass();
>this.entityClass = (Class)
> genericSuperclass.getActualTypeArguments()[1];
>}
>
>public void persist(E entity) {
>entityManager.persist(entity);
>}
>
>public void remove(E entity){
>entityManager.remove(entity);
>}
>
>public E findById(K id) {
>E entity;
>entity = (E) entityManager.find(entityClass, id);
>return entity;
>}
>
> }
>
> CertDAOImpl:
> public class CertDAOImpl extends ApplicationDAO{
>
>@Override
>public Certificate findByCertNumber(String certId) throws Exception
> {
>
>Certificate cert = (Certificate)
> entityManager.createNamedQuery("findByCert_Number")
>
>   .setParameter("Cert_Number",certId)
>
>   .getSingleResult();
>return cert;
>}
> }
>
> However when i access entityManager from CertDAOImpl. entitymanage is
> coming
> as null. Even though it is in same EJB jar. can anybody tell me what could
> be the issue?
>
> Thanks
> Chintan
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/PersistenceContext-is-null-tp6251959p6251959.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Issues with GeneratedValue and SequenceGenerator

[Jeremy Bauer]

IIRC, the identity value should be getting returned by the JDBC driver as a
result of the insert.  OpenJPA then populates the entity with that value.
What version of MySQL DB and JDBC driver are you using?

-Jeremy

On Wed, Apr 6, 2011 at 10:16 AM, realdepp  wrote:

> Thanks, but that didn't solve the problem.
>
> EntityManager.refresh() has no effect, like expected.
>
> I'm not enhancing with an eclipse tool, I'm calling the java program via
> ant:
>
>
>
>
>
>
>
>
>
>
> (I also tried the ant task, doesn't seem to make a difference)
>
> However, I get a bunch of warning messages: (I thought ignoring would be ok
> since I get no errors like "class not enhanced")
> openjpa.MetaData - Meta class "x.y.z.TimeSettings_" for entity class
> x.y.z.TimeSettings can not be registered with following exception
> "java.security.PrivilegedActionException: java.lang.ClassNotFoundException:
> x.y.z.TimeSettings_"
>
> I haven't checked yet if the warning message appears for every class, but
> most of them produce it.
>
>
> But I have to correct myself: initialValue AND allocationSize are ignored.
> The IDs start with 1 and they get increased by 50 (default value?) with
> every new persisted entity.
> (And, of course, I don't see any way to get the ids into the application)
>
>
> Is that probably related to MySQL?
>
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Issues-with-GeneratedValue-and-SequenceGenerator-tp6244055p6246413.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Non JPA Annotations?

[Jeremy Bauer]

Hi Jay,

Using a RUNTIME retention policy should do the trick.  What type of
enhancement are you using?  If you use build time enhancement,  have you
tried to decompile your enhanced entity classes?  I just ran a quick test
with OpenJPA trunk and my custom annotations show up in the decompiler
output of the enhanced entity class files.  Bean Validation
(javax.validation.constraints.*) constraints also survive the enhancement
process and are available at runtime using RUNTIME retention.  Otherwise,
the openjpa-integration/validation suite of tests would fail.

Could you provide a simple test that demonstrates the annotations being
lost?  I may be using a different style of enhancement or have some other
environmental configuration difference.

-Jeremy

On Tue, Mar 15, 2011 at 1:41 PM, Jay Herrick  wrote:

> Hello,
>
> I'm trying to add some custom annotations to my entity objects that I'll
> use
> at runtime for display purposes.  I've done this before in other code and
> I've defined my custom annotation with the
> @Retention(RetentionPolicy.RUNTIME) annotation (It always tickles me that
> we
> use annotations to build annotations :) )
>
> It looks like my annotations are removed when OpenJPA enhances the entity
> classes.  Is that really what's happening here?  Is there any way I can ask
> OpenJPA to leave my annotations intact?
>
> Thanks for any help you can offer,
>
> -Jay
>

Re: OpenJPA Date Proxy serialization problem when using entities with GWT

[Jeremy Bauer]

Prashant,

According to the OpenJPA migration considerations documentation[1] section
1.1.5, clear()/close() will remove proxies automatically upon serialization
if you have a version 2.0 persistence.xml.  If you are using a version 1.0
persistence.xml setting this property should result in proxy removal:

  

hth,
-Jeremy

[1]
http://openjpa.apache.org/builds/latest/docs/manual/migration_considerations.html

On Wed, Mar 9, 2011 at 9:13 PM, Prashant Bhat  wrote:

> Hi All,
>
> We're developing an application using OpenJpa 2.1, Spring-3.0.5 and
> GWT-2.2.0. This integration works for all other types in the entity, but
> fails for fields of type Date with the following exception:
> --
> com.google.gwt.user.client.rpc.SerializationException: Type
> 'org.apache.openjpa.util.java$util$Date$proxy' was not included in the set
> of types which can be serialized by this SerializationPolicy or its Class
> object could not be loaded. For security purposes, this type will not be
> serialized.: instance = Sat Dec 31 00:00:00 SGT 2011
> --
> I tried using DTO instead of using an entity directly, but when date
> property is copied from Entity object to DTO, the same proxy will be set.
> So
> it doesn't work either.
>
> When searched, I found lot of references to detaching the entity to remove
> all proxies needed by Jpa. It works, but this needs to be explicitly
> called,
> while the same works without calling this, in our Swing app which gets the
> serialized objects through Spring Remoting. And also, as there're a lot of
> DAOs already written, this is going to be major change.
>
> So, is there a openjpa configuration setting to use, so that all proxies
> are
> removed on em.close() ? I really appreciate any help to solve this.
>
> Thanks,
> Prashant
>

Re: OneToMany cascading persist and sequence ID generator

[Jeremy Bauer]

No problem.  I'm happy to hear that you are up and running.

-Jeremy

On Wed, Mar 2, 2011 at 11:26 PM, Phill  wrote:

> Many thanks Jeremy, to my embarrassment I've discovered that lead wasn't
> getting set properly on the other end of the association. I jumped to the
> wrong conclusion about the id generation not working... sorry for taking up
> your time with this.
>
> On 02/mar/2011, at 21.42, Jeremy Bauer wrote:
>
> > Hi Phill,
> >
> > I tried a similar configuration, but was unable to reproduce the failure.
> > Since cascade is defined on the Lead-side of the relationship, I'm
> assuming
> > that you are persisting the Lead entity, right?  I'm also assuming that
> > you've set all bi-directional references in your code.  ie
> > answer.setLead(lead), lead.setAnswers(answers).  If both of those
> > assumptions are correct, the next step would be to provide an OpenJPA
> trace
> > using:
> >
> > 
> >
> > please enable parameter value trace as well using:
> >
> >  > value="PrintParameters=true"/>
> >
> > That may help us spot the problem.  Or, if possible, please provide a
> simple
> > test that can be used to reproduce the problem.
> >
> > -Jeremy
> >
> > On Wed, Mar 2, 2011 at 11:08 AM, Phill  wrote:
> >
> >> Yes it also uses a sequence generator.
> >>
> >> SurveyAnswer.java
> >>
> >> @SequenceGenerator(name = "Survey_Result_Id_Gen", sequenceName =
> >> "survey_result_seq", allocationSize = 10)
> >>
> >> @Id
> >> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator =
> >> "Survey_Result_Id_Gen")
> >> @Column(name = "result_id")
> >> protected long id;
> >>
> >>
> >> On 02/mar/2011, at 17.24, Jeremy Bauer wrote:
> >>
> >>> Thanks, Phill.  Sorry, I forgot to ask - does SurveyAnswer also use the
> >> same
> >>> id generation strategy as Lead?  In the meantime, I'll begin trying to
> >>> reproduce the failure you are seeing.
> >>>
> >>> -Jeremy
> >>>
> >>> On Wed, Mar 2, 2011 at 9:26 AM, Phill  wrote:
> >>>
> >>>> OpenJPA 2.1.0 and PostgreSQL 9
> >>>> I have separate DDL.
> >>>> Phill
> >>>>
> >>>>
> >>>> On 02/mar/2011, at 16.22, Jeremy Bauer wrote:
> >>>>
> >>>>> Hi Phill,
> >>>>>
> >>>>> What database and version of OpenJPA are you using?  Also, does
> OpenJPA
> >>>>> generate the tables or do you have separate DDL?
> >>>>>
> >>>>> -Jeremy
> >>
>
>

Re: OneToMany cascading persist and sequence ID generator

[Jeremy Bauer]

Hi Phill,

I tried a similar configuration, but was unable to reproduce the failure.
Since cascade is defined on the Lead-side of the relationship, I'm assuming
that you are persisting the Lead entity, right?  I'm also assuming that
you've set all bi-directional references in your code.  ie
answer.setLead(lead), lead.setAnswers(answers).  If both of those
assumptions are correct, the next step would be to provide an OpenJPA trace
using:



please enable parameter value trace as well using:



That may help us spot the problem.  Or, if possible, please provide a simple
test that can be used to reproduce the problem.

-Jeremy

On Wed, Mar 2, 2011 at 11:08 AM, Phill  wrote:

> Yes it also uses a sequence generator.
>
> SurveyAnswer.java
>
> @SequenceGenerator(name = "Survey_Result_Id_Gen", sequenceName =
> "survey_result_seq", allocationSize = 10)
>
> @Id
> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator =
> "Survey_Result_Id_Gen")
> @Column(name = "result_id")
> protected long id;
>
>
> On 02/mar/2011, at 17.24, Jeremy Bauer wrote:
>
> > Thanks, Phill.  Sorry, I forgot to ask - does SurveyAnswer also use the
> same
> > id generation strategy as Lead?  In the meantime, I'll begin trying to
> > reproduce the failure you are seeing.
> >
> > -Jeremy
> >
> > On Wed, Mar 2, 2011 at 9:26 AM, Phill  wrote:
> >
> >> OpenJPA 2.1.0 and PostgreSQL 9
> >> I have separate DDL.
> >> Phill
> >>
> >>
> >> On 02/mar/2011, at 16.22, Jeremy Bauer wrote:
> >>
> >>> Hi Phill,
> >>>
> >>> What database and version of OpenJPA are you using?  Also, does OpenJPA
> >>> generate the tables or do you have separate DDL?
> >>>
> >>> -Jeremy
>

Re: same jpa query generates different SQLs

[Jeremy Bauer]

Marc,

I'm glad that worked for you.  You could actually just exclude that query
for the time being, that way you still get caching benefits for your other
statements.  To exclude the query you can either set the query hint via
query.setHint("openjpa.hint.IgnorePreparedQuery", true)  on the query or
exclude it via persistence property:



You can get more specifics on cache exclusion in this section of the OpenJPA
manual[1].

That should get you by for the time being, but please open a JIRA for this
problem so that it gets fixed.

[1]
http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_cache_querysql.html

-Jeremy

On Wed, Mar 2, 2011 at 10:51 AM, Marc Logemann  wrote:

> Hi Jeremy,
>
> thanks for your instant feedback. I directly tried your suggestion and now
> it works. So there is a bug in the cache implementation with regard to Type
> Mappings.
> And its not a DB2 thingy because i am using MySQL ;-)
>
> if you need more infos in the error case, i am willing to help if you
> want I would like to see this solved because disabling the cache means
> decreasing the performance somehow right?
>
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
>
>
>
>
> Am 02.03.2011 um 17:31 schrieb Jeremy Bauer:
>
> > Hi Marc,
> >
> > I'm wondering if this isn't caused by an inconsistent parameter type
> mapping
> > as a result of using the QuerySQLCache. I saw a similar issue a few weeks
> > ago, but it was oddly specific to DB2 on zOS. Please try:
> >
> > 
> >
> > -Jeremy
> >
> > On Wed, Mar 2, 2011 at 9:43 AM, Marc Logemann  wrote:
> >
> >> Hi,
> >>
> >> i am totally astonished:
> >>
> >> I am using this query:
> >>
> >>   public List findByDate(Date date) {
> >>
> >>   TypedQuery query = getEntityManager().
> >>   createQuery("select o FROM Order o where o.createdYmd = ?1
> >> order by o.id", Order.class);
> >>
> >>   query.setParameter(1, date, TemporalType.DATE);
> >>   return query.getResultList();
> >>   }
> >>
> >> This query is called by a service class which is scheduled ever 30
> seconds.
> >> See the caller:
> >>
> >>   // get yesterdays Date
> >>   Date today = new Date();
> >>   Calendar calendar = Calendar.getInstance();
> >>   calendar.setTime(today);
> >>   calendar.add(Calendar.DATE, -1);
> >>   Date yesterday = calendar.getTime();
> >>
> >>   List list = orderDao.findByDate(yesterday);
> >>
> >>
> >> Now, on the second run, the query parameter is of type timestamp with
> full
> >> time specified, giving me 0 records of course. First query returns
> records
> >> because there TemporalType seems to work. See log.
> >>
> >> FIRST RUN ->
> >>
> >> [DEBUG myScheduler-3 16:36:30] |  executing
> >> prepstmnt 1488869003 SELECT t0.oid, t0.`_version`, t1.oid,
> t1.`_version`,
> >> t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
> >> t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
> >> t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype,
> >> t2.printed, t2.printedby, t2.totalprice, t1.boxtype, t0.created,
> >> t0.createdymd, t0.custnr, t3.oid, t3.jpatype, t3.`_version`,
> t3.addresstype,
> >> t3.city, t3.company, t3.country, t3.department, t3.email, t3.firstname,
> >> t3.gender, t3.lastname, t3.middlename, t3.phone, t3.zip,
> t3.postofficebox,
> >> t3.street, t3.housenr, t3.title, t3.deliverymode, t0.greenoption,
> >> t0.ordernr, t4.oid, t4.jpatype, t4.`_version`, t4.addresstype, t4.city,
> >> t4.company, t4.country, t4.department, t4.email, t4.firstname,
> t4.gender,
> >> t4.lastname, t4.middlename, t4.phone, t4.zip, t4.postofficebox,
> t4.street,
> >> t4.housenr, t4.title, t4.deliverymode, t4.order_oid, t0.iscardowner,
> >> t0.cost, t0.currency, t0.pricing, t0.paymenttype, t0.printed,
> t0.printedby,
> >> t0.totalprice FROM orders t0 LEFT OUTER JOIN boxes t1 ON t0.box_oid =
> t1.oid
> >> LEFT OUTER JOIN address t3 ON t0.oid = t3.order_oid LEFT OUTER JOIN
> address
> >> t4 ON t0.invaddress_oid = t4.oid LEFT OUTER JOIN orders t2 ON t1.oid =
> >> t2.box_oid WHERE (t0.createdymd = ?) AND (t3.jpatype IS NULL OR
> t3.jpatype
> >> IN (?)) ORDER BY t0.ordernr ASC [params=(Date) 2011-03-01, (int) 2]
> >>
> >> SECOND RUN ->
> >>
> >

Re: same jpa query generates different SQLs

[Jeremy Bauer]

Hi Marc,

I'm wondering if this isn't caused by an inconsistent parameter type mapping
as a result of using the QuerySQLCache. I saw a similar issue a few weeks
ago, but it was oddly specific to DB2 on zOS. Please try:



-Jeremy

On Wed, Mar 2, 2011 at 9:43 AM, Marc Logemann  wrote:

> Hi,
>
> i am totally astonished:
>
> I am using this query:
>
>public List findByDate(Date date) {
>
>TypedQuery query = getEntityManager().
>createQuery("select o FROM Order o where o.createdYmd = ?1
> order by o.id", Order.class);
>
>query.setParameter(1, date, TemporalType.DATE);
>return query.getResultList();
>}
>
> This query is called by a service class which is scheduled ever 30 seconds.
> See the caller:
>
>// get yesterdays Date
>Date today = new Date();
>Calendar calendar = Calendar.getInstance();
>calendar.setTime(today);
>calendar.add(Calendar.DATE, -1);
>Date yesterday = calendar.getTime();
>
>List list = orderDao.findByDate(yesterday);
>
>
> Now, on the second run, the query parameter is of type timestamp with full
> time specified, giving me 0 records of course. First query returns records
> because there TemporalType seems to work. See log.
>
> FIRST RUN ->
>
> [DEBUG myScheduler-3 16:36:30] |  executing
> prepstmnt 1488869003 SELECT t0.oid, t0.`_version`, t1.oid, t1.`_version`,
> t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
> t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
> t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype,
> t2.printed, t2.printedby, t2.totalprice, t1.boxtype, t0.created,
> t0.createdymd, t0.custnr, t3.oid, t3.jpatype, t3.`_version`, t3.addresstype,
> t3.city, t3.company, t3.country, t3.department, t3.email, t3.firstname,
> t3.gender, t3.lastname, t3.middlename, t3.phone, t3.zip, t3.postofficebox,
> t3.street, t3.housenr, t3.title, t3.deliverymode, t0.greenoption,
> t0.ordernr, t4.oid, t4.jpatype, t4.`_version`, t4.addresstype, t4.city,
> t4.company, t4.country, t4.department, t4.email, t4.firstname, t4.gender,
> t4.lastname, t4.middlename, t4.phone, t4.zip, t4.postofficebox, t4.street,
> t4.housenr, t4.title, t4.deliverymode, t4.order_oid, t0.iscardowner,
> t0.cost, t0.currency, t0.pricing, t0.paymenttype, t0.printed, t0.printedby,
> t0.totalprice FROM orders t0 LEFT OUTER JOIN boxes t1 ON t0.box_oid = t1.oid
> LEFT OUTER JOIN address t3 ON t0.oid = t3.order_oid LEFT OUTER JOIN address
> t4 ON t0.invaddress_oid = t4.oid LEFT OUTER JOIN orders t2 ON t1.oid =
> t2.box_oid WHERE (t0.createdymd = ?) AND (t3.jpatype IS NULL OR t3.jpatype
> IN (?)) ORDER BY t0.ordernr ASC [params=(Date) 2011-03-01, (int) 2]
>
> SECOND RUN ->
>
> [DEBUG myScheduler-2 16:37:00] |  executing
> prepstmnt 154018541 SELECT t0.oid, t0.`_version`, t1.oid, t1.`_version`,
> t1.cleared, t1.id, t1.lastused, t2.oid, t2.`_version`, t2.created,
> t2.createdymd, t2.custnr, t2.greenoption, t2.ordernr, t2.invaddress_oid,
> t2.iscardowner, t2.cost, t2.currency, t2.pricing, t2.paymenttype,
> t2.printed, t2.printedby, t2.totalprice, t1.boxtype, t0.created,
> t0.createdymd, t0.custnr, t3.oid, t3.jpatype, t3.`_version`, t3.addresstype,
> t3.city, t3.company, t3.country, t3.department, t3.email, t3.firstname,
> t3.gender, t3.lastname, t3.middlename, t3.phone, t3.zip, t3.postofficebox,
> t3.street, t3.housenr, t3.title, t3.deliverymode, t0.greenoption,
> t0.ordernr, t4.oid, t4.jpatype, t4.`_version`, t4.addresstype, t4.city,
> t4.company, t4.country, t4.department, t4.email, t4.firstname, t4.gender,
> t4.lastname, t4.middlename, t4.phone, t4.zip, t4.postofficebox, t4.street,
> t4.housenr, t4.title, t4.deliverymode, t4.order_oid, t0.iscardowner,
> t0.cost, t0.currency, t0.pricing, t0.paymenttype, t0.printed, t0.printedby,
> t0.totalprice FROM orders t0 LEFT OUTER JOIN boxes t1 ON t0.box_oid = t1.oid
> LEFT OUTER JOIN address t3 ON t0.oid = t3.order_oid LEFT OUTER JOIN address
> t4 ON t0.invaddress_oid = t4.oid LEFT OUTER JOIN orders t2 ON t1.oid =
> t2.box_oid WHERE (t0.createdymd = ?) AND (t3.jpatype IS NULL OR t3.jpatype
> IN (?)) ORDER BY t0.ordernr ASC [params=(Timestamp) 2011-03-01 16:37:00.001,
> (int) 2]
>
> I have completely no clue what to do now ;-) Thanks for input.
>
>
>
> ---
> regards
> Marc Logemann
> http://www.logemann.org
> http://www.logentis.de
>
>
>
>
>

Re: OneToMany cascading persist and sequence ID generator

[Jeremy Bauer]

Thanks, Phill.  Sorry, I forgot to ask - does SurveyAnswer also use the same
id generation strategy as Lead?  In the meantime, I'll begin trying to
reproduce the failure you are seeing.

-Jeremy

On Wed, Mar 2, 2011 at 9:26 AM, Phill  wrote:

> OpenJPA 2.1.0 and PostgreSQL 9
> I have separate DDL.
> Phill
>
>
> On 02/mar/2011, at 16.22, Jeremy Bauer wrote:
>
> > Hi Phill,
> >
> > What database and version of OpenJPA are you using?  Also, does OpenJPA
> > generate the tables or do you have separate DDL?
> >
> > -Jeremy
> >
> > On Wed, Mar 2, 2011 at 8:49 AM, Phill  wrote:
> >
> >> I'm having some problems with a cascading @OneToMany persist, my class
> with
> >> the @ManyToOne has a sequence id generator and this Id is not getting
> >> populated in the cascaded entity.
> >>
> >> Here are the relevant snippets:
> >>
> >> Lead.java
> >> --
> >> @SequenceGenerator(name = "Lead_Id_Gen", sequenceName = "lead_id_seq")
> >>
> >> @Id
> >> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator =
> >> "Lead_Id_Gen")
> >> @Column(name = "lead_id")
> >> private Long id;
> >>
> >> @OneToMany(mappedBy = "lead", cascade = CascadeType.ALL)
> >> private List answers = new ArrayList();
> >>
> >> SurveyAnswer.java
> >> --
> >> @ManyToOne
> >> @JoinColumn(name = "lead_id")
> >> protected Lead lead;
> >>
> >>
> >> org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: null value in
> >> column "lead_id" violates not-null constraint {prepstmnt 26568269
> >> INSERT INTO survey_result (result_id, result_boolean, result_number,
> >>   result_int, result_text, answer_type, lead_id, survey_id,
> >>   question_id, single_choice)
> >>
> >>
> >> Should this not happen automatically or am I missing something?
> >>
> >> Thanks
> >> Phill
>
>

Re: OneToMany cascading persist and sequence ID generator

[Jeremy Bauer]

Hi Phill,

What database and version of OpenJPA are you using?  Also, does OpenJPA
generate the tables or do you have separate DDL?

-Jeremy

On Wed, Mar 2, 2011 at 8:49 AM, Phill  wrote:

> I'm having some problems with a cascading @OneToMany persist, my class with
> the @ManyToOne has a sequence id generator and this Id is not getting
> populated in the cascaded entity.
>
> Here are the relevant snippets:
>
> Lead.java
> --
> @SequenceGenerator(name = "Lead_Id_Gen", sequenceName = "lead_id_seq")
>
> @Id
> @GeneratedValue(strategy = GenerationType.SEQUENCE, generator =
> "Lead_Id_Gen")
> @Column(name = "lead_id")
> private Long id;
>
> @OneToMany(mappedBy = "lead", cascade = CascadeType.ALL)
> private List answers = new ArrayList();
>
> SurveyAnswer.java
> --
> @ManyToOne
> @JoinColumn(name = "lead_id")
> protected Lead lead;
>
>
> org.apache.openjpa.lib.jdbc.ReportingSQLException: ERROR: null value in
> column "lead_id" violates not-null constraint {prepstmnt 26568269
> INSERT INTO survey_result (result_id, result_boolean, result_number,
>result_int, result_text, answer_type, lead_id, survey_id,
>question_id, single_choice)
>
>
> Should this not happen automatically or am I missing something?
>
> Thanks
> Phill

Re: correct use of GenerationType.TABLE

[Jeremy Bauer]

Hi Henno,

Whether the table generator will be a performance bottleneck will depend on
your application.  If it is insert/persist heavy and/or has many clients
simultaneously persisting new entities, the table generator could become a
bottleneck. As you mentioned, increasing the allocation size will reduce
trips to the database and contention on the table.  Using a separate table
via a custom table generator can help remove contention on any single
table.  A custom table generator also provides the ability to reuse a single
table by using a different PK value for each generated id.  (ie.  each
generator has its own table row)  That can provide better performance and
help reduce the number of DB tables you need to manage.

Also, if you'd like to continue using the system/default table generator you
can change the default allocation size by setting this persistence property:

  

>> We have existing data that is migrated to the database schema generated
by OpenJPA. Am I correct that after migration I >> should initialize the
SEQUENCE_VALUE to the maximum over all entity id's?

Yes.  Initializing SEQUENCE_VALUE to a value larger than your current
maximum entity ID should do the trick.

hth,
-Jeremy

On Wed, Feb 23, 2011 at 3:37 AM, Henno Vermeulen wrote:

> Hello,
>
> All of our entities inherit from "AbstractEntity" which is a
> MappedSuperclass that defines an automatically generated identity column of
> type Long. Because of issues we are having with GenerationType.IDENTITY (
> https://issues.apache.org/jira/browse/OPENJPA-1949) I would like to switch
> to GenerationType.TABLE.
>
> When I annotate the id column in our mapped super class as
>
>@Id
>@GeneratedValue(strategy = GenerationType.TABLE)
>private Long id;
>
> OpenJPA creates a sequence table with only one row (with ID 0). This means
> that all our entities will share this sequence to generate new id's. This is
> not a problem for our application, but I was wondering if there are any
> performance issues with this. Would this be solved by defining my own
> tablegenerator with an allocationSize of something like 1000?
>
> We have existing data that is migrated to the database schema generated by
> OpenJPA. Am I correct that after migration I should initialize the
> SEQUENCE_VALUE to the maximum over all entity id's?
>
> (I guess it can also be solved by pulling up the id column so that all our
> entities have to define it's own id and use the same generator table. This
> gives a lot of unnecessary code duplication while our design choice that all
> of our entities have a synthetic id works perfectly fine for us. We use this
> in many places with our notification, caching and application level lock
> system.)
>
> Henno
>
>

Re: How to get generated keys without requerying the database?

[Jeremy Bauer]

You are welcome.  I'm glad there was a simple workaround.  Thanks for filing
a JIRA.  It has plenty of detail, which is great.  Keep an eye on the JIRA
for fix availability.

-Jeremy

On Tue, Jan 25, 2011 at 5:28 PM, robsinner  wrote:

>
> Jeremy (and Kevin),
>
> Thank you so much for your quick turnaround time and response and the
> workaround.
>
> I modified the persistence.xml with
>
> I also created a bug in JIRA- My first one so I hope that it was detailed
> enough.
> https://issues.apache.org/jira/browse/OPENJPA-1930
>
> Thanks again, it is much appreciated.
>
> R
> S
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/How-to-get-generated-keys-without-requerying-the-database-tp5957346p5960986.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: How to get generated keys without requerying the database?

[Jeremy Bauer]

Thanks for the DB and JCC info.  I remembered there being some issue with
getGeneratedKeys on a JCC driver level, but that was quite a while ago.
Your driver and DB level are current, so I quickly set aside that
possibility.

Using a trimmed down version of your code, I found that there is a bug in
OpenJPA's batching update constraint manager (the piece of code that drives
batched updates through the JDBC driver).  The batching manager currently
does not retrieve non-key identity fields on an insert/update operation.
Until a fix is available, you can get around the problem by adding this
property to your persistence.xml:

  

This property enables the non-batching constraint update manager, which has
the proper code to retrieve the generated field.

Please file a JIRA for this issue[1] and we'll work on providing a fix.  Or
let me know and I'd be happy to file one for you.

-Jeremy

[1] http://issues.apache.org/jira/browse/OPENJPA

On Tue, Jan 25, 2011 at 2:55 PM, robsinner  wrote:

>
> DB2 (from Control Center Help About)
> Product Identifier SQL09072
> Level Identifier 08030107
> Level DB2 v9.7.200.358
> Build Level s100514
> PTF IP23084
>
> JCC Driver is db2jcc4-9.7.100.177.jar, db2jcc_license_cu-9.7.100.177.jar
>
> Thank you for your help,
>
> R
> S
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/How-to-get-generated-keys-without-requerying-the-database-tp5957346p5960445.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: How to get generated keys without requerying the database?

[Jeremy Bauer]

Rob,

Thanks for the additional info and trace.  I'll try to reproduce this
locally.  What level of DB2 and JCC driver are you using?  I scanned the
trace, but neither jumped out at me.

-Jeremy

On Tue, Jan 25, 2011 at 12:36 PM, robsinner  wrote:

>
> Kevin,
>
> Thanks for your response.
>
> I am including the full log from my junit test with TRACE turned on via
> openjpa.Log in persistence.xml
> 
>
> I am using the DB2Dictionary in my persistence.xml
>
>  value="org.apache.openjpa.jdbc.sql.DB2Dictionary"/>
>
> I have a junit test which prints out these two variables from the
> DB2Dictionary.
>
>public void testShowDb2Dictionary()
>{
>DB2Dictionary dictionary = new
> org.apache.openjpa.jdbc.sql.DB2Dictionary();
>
> log.info
> ("dictionary.lastGeneratedKeyQuery="+dictionary.lastGeneratedKeyQuery);
> //this shows VALUES(IDENTITY_VAL_LOCAL())
>
> log.info
> ("dictionary.supportsGetGeneratedKeys="+dictionary.supportsGetGeneratedKeys);
> //this shows null
>}
>
> This prints out
> 2011-01-25 10:27:06,266 INFO  [] com.ais.persistence.InpartmasterTest:103 -
> dictionary.lastGeneratedKeyQuery=VALUES(IDENTITY_VAL_LOCAL())
> 2011-01-25 10:27:06,266 INFO  [] com.ais.persistence.InpartmasterTest:104 -
> dictionary.supportsGetGeneratedKeys=null
>
> I would think the DB2Dictionary.supportsGetGeneratedKeys ==null is part of
> the problem. But I dont know how to resolve.
>
> I know I am able to use stmt.getGeneratedKeys with the same db2 jdbc driver
> class (p:driverClass="com.ibm.db2.jcc.DB2Driver")
> with a straight JDBC Dao Framework
>
> Thank you for your help.
>
> Full Log Below
> 
> 2011-01-25 10:26:55,861 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:81 - FirestormUtil static init
> loading spring
> 2011-01-25 10:26:55,876 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:122 - applicationContext.xml
> exists=true
> 2011-01-25 10:26:55,878 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:126 -
>
> URL=file:/C:/RAD/aircore-JPA-J2-SNAPSHOT/target/classes/applicationContext.xml
> 2011-01-25 10:26:55,879 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:135 - running with
> applicationContext.xml
> 2011-01-25 10:26:55,880 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:122 - applicationContext2.xml
> exists=true
> 2011-01-25 10:26:55,881 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:126 -
>
> URL=file:/C:/RAD/aircore-JPA-J2-SNAPSHOT/target/classes/applicationContext2.xml
> 2011-01-25 10:26:55,882 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:135 - running with
> applicationContext2.xml
> 2011-01-25 10:26:55,883 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:122 - applicationContext3.xml
> exists=false
> 2011-01-25 10:26:55,884 ERROR []
> com.cms.shared.ext.firestorm.FirestormUtil:130 - class path resource
> [applicationContext3.xml] cannot be resolved to URL because it does not
> exist
> 2011-01-25 10:26:55,886 ERROR []
> com.cms.shared.ext.firestorm.FirestormUtil:139 - running without
> applicationContext3.xml
> 2011-01-25 10:26:55,912 INFO  []
> com.cms.shared.ext.firestorm.FirestormUtil:101 - building Spring
> ClassPathXmlApplicationContext from these files[applicationContext.xml
> applicationContext2.xml]
> 2011-01-25 10:26:55,957 INFO  []
> org.springframework.context.support.ClassPathXmlApplicationContext:456 -
> Refreshing
> org.springframework.context.support.ClassPathXmlApplicationContext@4998a455
> :
> startup date [Tue Jan 25 10:26:55 PST 2011]; root of context hierarchy
> 2011-01-25 10:26:56,013 INFO  []
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader:315 - Loading
> XML bean definitions from class path resource [applicationContext.xml]
> 2011-01-25 10:26:56,417 INFO  []
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader:315 - Loading
> XML bean definitions from class path resource [jpapersistence.xml]
> 2011-01-25 10:26:56,669 INFO  []
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader:315 - Loading
> XML bean definitions from class path resource [stdcore.xml]
> 2011-01-25 10:26:59,331 INFO  []
> org.springframework.beans.factory.xml.XmlBeanDefinitionReader:315 - Loading
> XML bean definitions from class path resource [applicationContext2.xml]
> 2011-01-25 10:26:59,384 INFO  []
> org.springframework.beans.factory.support.DefaultListableBeanFactory:618 -
> Overriding bean definition for bean 'fiscalYrDao': replacing [Generic bean:
> class [com.cms.shared.gen.firestorm.jdbc.FiscalYrDaoImpl]; scope=;
> abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0;
> autowireCandidate=true; primary=false; factoryBeanName=null;
> factoryMethodName=null; initMethodName=null; destroyMethodName=null;
> defined
> in class path resource [stdcore.xml]] with [Generic bean: class
> [com.cms.shared.gen.firestorm.jdbc.FiscalYrDaoImpl]; scope=;
> abstract=false;
> lazyInit=false; autowireMode=0; dependencyCheck=0; autowireCandidate=true;
> primary=false; factoryBea

Re: How to get generated keys without requerying the database?

[Jeremy Bauer]

Hi,

Based on the code snippets you've provided, it looks like you my just either
need to call em.flush() to force the DB update or commit the transaction
before getting the recId from the dto.  If that doesn't help, repost and
I'll dig a little deeper.  OpenJPA refreshes primary key identity fields
after a flush or commit.  I think it will/should do the same for non-PK
generated fields.

hth,
-Jeremy

On Mon, Jan 24, 2011 at 8:33 PM, robsinner  wrote:

>
> I have an Entity with a non primary key identity column.
>
> This entity
> Part.java
> has the following fields among others
>
>@EmbeddedId
>private PartPK pk;
>
>
>@GeneratedValue(strategy=GenerationType.IDENTITY)
>@Column(name="REC_ID")
>private Integer recId;
>
> Note the EmbeddedId does not contain the  Generated Value , the PartPk is
> made up of two strings, one for company and one for part number.
>
> So the Entity has a primary key which is  a business composite key. This
> table also has a column in DB2 which is a IDENTITY column which is not part
> of the primary key. This identity column which is not part of the primary
> key is called REC_ID.
>
> After insert I would like the recId to be populated onto the entity however
> it is not. In JDBC this is usually accomplished via
> statement.getGeneratedKeys after the insert statements has been run.
>
> For example in a straight JDBC Data Access Object this would be
> accomplished
> after the insert statement by
>// retrieve values from auto-increment columns
>rs = stmt.getGeneratedKeys();
>if (rs != null && rs.next()) {
>dto.setRecId( new Integer( rs.getInt(1) ) );
>}
>
> However when I run a junit test using a simple JPA data access object the
> recId column is null after insert.
>
>public void testInsert()
>{
>log.info("insert");
>log.info("part="+part);
>
>manager = getManager();
>
>pk.setIncomp(comp);
>pk.setInpart(part);
>
>dto.setPk(pk);
>
>log.info(dto);
>manager.insert(dto);
>
>log.info("recId="+dto.getRecId());
>assertFalse("recId is null after insert should not
> be", dto.getRecId() ==
> null); //fails here
>  }
>
>
> The manager class is wrapping this data access object code
>
>public PK insert(DTO dto) throws Exception {
>EntityManager em = getEntityManager();
>em.persist(dto);
>return dto.getPk();
>}
>
> How do I specify the mapping in the entity with a non primary key identity
> column such that after an insert the non primary key identity column is
> populated onto the entity.
>
> Among other things I am using Db2 with spring and openjpa 2.2.0.
>
> I believe this has something to do with getGeneratedKeys and how I'm doing
> the mapping in the entity and possibly DB2 with openjpa.
>
> The table are legacy and are not easily modifiable to accomplish this. Im
> trying to avoid having to relook up the non primary key with a seperate
> query by the primary key after the insert.
>
> Thank you in advance for your assistance. I searched in the nabble users
> list and could not find anything related. If you need more detailed
> information I can post more. I believe this is a simple configuration done
> incorrectly at the entity level.
>
> Thank you in advance for any assistance you provide.
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/How-to-get-generated-keys-without-requerying-the-database-tp5957346p5957346.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: [ANNOUNCE] Welcome Heath Thomann as a new committer

[Jeremy Bauer]

Congrats, Heath!  Welcome!

-Jeremy

On Wed, Jan 5, 2011 at 2:14 PM, Michael Dick wrote:

> The OpenJPA PMC recently extended committership to Heath Thomann and he
> accepted.
>
> Welcome aboard Heath!
>
> -mike
>

Re: JPAB results

[Jeremy Bauer]

Hi Ilan,

Thanks for your post, additional details about JPAB, and your willingness to
try different OpenJPA configurations.  While the performance gap is
concerning, myself and others are especially concerned with the functional
problems you are seeing.  I downloaded the benchmark jar and was able to
reproduce the errors you've documented.  Running the multi-threaded tests
with OpenJPA 2.0.0 on a multi-core system consistently produced duplicate
key exceptions.  I found that this issue is fixed in our 2.0.2-SNAPSHOT and
also in 2.1.0-SNAPSHOT/trunk.  However, the 2.0.2 snapshot runs into another
threading issue, which is caused by OpenJPA's QuerySQLCache.  By disabling
the cache with the property below, I was able to get a clean run with
2.0.2-SNAPSHOT.  Current trunk level code has some fixes in this area and
worked without it.

property-3=

I am doing a bit of experimentation with the benchmark in the areas of
connection pooling, data caching, and statement batching.  While OpenJPA has
many performance tuning switches and dials, these three typically have the
most impact.  Some of the other providers have these performance features
enabled by default, so enabling them in OpenJPA helps level the field.

If you have time and wouldn't mind giving OpenJPA another go, you can get
the latest 2.1.0-SNAPSHOT from here:
https://repository.apache.org/snapshots/org/apache/openjpa/apache-openjpa/2.1.0-SNAPSHOT/

as of this note the latest snapshot is
https://repository.apache.org/snapshots/org/apache/openjpa/apache-openjpa/2.1.0-SNAPSHOT/apache-openjpa-2.1.0-20101104.065025-93-binary.zip

This snapshot has connection pooling included and enabled by default.  If
you'd like, you can enable basic, un-tuned, statement batching and data
caching with these properties.

property-3=
property-4=

I and I'm sure others others would be interested in the result.  If I come
up with a better set of basic tuning parameters, I'll pass them along.
Others, please feel free to do the same.

-Jeremy

On Wed, Nov 3, 2010 at 11:24 AM, Ilan Kirsh  wrote:

>
> Hi all,
>
> I am the author of the  http://www.jpab.org JPAB benchmark .
>
> As Rick wrote - this is indeed an out of the box benchmark. Default
> configuration was used for all the tested products.
>
> I read with interest what you said about connection pooling. I am keen to
> try this but I wonder whether it will really make a difference because the
> tests do not use short term database connections, and anyway, the time of
> connecting to the database is excluded from the time measurement.
>
> But probably there are other things that can be done to improve
> performance.
> I'd like to run the tests again with optimized OpenJPA configuration but
> for
> this I will need some help from OpenJPA experts.
>
> Regarding test failures - I have used standard JPA for the tests. I am
> obviously keen to fix up any problems which are my errors, though, so I'd
> be
> very happy for details I have got incorrect to be pointed out and fixed.
>
> However, please notice that the same tests that failed with OpenJPA passes
> with other combinations such as Hibernate/MySQL. Therefore, this could
> really be a problem with the OpenJPA processing, as Kevin wrote. I think
> that these tests indicate at least some issues that might have to be fixed
> in OpenJPA.
>
> Finally, I'd like to address any concerns that the tests are specifically
> designed to make  http://www.objectdb.com ObjectDB  look best. The tests
> are
> very simple and include only standard JPA operations on simple object
> models. It is open source - does anyone see anything that is biased towards
> ObjectDB performance?  Actually, the performance gap could be even larger
> if
> the object model would be more complex. It is true, however, as explained
> on
> http://www.jpab.org/Benchmark_FAQ.html, that when the bottleneck is disk
> activity or network overhead - performance gaps are expected to be much
> lower.
>
> Best regards,
> Ilan Kirsh
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/JPAB-results-tp5693298p5702044.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: [ANNOUNCE] Welcome Jody Grassel as a new committer

[Jeremy Bauer]

Congratulations, Jody!  Welcome aboard!!

-Jeremy

On Thu, Nov 4, 2010 at 12:58 PM, Rick Curtis  wrote:

> Congrats Jody!
>
> Thanks,
> Rick
>
> On Thu, Nov 4, 2010 at 12:47 PM, Donald Woods  wrote:
>
> > The OpenJPA PMC recently extended committership to Jody and he accepted.
> >
> > Jody, I've added you to the openjpa-developers group in JIRA.
> > Once you have a Confluence ID, we can add you there too.
> >
> > Welcome aboard!
> >
> > -Donald
> >
>

Re: Default schema question (yes, I know about the Schema property)

[Jeremy Bauer]

Laird & Kevin,

This bug has been around a while.  It is filed under JIRA OPENJPA-400[1].
The typical workaround is to use the openjpa.jdbc.Schema property.  It looks
like OpenJPA *may* also pick up the value if you define your entities in the
orm.xml -- but my memory is cloudy regarding that workaround.  Regardless,
this is something that needs to be fixed.

-Jeremy

[1] https://issues.apache.org/jira/browse/OPENJPA-400

On Tue, Nov 2, 2010 at 5:17 PM, Kevin Sutter  wrote:

> Hi Laird,
> I agree with you.  You should be able to specify a default schema and/or
> catalog via the persistence-unit-defaults element of the orm.xml file.  I
> just looked through our junits, and I don't see any tests for this
> particular configuration...  I do see other defaults being tested, just not
> the schema or the catalog.
>
> And, although I can see Patrick's viewpoint in your referenced append on
> the
> use of multiple orm.xml files, the JPA spec also documents it's position on
> this situation (section 8.2.1.6.2):
>
> *If multiple mapping files are specified (possibly including one or more
> orm.xml files), the resulting mappings are obtained by combining the
> mappings from all of the files.
> The result is undefined if multiple mapping files (including any orm.xml
> file) referenced within a single
> persistence unit contain overlapping mapping information for any given
> class.
> *
>
> Basically, you could still shoot yourself in the foot if you're not
> careful.  But, it is legal to use multiple orm.xml files and we should be
> combining the results to the best of our ability.
>
> My take is that we should be honoring the default schema and catalog
> settings, and if we're not, open a JIRA to get this resolved.
>
> Thanks,
> Kevin
>
> On Tue, Nov 2, 2010 at 2:27 PM, Laird Nelson  wrote:
>
> > I have a test suite that runs my JPA entities across all the major JPA
> > providers.
> >
> > None of my entities has a schema name in it; I want to keep it that way.
> >
> > None of my entities are configured in any way other than annotations.
> >
> > I understand from the JPA specification that if I put in a
> >  element in my META-INF/orm.xml file, I can
> > indicate a default catalog and a default schema to use.
> >
> > When I do this, indeed my EclipseLink and Hibernate tests pass.
> >
> > My OpenJPA tests fail.
> >
> > I then read this:
> >
> >
> http://openjpa.208410.n2.nabble.com/best-way-to-set-default-schema-across-all-entities-td215796.html
> >
> > I believe this is a misinterpretation of the specification.  Is there any
> > way to get OpenJPA to honor the persistence-unit-defaults element in the
> > orm.xml file and to apply it to entities that are not listed therein?
> >
> > I am using OpenJPA 2.0.0-beta3 (not 2.0.1, since that has a
> > NullPointerException regression in named queries which I previously
> > documented).
> >
> > Best,
> > Laird
> >
>

Re: JPAB results

[Jeremy Bauer]

It looks like benchmark is configured to use openjpa-all-2.0.0 so it
wouldn't be using auto-enablement of DBCP.  The auto-enablement wasn't
available until recently in openjpa-all-2.1.0-SNAPSHOT.  I scanned some of
the benchmark config files and they are using direct-to-DB jdbc URL's, so
nor does it look like pooling is explicitly enabled.  Like so many other
JSE-based benchmarks, I think we'd see more favorable OpenJPA results with
connection pooling.

-Jeremy

On Tue, Nov 2, 2010 at 9:15 AM, Rick Curtis  wrote:

> I also took a quick look and it appears that this is another out of the box
> test. Caching would probably bridge the gap between us and Hibernate...
> also
> I'm not sure they are running with the auto connection pooling stuff Donald
> has been working on.
>
> Thanks,
> Rick
>
> On Tue, Nov 2, 2010 at 8:49 AM, Kevin Sutter  wrote:
>
> > Although this "benchmark" is obviously biased, it's still good to be
> > reminded of potential pitfalls and/or inconsistencies.  For example, I
> took
> > a quick look at one set of results and it seems to indicate a repeating
> > issue with obtaining a primary key sequence from the OpenJPA sequence
> > table.  This could be a problem with the application, or it could be a
> > problem with the OpenJPA processing.  Digging in a bit on these type of
> > issues would probably be worthwhile.
> >
> > But, spending a lot of time attempting to match the results of ObjectDB
> is
> > probably not that interesting...
> >
> > Kevin
> >
> > On Tue, Nov 2, 2010 at 7:58 AM, Georgi Naplatanov 
> wrote:
> >
> > > Hi gkorland.
> > >
> > > Do not trust on this tests. It is better to make your own test and then
> > > decide  which implementation is good for you.
> > >
> > > My testing indicates that OpenJPA (with or without cache) is faster
> than
> > > Hibernate on mostly write and less read operations.
> > >
> > > On read operation probably all JPA implementation are very close due
> the
> > >  cache.
> > >
> > > Best regards
> > > Georgi
> > >
> > >
> > > gkorland wrote:
> > >
> > >> Did anyone review the JPAB (http://www.jpab.org/) results? It seems
> > like
> > >> all the other JPA guys are running faster and even better...
> > >>
> > >
> > >
> >
>

Re: Problems with trunk build

[Jeremy Bauer]

Hi Georgi,

A few of us were having some build issues this morning due to a dependency
update.  The change was backed out and trunk is now building again.  The
error you've posted doesn't look the same, but I'm doing an install vs.
package.  I'd try doing a clean before package with the very latest code.
You may have better luck.

-Jeremy

On Mon, Nov 1, 2010 at 12:47 PM, Georgi Naplatanov  wrote:

> Hi all.
>
> I have the following problems when i try to build OpenJPA from trunk:
>
> 1. After "mvn compile" execution the following error occurs :
>
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] An Ant BuildException has occured: The following error occurred
> while executing this line:
> /home/gosho/eclipse_workplaces/openjpa/trunk/openjpa-examples/openbooks/build.xml:116:
> *** Error:
>   The directory for OpenJPA libraries can not be located at
> /home/gosho/.m2/repository/org/apache/openjpa/openjpa-all/2.1.0-SNAPSHOT.
>   Make sure openjpa.lib property value is correct in
> build.properties file.
>
> 2. After "mvn package -DskipTests" execution - the same error as above
>
> 3. If i change HSQLDictionary.java file for example, the compiled file is
> in "trunk/openjpa-jdbc/target/classes/org/apache/openjpa/jdbc/sql" directory
> which is correct, but in the
> "trunk/openjpa-project/target/site/downloads/apache-openjpa-2.1.0-SNAPSHOT-binary.zip"
> is unmodified file.
>
> What is wrong ?
>
> Best regards
> Georgi
>

Re: Migrate EntityBean NamedSequenceTable to OpenJPA

[Jeremy Bauer]

C,

JPA provides similar, but not exact capabilities through table generators.
The main difference in JPA is that a table generator can be used to generate
IDs for multiple entities from a single table while the approach you've
provided appears to be capable of only managing a single ID per table.

JPA table generators are able to manage multiple id's by having a sequence
name and sequence value column in the table.  A TableGenerator keys off the
value defined by "pkColumnValue" (default is "DEFAULT" if not specified) in
column "pkColumnName" to generate a new block of keys.

Here is a example of defining a TableGenerator and using within
GeneratedValue for an entity.

@Entity
@Table(name="Entity_TBL")
@TableGenerator(name="WebCartSequence",
schema="dbo",
table="WebCartSequence",
pkColumnName="Sequence_Name",
valueColumnName="Sequence",
pkColumnValue="MyEntityID")
public class MyEntity {

@Id
@GeneratedValue(strategy=GenerationType.TABLE,
generator="WebCartSequence")
private int id;
...
}

Again, this will not work with the same table definition as you currently
use.  Based on the names in the example, you could add a column named
"Sequence_Name" to your existing table and set its value to "MyEntityID" and
that may do the trick.

-Jeremy


On Wed, Oct 13, 2010 at 12:41 PM, corstad  wrote:

>
> Greetings:
>
>  I am attempting to migrate Entity Beans to OpenJPA. Each Entity Bean
> represents a single table in the DB. The Entity Beans are deployed on
> WebLogic 10.0 using WLS 8 version of the deployment descriptors. (I just
> work here).
>
>  Each table has a corresponding sequence table with a single column named
> Sequence. The current DD for these use the following XML within the
> weblogic-cmp-jar.xml file for each weblogic-rdbms-bean defined.
>
>   
>  NAMED_SEQUENCE_TABLE
>  WebCartSequence
>  1
>   
>
> The SQL used to create the sequence table is:
>
> CREATE TABLE [dbo].[WebCartSequence](
>[Sequence] [int] NOT NULL
> ) ON [PRIMARY]
>
>
> My question is what would the OpenJPA annotations look like to use this id
> generation strategy?
>
> Thanks,
>
> C.
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Migrate-EntityBean-NamedSequenceTable-to-OpenJPA-tp5631958p5631958.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Re: @Externalizer not working during maven test phase

[Jeremy Bauer]

Heiko,

Thanks for following up so quickly.  I put together a quick test and wasn't
able to produce the same result.  I was just about to type up an email
asking for more info.  I'm glad to hear you were able to work around the
issue with a simple change.

I agree that having the exception surfaced from OpenJPA, if possible, would
be more helpful.  If you can supply a simple test to show the problem we
could certainly look into propagating the exception.  Filing a JIRA[1] would
be the best route.  That way, you can attach the test directly to the JIRA
and keep and eye out for a fix.

-Jeremy

[1] https://issues.apache.org/jira/browse/OPENJPA

On Wed, Sep 29, 2010 at 1:09 AM,  wrote:

> Hello Jeremy,
>
> thank you for your investigations. I might have come up with a reason for
> this problem. I tried to simply load the class TypeMapping during the
> maven integration test exactly before the openJPA test begun. It did not
> load, but an ExceptionInInitializer was thrown. Though openJPA was in its
> final decision right as the class was 'bad' cause it was not loadable.
>
> However, the really interesting thing is why in the maven test phase the
> static initializer failed and thus the class did not load. Within the
> static initializer we load an xml-file via
>
> Thread.currentThread().getContextClassLoader().getResourceAsStream(
> "/TypeMapping.xml")
>
> As this seems to work well inside the application server, it does not work
> when maven's integration phase is running. The xml file is not found.
> Without the leading slash it works for both, the application server AND
> maven's integration phase.
>
> To summarize:
>
> 1) openJPA does not cause this the problem
> 2) the actual cause WHY the class is bad for meta data is hidden and leads
> to difficult-to-find problems. If the stack trace contained the
> ExceptionInInitializer-Exception, this mail would have never been written
> ;-)
> 3) Maybe providing the causing exception in future versions of openJPA
> (although I'm stuck at openJPA 1.0.4 right now) would be an improvement.
>
> Best regards, and thank you again for your short reply.
>
> Heiko
>
> techhu...@gmail.com schrieb am 28.09.2010 16:14:10:
>
> > Hi Heiko,
> >
> > Odd problem, indeed.  I'll setup a similar environment and let you know
> if I
> > have any suggestions.  Which version of maven are you using and which
> OS?
> >
> > -Jeremy
> >
> > On Tue, Sep 28, 2010 at 5:10 AM, Heiko Kopp
> wrote:
> >
> > >
> > > Hello,
> > >
> > > I've encountered a problem when using openJPA inside mavens
> integration
> > > test
> > > phase. Alot of my entities respectively their members have been
> annotated
> > > with @Factory and @Externalizer to automatically convert database
> datatypes
> > > into schema relevent enumerations. An example for this is:
> > >
> > > @Entity
> > > @Table(name = "PARTNER", schema = "PART")
> > > public class Partner
> > > {
> > >
> > >
> > >@Column(name = "I_SCHL_WERTBEZ")
> > >@Externalizer(TypeMapping.MARSHAL_SALUTATION_INDIVIDUAL)
> > >@Factory(TypeMapping.UNMARSHAL_SALUTATION_INDIVIDUAL)
> > >private SalutationIndividualEnum salutationIndividual;
> > >
> > >...
> > > }
> > >
> > > The Externalizer- and Factory-Methods have been extracted into a
> separate
> > > class called 'TypeMapping'. In this class we additionally have the
> > > following
> > > string constants as used above:
> > >
> > > public static final String MARSHAL_SALUTATION_INDIVIDUAL
> > >   =
> > >
> > > "com.mbbank.partner.pas.common.system.typemapping.TypeMapping.
> > marshalSalutationIndividual";
> > >
> > > public static final String UNMARSHAL_SALUTATION_INDIVIDUAL
> > >   =
> > >
> > > "com.mbbank.partner.pas.common.system.typemapping.TypeMapping.
> > unmarshalSalutationIndividual";
> > >
> > > These strings referr to the actuall methods.
> > >
> > > The TypeMapping-class is located in a different package than the
> entity
> > > class. And this seems to be a problem during test test phase in maven.
> > > While
> > > the code works perfectly in the application server, it fails in the
> maven
> > > test phase with the following exception:
> > >
> > > 
> > > org.apache.openjpa.persistence.ArgumentException: Der Klassenname
> > > "com.mbbank.partner.pas.common.system.typemapping.TypeMapping", der in
> der
> > > Metadatenerweiterung im Feld
> > >
> > > "com.mbbank.partner.pas.common.system.database.model.Person.
> > salutationIndividual"
> > > verwendet wird, ist nicht gültig.
> > > at org.apache.openjpa.meta.JavaTypes.classForName(JavaTypes.java:227)
> > >at
> > > org.apache.openjpa.meta.JavaTypes.classForName(JavaTypes.java:194)
> > >at
> > > org.apache.openjpa.meta.JavaTypes.classForName(JavaTypes.java:185)
> > >at
> > >
> org.apache.openjpa.meta.FieldMetaData.findMethod(FieldMetaData.java:1533)
> > >at
> > >
> > > org.apache.openjpa.meta.FieldMetaData.
> > getExternalizerMethod(FieldMetaData.java:1465)
> > >at
> > > org.apache.openjpa.meta.

Re: @Externalizer not working during maven test phase

[Jeremy Bauer]

Hi Heiko,

Odd problem, indeed.  I'll setup a similar environment and let you know if I
have any suggestions.  Which version of maven are you using and which OS?

-Jeremy

On Tue, Sep 28, 2010 at 5:10 AM, Heiko Kopp wrote:

>
> Hello,
>
> I've encountered a problem when using openJPA inside mavens integration
> test
> phase. Alot of my entities respectively their members have been annotated
> with @Factory and @Externalizer to automatically convert database datatypes
> into schema relevent enumerations. An example for this is:
>
> @Entity
> @Table(name = "PARTNER", schema = "PART")
> public class Partner
> {
>
>
>@Column(name = "I_SCHL_WERTBEZ")
>@Externalizer(TypeMapping.MARSHAL_SALUTATION_INDIVIDUAL)
>@Factory(TypeMapping.UNMARSHAL_SALUTATION_INDIVIDUAL)
>private SalutationIndividualEnum salutationIndividual;
>
>...
> }
>
> The Externalizer- and Factory-Methods have been extracted into a separate
> class called 'TypeMapping'. In this class we additionally have the
> following
> string constants as used above:
>
> public static final String MARSHAL_SALUTATION_INDIVIDUAL
>   =
>
> "com.mbbank.partner.pas.common.system.typemapping.TypeMapping.marshalSalutationIndividual";
>
> public static final String UNMARSHAL_SALUTATION_INDIVIDUAL
>   =
>
> "com.mbbank.partner.pas.common.system.typemapping.TypeMapping.unmarshalSalutationIndividual";
>
> These strings referr to the actuall methods.
>
> The TypeMapping-class is located in a different package than the entity
> class. And this seems to be a problem during test test phase in maven.
> While
> the code works perfectly in the application server, it fails in the maven
> test phase with the following exception:
>
> 
> org.apache.openjpa.persistence.ArgumentException: Der Klassenname
> "com.mbbank.partner.pas.common.system.typemapping.TypeMapping", der in der
> Metadatenerweiterung im Feld
>
> "com.mbbank.partner.pas.common.system.database.model.Person.salutationIndividual"
> verwendet wird, ist nicht gültig.
> at org.apache.openjpa.meta.JavaTypes.classForName(JavaTypes.java:227)
>at
> org.apache.openjpa.meta.JavaTypes.classForName(JavaTypes.java:194)
>at
> org.apache.openjpa.meta.JavaTypes.classForName(JavaTypes.java:185)
>at
> org.apache.openjpa.meta.FieldMetaData.findMethod(FieldMetaData.java:1533)
>at
>
> org.apache.openjpa.meta.FieldMetaData.getExternalizerMethod(FieldMetaData.java:1465)
>at
> org.apache.openjpa.meta.FieldMetaData.resolve(FieldMetaData.java:1640)
>at
> org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:400)
>at
> org.apache.openjpa.meta.ClassMetaData.resolveMeta(ClassMetaData.java:1688)
>at
> org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1623)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataRepository.java:675)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.resolveMeta(MetaDataRepository.java:574)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:499)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:301)
>at
> org.apache.openjpa.kernel.BrokerImpl.newObjectId(BrokerImpl.java:1060)
>at
>
> org.apache.openjpa.kernel.DelegatingBroker.newObjectId(DelegatingBroker.java:252)
>at
>
> org.apache.openjpa.persistence.EntityManagerImpl.find(EntityManagerImpl.java:347)
>
> The string is localized into German, the original one is referred to as
> 'bad-class'. It's English representation is:
>
> bad-class: The class name "{0}" used in a metadata extension on field "{1}"
> is not valid.
>
> As both class files are present in the same module and even during the test
> phase, I've actually no clue on how to fix this issue. It can be fixed,
> when
> I put the static methods in the same package/class as the annotated field,
> but that is no solutation for us as it will duplicate a lot of code.
>
> Has anyone an idea why this appends and what can be done to prevent it?
>
> Thank you very much.
>
> As seen in the stack trace above, I'm using openJPA 1.0.4-,
> which
> is part of the Websphere Application Server 6.1.0.29.
>
> Best regards,
>
> Heiko
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Externalizer-not-working-during-maven-test-phase-tp5578748p5578748.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: DataCache on Class with a collection of DataCache off -> n+1 select

[Jeremy Bauer]

Hi Marc,

If you are using OpenJPA 1.x, specifying
@org.apache.openjpa.persistence.DataCache(enabled=false) annotation on your
inventory entities will inform OpenJPA that these entities should not be
cached.  If you are using OpenJPA 2.x, you have a few more options.  You can
continue to use the OpenJPA specific @DataCache annotation or use the JPA
2.0 standard @javax.persistence.Cacheable(false) annotation to prevent
inventory entities from being cached.  At an operation level, you can
specify the property "javax.persistence.cache.storeMode" with value of
javax.persistence.CacheStoreMode BYPASS on the finder or query to indicate
not to cache the result.

In addition, you could consider using LAZY fetch to not return the inventory
relation.  If that is too stringent, OpenJPA provides configurable fetch
groups[1] which let your further tune what should/should not be returned in
the query result.

hth,
Jeremy

[1] http://openjpa.apache.org/builds/latest/manual/ref_guide_fetch.html

On Mon, Sep 20, 2010 at 11:00 AM, killbulle  wrote:

>
> Hi ,
> we encounters a recently a little performance problem
> A class product(cached)  have a map off inventory (not Cached)
> when we retrieve the product in a new Entitymanager it generate a n+1
> select
> with a find all
> method.
> Is there a way to not cache the collection stub (1 - inventory...) ?
> Regards
> Marc
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/DataCache-on-Class-with-a-collection-of-DataCache-off-n-1-select-tp5551060p5551060.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Need id to set in VO .

[Jeremy Bauer]

Hi Himadri,

One option is to add a PostPersist lifecycle method to your entity class.
The id is guaranteed to be available during this callback.  During the
lifecycle method you can set the id on your value object.  The simplest (but
not pretty) way to do that might be to store a transient reference to the
value object within the entity.  Note: make sure to return that same ref
from your EJB method.  PostPersist will fire after commit, modifying the id
of the value object en route.

For example:

@Entity
public class MyEntity {

transient public MyValue _value;

...

@PostPersist
public void postPersist() {
_value.id = getId();
}
}

hth,

-Jeremy

On Mon, Aug 30, 2010 at 11:44 PM, Himadri  wrote:

>
> Hi,
>
> Am using EJB3.0 Entity on WL 10.3 . The application is designed in
> ValueObject model i.e Entities are not directly passed to client but
> converted into value objects and then sent to client. I cannot change this
> design now.
> Value object also has primary key (id) column . My requirement is to create
> an entity and send VO back with id of newly created entity set.
>
> Now I understand , id is not generated untill the entity is inserted into
> database.. At the end of method when i convert Entity to VO , I donot get
> the primay key as the transaction is not committed yet.
> So to overcome this problem , I have user em.flush() ... and then I could
> get the key..  I understand its a bad practice to use flush .. but can
> anyone suggest how else can I get the system generated primary key at the
> end of method and set it back in VO ?
>
> Thanks
> Himadri
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Need-id-to-set-in-VO-tp5481138p5481138.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: [VOTE] Apache OpenJPA 2.0.1 release candidate

[Jeremy Bauer]

+1 Thanks, Donald!

-Jeremy

On Thu, Aug 26, 2010 at 10:55 AM, Donald Woods  wrote:

> I've staged a release candidate for OpenJPA 2.0.1 with the following
> artifacts up for a vote:
>
> SVN source tag (r989424) made from the 2.0.x branch:
> https://svn.apache.org/repos/asf/openjpa/tags/2.0.1/
>
> Source release:
>
> https://repository.apache.org/content/repositories/orgapacheopenjpa-147/org/apache/openjpa/apache-openjpa/2.0.1/apache-openjpa-2.0.1-source.zip
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapacheopenjpa-147/
>
> Staging site for Downloads, Javadoc and User Guide:
> http://people.apache.org/~dwoods/openjpa/2.0.1/staging-site/
>
> PGP release keys (signed using D018E6B1):
> https://svn.apache.org/repos/asf/openjpa/KEYS
>
> For changes in this release, please visit the release notes:
>
> https://svn.apache.org/repos/asf/openjpa/tags/2.0.1/openjpa-project/CHANGES.txt
>
>
> Vote will be open for 72 hours.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
>
> Thanks,
> Donald
>
>

Re: Integrating existing customized Datasource and Connection objects in JPA

[Jeremy Bauer]

Hyndavi,

Have you considered registering your own Datasource in JNDI during
initialization (before OpenJPA needs it)?  Provided your data source fully
implements javax.jdbc.DataSource and hands out fully implemented and/or
wrapped connections, theoretically OpenJPA should look up the data source by
name and use it to create connections.  If you are in an app server
environment there may be some restrictions on whether you can register your
own objects in JNDI.  I haven't tried this so I have no idea whether it'll
work, but It might be worth a try.

-Jeremy

On Tue, Aug 17, 2010 at 2:31 AM, hyndavi  wrote:

>
> Hi Mike,
>
> Thank you very much for your response.
>
> Yes. I have existing customized API that helps us to create Datasource and
> Connection objects based on Database availablility. This also maintains
> connection pools, checks Database availablility and etc.
>
> We are planning to use JPA going forward. With that we would like to
> integrate this customized API.
>
> -Hyndavi.
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Integrating-existing-customized-Datasource-and-Connection-objects-in-JPA-tp5411498p5430996.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Glassfishv3 + OpenJPA-2.0.0: Enhancer not working

[Jeremy Bauer]

Sounds like you are getting closer.  I scaled back to only including the
openjpa-2.0.0.jar and serp in my app.  Injection (into a servlet) and
integrated/container enhancement continued to work.  So, it doesn't look
like an incompatibility with any of the Glassfish provided common or API
libs.  Hopefully, the Glassfish folks will be able to figure out what is up
with injection.  If you can share your app, I'd be happy to give it a go in
my environment.

-Jeremy

On Tue, Jul 20, 2010 at 7:29 AM, Stefan Schilling  wrote:

> Jeremy,
>
> I just finished testing.
>
> I used the following setup:
> - manual enhancement via maven: disabled
> - manual MetaDataFactory setup: disabled
> - using Injection: enabled
>
>
> This one brings the Enhancer to life, I dont need to manually enhance a
> class or anything. BUT: The @PersistenceUnit dependency does *NOT* get shot
> into the class; the variable stays null.
>
> When I remove the @PersistenceUnit entries, the enhancer stops working as
> well.
>
> I used:
>
> @PersistenceUnit(unitName="myApplicationPersistenceUnit")
> private EntityManagerFactory emfTmp;
> private EntityManagerFactory emf =
> Persistence.createEntityManagerFactory("myApplicationPersistenceUnit");
>
> persistence.xml:
>
>   xmlns="http://java.sun.com/xml/ns/persistence";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>  http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
>  
>
>  org.apache.openjpa.persistence.PersistenceProviderImpl
>jdbc/MyDataSource
>
>  
>  
>  
>  
>  
>
>  
> 
>
> emf is usable, emfTmp stays null; but the Enhancer is working.
>
> I'll report this one back to the Glassfish forum as well.
>
> Thanks.
>
> Stefan
>
> PS: yes, I know, OpenJPA delivers those 3 geronimo libraries as well, but
> these should be available as I'm using an app server. The commons-* and serp
> libraries are added to Glassfish's lib directory along w/ OpenJPA-2.0.0.jar.
>
>
>  Original-Nachricht 
> > Datum: Mon, 19 Jul 2010 16:26:55 -0500
> > Von: Jeremy Bauer 
> > An: users@openjpa.apache.org
> > Betreff: Re: Glassfishv3 + OpenJPA-2.0.0: Enhancer not working
>
> > Stefan,
> >
> > Are you using an injected entity manager or entity manager factory:
> >
> > @PersistenceUnit
> > private EntityManagerFactory emf;
> >
> > or going the application managed route:
> >
> > emf =
> > Persistence.createEntityManagerFactory("myApplicationPersistenceUnit");
> >
> > ?
> >
> > In my simple test, I found that OpenJPA 2.0.0 OpenJPA 2.0.0 worked well
> > with
> > GlassFish v3 (74.2)  when injecting an emf.  The classes did not need to
> > be
> > listed in the persistence.xml and OpenJPA's class transformer hooked into
> > the container - so I did not need to pre-enhance the entities.  However,
> > this did not happen when I went the app managed route - which is like
> > running in JSE mode (which requires classes to be listed).  I had to
> > perform
> > enhancement by other means and my entities needed to be listed in the
> > persistence.xml.
> >
> > Injection into a servlet or EJB looks to be the best way to go, if
> > possible.
> >
> > -Jeremy
> >
> > On Mon, Jul 19, 2010 at 8:04 AM, Stefan Schilling 
> > wrote:
> >
> > > Hello,
> > >
> > > I have a Glassfishv3 running here and *need* to use OpenJPA-2.0.0.
> > >
> > > I'm currently having two different setups in our persistence.xml;
> here's
> > > the working one:
> > >
> > > http://java.sun.com/xml/ns/persistence";
> > >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > >xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
> > >http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> > > version="1.0">
> > >
> > > > > transaction-type="RESOURCE_LOCAL">
> > >
> > >
> >
> org.apache.openjpa.persistence.PersistenceProviderImpl
> > >jdbc/MyDataSource
> > >
> > > > > value="DefaultLevel=WARN, Runtime=INFO, Tool=INFO, SQL=TRACE"/>
> > >
> > >   

Re: Glassfishv3 + OpenJPA-2.0.0: Enhancer not working

[Jeremy Bauer]

Stefan,

I took another look at your stack and it looks like you are using an app
managed persistence unit.  It may simplify things for you if you can switch
to using injection to get an instance of the emf.

BTW, I have these libs bundled with my app:

commons-collections-3.2.1.jar
commons-lang-2.1.jar
commons-pool-1.5.3.jar
geronimo-jpa_2.0_spec-1.0.jar  (not sure if this lib is required, but
NetBeans complained if it wasn't there)
openjpa-2.0.0.jar
serp-1.13.1.jar

-Jeremy

On Mon, Jul 19, 2010 at 4:26 PM, Jeremy Bauer  wrote:

> Stefan,
>
> Are you using an injected entity manager or entity manager factory:
>
> @PersistenceUnit
> private EntityManagerFactory emf;
>
> or going the application managed route:
>
> emf =
> Persistence.createEntityManagerFactory("myApplicationPersistenceUnit");
>
> ?
>
> In my simple test, I found that OpenJPA 2.0.0 OpenJPA 2.0.0 worked well
> with GlassFish v3 (74.2)  when injecting an emf.  The classes did not need
> to be listed in the persistence.xml and OpenJPA's class transformer hooked
> into the container - so I did not need to pre-enhance the entities.
> However, this did not happen when I went the app managed route - which is
> like running in JSE mode (which requires classes to be listed).  I had to
> perform enhancement by other means and my entities needed to be listed in
> the persistence.xml.
>
> Injection into a servlet or EJB looks to be the best way to go, if
> possible.
>
> -Jeremy
>
> On Mon, Jul 19, 2010 at 8:04 AM, Stefan Schilling wrote:
>
>> Hello,
>>
>> I have a Glassfishv3 running here and *need* to use OpenJPA-2.0.0.
>>
>> I'm currently having two different setups in our persistence.xml; here's
>> the working one:
>>
>> http://java.sun.com/xml/ns/persistence";
>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>>http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
>> version="1.0">
>>
>>> transaction-type="RESOURCE_LOCAL">
>>
>>  org.apache.openjpa.persistence.PersistenceProviderImpl
>>jdbc/MyDataSource
>>
>>> value="DefaultLevel=WARN, Runtime=INFO, Tool=INFO, SQL=TRACE"/>
>>
>>
>>
>> 
>>
>> This one has the disadvantage, that the entity classes used (here: Class1
>> and Class2) need to be listed twice (in persistence.xml and pom.xml), to
>> configure the Enhancer outside of Glassfish and push the results into
>> OpenJPA's MetaDataFactory. Of course, keeping two lists of classes up to
>> date is error prone, especially as the following error is produced, if this
>> step is omitted or some classes are forgotten:
>>
>> 
>> org.apache.openjpa.persistence.ArgumentException: An error occurred while
>> parsing the query filter "SELECT g FROM Class1 g ORDER BY g.dateCreated
>> DESC". Error message: The name "Class1" is not a recognized entity or
>> identifier. Known entity names: []
>>at
>> org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:197)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:167)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:242)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:212)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:205)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$200(JPQLExpressionBuilder.java:81)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:2387)
>>at
>> org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:61)
>>at
>> org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:154)
>>at
>> org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:671)
>>at
>> org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:652)
>>at
>> org.apache.openjpa.kernel.QueryImpl.

Re: Glassfishv3 + OpenJPA-2.0.0: Enhancer not working

[Jeremy Bauer]

Stefan,

Are you using an injected entity manager or entity manager factory:

@PersistenceUnit
private EntityManagerFactory emf;

or going the application managed route:

emf =
Persistence.createEntityManagerFactory("myApplicationPersistenceUnit");

?

In my simple test, I found that OpenJPA 2.0.0 OpenJPA 2.0.0 worked well with
GlassFish v3 (74.2)  when injecting an emf.  The classes did not need to be
listed in the persistence.xml and OpenJPA's class transformer hooked into
the container - so I did not need to pre-enhance the entities.  However,
this did not happen when I went the app managed route - which is like
running in JSE mode (which requires classes to be listed).  I had to perform
enhancement by other means and my entities needed to be listed in the
persistence.xml.

Injection into a servlet or EJB looks to be the best way to go, if possible.

-Jeremy

On Mon, Jul 19, 2010 at 8:04 AM, Stefan Schilling  wrote:

> Hello,
>
> I have a Glassfishv3 running here and *need* to use OpenJPA-2.0.0.
>
> I'm currently having two different setups in our persistence.xml; here's
> the working one:
>
> http://java.sun.com/xml/ns/persistence";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
> transaction-type="RESOURCE_LOCAL">
>
>  org.apache.openjpa.persistence.PersistenceProviderImpl
>jdbc/MyDataSource
>
> value="DefaultLevel=WARN, Runtime=INFO, Tool=INFO, SQL=TRACE"/>
>
>
>
> 
>
> This one has the disadvantage, that the entity classes used (here: Class1
> and Class2) need to be listed twice (in persistence.xml and pom.xml), to
> configure the Enhancer outside of Glassfish and push the results into
> OpenJPA's MetaDataFactory. Of course, keeping two lists of classes up to
> date is error prone, especially as the following error is produced, if this
> step is omitted or some classes are forgotten:
>
> 
> org.apache.openjpa.persistence.ArgumentException: An error occurred while
> parsing the query filter "SELECT g FROM Class1 g ORDER BY g.dateCreated
> DESC". Error message: The name "Class1" is not a recognized entity or
> identifier. Known entity names: []
>at
> org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:197)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:167)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:242)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:212)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:205)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$200(JPQLExpressionBuilder.java:81)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:2387)
>at
> org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:61)
>at
> org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:154)
>at
> org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:671)
>at
> org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:652)
>at
> org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:618)
>at
> org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:680)
>at org.apache.openjpa.kernel.QueryImpl.compile(QueryImpl.java:587)
>at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:985)
>at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:971)
>at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:100)
>at
> my.domain.database.DatabaseAccess.getAllClass1(DatabaseAccess.java:159)
>at my.domain.portlets.MyPortlet.doView(MyPortlet.java:74)
>at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
>at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
>at
> com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:103)
>at
> com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:66)
>at
> com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:91)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>at
> org.apache.catalina.core.StandardWrapper.service(Standard

Re: Glassfishv3 + OpenJPA-2.0.0: Enhancer not working

[Jeremy Bauer]

Stefan,

It does not look like your persistent classes are being discovered.  I think
I have glassfish v3 installed somewhere, so I'll see if I can reproduce the
issue.  BTW, there's a developer's edition of WebSphere Application Server
V7[1] and a feature pack for OSGi/JPA 2.0[2] available for it.  That'll give
you nearly the same environment as your target platform.

-Jeremy

[1] http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/
[2] http://www-01.ibm.com/software/webservers/appserv/was/featurepacks/osgi/

On Mon, Jul 19, 2010 at 8:04 AM, Stefan Schilling  wrote:

> Hello,
>
> I have a Glassfishv3 running here and *need* to use OpenJPA-2.0.0.
>
> I'm currently having two different setups in our persistence.xml; here's
> the working one:
>
> http://java.sun.com/xml/ns/persistence";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
>http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";
> version="1.0">
>
> transaction-type="RESOURCE_LOCAL">
>
>  org.apache.openjpa.persistence.PersistenceProviderImpl
>jdbc/MyDataSource
>
> value="DefaultLevel=WARN, Runtime=INFO, Tool=INFO, SQL=TRACE"/>
>
>
>
> 
>
> This one has the disadvantage, that the entity classes used (here: Class1
> and Class2) need to be listed twice (in persistence.xml and pom.xml), to
> configure the Enhancer outside of Glassfish and push the results into
> OpenJPA's MetaDataFactory. Of course, keeping two lists of classes up to
> date is error prone, especially as the following error is produced, if this
> step is omitted or some classes are forgotten:
>
> 
> org.apache.openjpa.persistence.ArgumentException: An error occurred while
> parsing the query filter "SELECT g FROM Class1 g ORDER BY g.dateCreated
> DESC". Error message: The name "Class1" is not a recognized entity or
> identifier. Known entity names: []
>at
> org.apache.openjpa.kernel.exps.AbstractExpressionBuilder.parseException(AbstractExpressionBuilder.java:119)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getClassMetaData(JPQLExpressionBuilder.java:197)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.resolveClassMetaData(JPQLExpressionBuilder.java:167)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:242)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateMetaData(JPQLExpressionBuilder.java:212)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.getCandidateType(JPQLExpressionBuilder.java:205)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder.access$200(JPQLExpressionBuilder.java:81)
>at
> org.apache.openjpa.kernel.jpql.JPQLExpressionBuilder$ParsedJPQL.populate(JPQLExpressionBuilder.java:2387)
>at
> org.apache.openjpa.kernel.jpql.JPQLParser.populate(JPQLParser.java:61)
>at
> org.apache.openjpa.kernel.ExpressionStoreQuery.populateFromCompilation(ExpressionStoreQuery.java:154)
>at
> org.apache.openjpa.kernel.QueryImpl.newCompilation(QueryImpl.java:671)
>at
> org.apache.openjpa.kernel.QueryImpl.compilationFromCache(QueryImpl.java:652)
>at
> org.apache.openjpa.kernel.QueryImpl.compileForCompilation(QueryImpl.java:618)
>at
> org.apache.openjpa.kernel.QueryImpl.compileForExecutor(QueryImpl.java:680)
>at org.apache.openjpa.kernel.QueryImpl.compile(QueryImpl.java:587)
>at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:985)
>at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:971)
>at
> org.apache.openjpa.persistence.EntityManagerImpl.createQuery(EntityManagerImpl.java:100)
>at
> my.domain.database.DatabaseAccess.getAllClass1(DatabaseAccess.java:159)
>at my.domain.portlets.MyPortlet.doView(MyPortlet.java:74)
>at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
>at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
>at
> com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:103)
>at
> com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:66)
>at
> com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:91)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>at
> org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
>at
> org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:802)
>at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:664)
>at
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:619)
>at
> org.apache.catalina.core

Re: Saving a double in prosgres

[Jeremy Bauer]

Hi Håkon,

I also see the rounded value when using DECIMAL(10, 6).  OpenJPA passes the
double value as-is to the JDBC driver and the JDBC driver or PostgreSQL DB
does the rounding.  It looks like "double precision" is a better choice for
a data type.

@ElementColumn(name = "ELEMENT", columnDefinition="double
precision",nullable=false)

Using this type, I was able to store and returned the unrounded value
[2.1993] within my entity upon query.

Note:  If you use SQL Shell/psql to verify the value, the value gets
displayed as rounded whether you use the decimal or double precision type.
So, be sure you validate the value within your JPA code.

-Jeremy

On Fri, Jun 11, 2010 at 9:00 AM, Rick Curtis  wrote:

> Are you using OpenJPA to generate your tables? If so, what is the SQL that
> is being generated to create this table?
>
> 2010/6/11 Håkon Sagehaug 
>
> > Hi
> >
> > I tried to add the column definition
> >
> > @ElementColumn(name = "ELEMENT", columnDefinition="DECIMAL(10,
> > 6)",nullable=false)
> >
> > But got the same when I want to persist value 2.199 I end up with
> 2.2.
> > Any other tips? I use openjpa 1.2.0 should I migrate to 2.0?
> >
> > cheers, Håkon
> >
> >
> >
> > On 10 June 2010 18:19, Jeremy Bauer  wrote:
> >
> > > Håkon,
> > >
> > > I did not find a DOUBLEUNSIGNED type supported for PostgreSQL, but
> could
> > > have missed something.
> > >
> > > This should provide what you are looking for though...
> > >
> > >@PersistentCollection
> > >@ElementColumn(name = "ELEMENT", columnDefinition="DECIMAL(10,
> > > 6)",nullable=false)
> > >private double[] doubleValues;
> > >
> > > JPA/OpenJPA 2.0 provides standardized support for column definitions by
> > > using @ElementCollection and @Column, but unlike @PersistentCollection,
> > > @ElementCollection cannot be applied to an array.  Instead, you'd need
> to
> > > use a collection type.
> > >
> > > If you are using OpenJPA 2.0 you could modify your code as follows:
> > >
> > >@ElementCollection
> > >@Column(columnDefinition="DECIMAL(10,6)",nullable=false)
> > >private List doubleValues;
> > >
> > >public void setDoubles(Double[] doubles) {
> > > doubleValues = Arrays.asList(doubles);
> > >}
> > >
> > >public Double[] getDoubles() {
> > >return (Double[])doubleValues.toArray();
> > >}
> > >
> > > Since List does not support primitive types, you'd also need to use the
> > > Double object type.  You could then modify your getter and setter to
> > > convert
> > > to and from a primitive array.  I didn't go that far, but it would be
> > > fairly
> > > simple.  In addition, if you need to maintain the order of the array in
> > the
> > > DB, use the @OrderColumn annotation.  There is an OpenJPA version for
> JPA
> > > 1.0 apps and a standardized version in JPA 2.0, same annotation name,
> > > different packages.
> > >
> > > hth,
> > > -Jeremy
> > >
> > > 2010/6/10 Håkon Sagehaug 
> > >
> > > > Hi all,
> > > >
> > > > I've got a persitent collection in a entity looking like this
> > > >
> > > > @PersistentCollection
> > > >double[] doubleValues;
> > > >
> > > > But when  I store the values the, it's rounded up. So if I want to
> > store
> > > > the
> > > > value 2.1993 in the database it's stored as 2.2. The
> driver
> > I
> > > > 'm
> > > > using is postgresql-8.3-603.jdbc3.jar. Should I use another type in
> the
> > > > entity or is there another solution. I guess it's this issue [1], I'm
> > > > facing. I found that you could set column property like this
> > > >
> > > >
> > > >
> > >
> >
>  
> @Column(columnDefinition="DOUBLEUNSIGNED",precision=10,scale=6,nullable=false)
> > > >
> > > > But hwo can I set hat on a persitent collection?
> > > >
> > > > cheers, Håkon
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://openjpa.apache.org/builds/latest/docs/manual/dbsupport_postgresql.html#dbsupport_postgresql_issues
> > > >
> > >
> >
>

Re: Saving a double in prosgres

[Jeremy Bauer]

Håkon,

I did not find a DOUBLEUNSIGNED type supported for PostgreSQL, but could
have missed something.

This should provide what you are looking for though...

@PersistentCollection
@ElementColumn(name = "ELEMENT", columnDefinition="DECIMAL(10,
6)",nullable=false)
private double[] doubleValues;

JPA/OpenJPA 2.0 provides standardized support for column definitions by
using @ElementCollection and @Column, but unlike @PersistentCollection,
@ElementCollection cannot be applied to an array.  Instead, you'd need to
use a collection type.

If you are using OpenJPA 2.0 you could modify your code as follows:

@ElementCollection
@Column(columnDefinition="DECIMAL(10,6)",nullable=false)
private List doubleValues;

public void setDoubles(Double[] doubles) {
 doubleValues = Arrays.asList(doubles);
}

public Double[] getDoubles() {
return (Double[])doubleValues.toArray();
}

Since List does not support primitive types, you'd also need to use the
Double object type.  You could then modify your getter and setter to convert
to and from a primitive array.  I didn't go that far, but it would be fairly
simple.  In addition, if you need to maintain the order of the array in the
DB, use the @OrderColumn annotation.  There is an OpenJPA version for JPA
1.0 apps and a standardized version in JPA 2.0, same annotation name,
different packages.

hth,
-Jeremy

2010/6/10 Håkon Sagehaug 

> Hi all,
>
> I've got a persitent collection in a entity looking like this
>
> @PersistentCollection
>double[] doubleValues;
>
> But when  I store the values the, it's rounded up. So if I want to store
> the
> value 2.1993 in the database it's stored as 2.2. The driver I
> 'm
> using is postgresql-8.3-603.jdbc3.jar. Should I use another type in the
> entity or is there another solution. I guess it's this issue [1], I'm
> facing. I found that you could set column property like this
>
>
>  
> @Column(columnDefinition="DOUBLEUNSIGNED",precision=10,scale=6,nullable=false)
>
> But hwo can I set hat on a persitent collection?
>
> cheers, Håkon
>
> [1]
>
> http://openjpa.apache.org/builds/latest/docs/manual/dbsupport_postgresql.html#dbsupport_postgresql_issues
>

Re: Attribute 'pk-column-value' is not allowed to appear in element 'generated-value'

[Jeremy Bauer]

Hi Gilberto,

The generated-value element does not provide an attribute named
"pk-column-value", thus, the schema validator validating your orm.xml file
is throwing an exception.

This line is the culprit:



The schema definition for generated-value is as follows:


  

@Target({METHOD, FIELD}) @Retention(RUNTIME)
public @interface GeneratedValue {
   GenerationType strategy() default AUTO;
   String generator() default "";
}

  
  
  


The pk-column-name can only be specified on the table generator itself.  I
don't think it is possible to override the pk-column-name at an attribute
level - certainly not via generated-value.  According to the JPA 2.0 spec:


3. The sequence-generator, table-generator, named-query,
named-native-query and sql-result-set-mapping elements are global
to the persistence unit. It is undefined to have more than one
sequence-generator or table-generator of the same name in the same
or different mapping files in a persistence unit.


Once a table generator is defined, there can/should only be one definition
for the persistence unit.  You can define multiples with a different
pk-column-name values, but the table-generator name needs to be unique.

hth,
-Jeremy

On Wed, Jun 9, 2010 at 9:29 AM, gilbertoca  wrote:

>
> Hi, hope everyone is well!
>
> Can anyone help me understand the following exception (
>
> http://code.google.com/p/construtor/source/browse/trunk/park-jpa/core/src/main/resources/META-INF/orm.xml
> my orm.xml file ):
> [CODE]
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 13 source files to
> /home/gilberto/dev/netbeans-config/park-jpa/core/target/classes
> [INFO] [antrun:run {execution: default}]
> [INFO] Executing tasks
> 216  parkPU  INFO   [main] openjpa.Tool - No targets were given.  Running
> on
> all classes in your persistent classes list, or all metadata files in
> classpath directories if you have not listed your persistent classes.  Use
> -help to display tool usage information.
> 
> org.apache.openjpa.util.GeneralException: org.xml.sax.SAXException:
>
> file:/home/gilberto/dev/netbeans-config/park-jpa/core/target/classes/META-INF/orm.xml
> [Location: Line: 30, C: 105]: org.xml.sax.SAXParseException:
> cvc-complex-type.3.2.2: Attribute 'pk-column-value' is not allowed to
> appear
> in element 'generated-value'.
>at
>
> org.apache.openjpa.persistence.PersistenceMetaDataFactory.parseXML(PersistenceMetaDataFactory.java:295)
>at
>
> org.apache.openjpa.persistence.PersistenceMetaDataFactory.load(PersistenceMetaDataFactory.java:228)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:554)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:374)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:358)
>at org.apache.openjpa.enhance.PCEnhancer.(PCEnhancer.java:256)
>at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4653)
>at
> org.apache.openjpa.ant.PCEnhancerTask.executeOn(PCEnhancerTask.java:89)
>at
> org.apache.openjpa.lib.ant.AbstractTask.execute(AbstractTask.java:171)
>at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:616)
>at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
>at org.apache.tools.ant.Task.perform(Task.java:348)
>at org.apache.tools.ant.Target.execute(Target.java:357)
>at
>
> org.apache.maven.plugin.antrun.AbstractAntMojo.executeTasks(AbstractAntMojo.java:118)
>at
> org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:98)
>at
>
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
>at
>
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>at org.apache.maven.Defa

Re: relation "mySequence" already exists

[Jeremy Bauer]

I agree.  Fixing this would be a good thing, provided it can be fixed
without causing other issues  (ie. removing or attempting to remove other
system created sequences).  I created OPENJPA-1689[1] for this issue.

-Jeremy

[1] https://issues.apache.org/jira/browse/OPENJPA-1689

On Wed, Jun 9, 2010 at 5:50 AM, No1UNo  wrote:

>
> It would be nice to fix this. I'd hate to see anyone else hit this.
> Failing that documenting this unexpected behavior would be okay.
>
> -=- Jerry (via iPhone)
>
> On Jun 9, 2010, at 12:38 AM, "Christopher Schmidt-4 [via OpenJPA]" <
> ml-node+5156733-944799821-93...@n2.nabble.com
>  > wrote:
>
> > Jersey,
> >
> > You are right. I changed the sequenceName to xxx and it works...
> >
> > Thx for help :)
> >
> > Am 08.06.2010 23:17 schrieb "Jeremy Bauer" <[hidden email]>:
> >
> > Hi Christopher,
> >
> > As it turns out, I don't think this problem is the same as
> > OPENJPA-1259.
> > There is special code in the PostgresDictionary that treats sequences
> > suffixed with "_SEQ" as system managed sequences.  The comment in
> > PostgresDictionary.isSystemSequence reads:
> >
> >// filter out generated sequences used for bigserial cols,
> > which are
> >// of the form __seq
> >
> > This explains why the same code worked for me on DB2.  Are you able to
> > modify the sequence name?  (ex. sequenceName = "seq_obj_item_id")
> > If not,
> > please file a new JIRA.   It may/should be possible to make the code
> > a bit
> > smarter by actually verifying _seq suffixed sequences are for a
> > bigserial
> > column[1] instead of just making the assumption.
> >
> > -Jeremy
> >
> > [1]
> >
> http://www.postgresql.org/docs/8.4/static/datatype-numeric.html#DATATYPE-SERIAL
> >
> >
> > On Mon, Jun 7, 2010 at 2:39 PM, Jeremy Bauer <[hidden email]> wrote:
> >
> > > Christopher,
> > >
> > > I am ...
> >
> >
> > View message @
> http://openjpa.208410.n2.nabble.com/relation-mySequence-already-exists-tp5136569p5156733.html
> > To start a new topic under OpenJPA Users, email
> ml-node+208411-1595610943-93...@n2.nabble.com
> > To unsubscribe from OpenJPA Users, click here.
> >
>
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/relation-mySequence-already-exists-tp5136569p5157786.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: relation "mySequence" already exists

[Jeremy Bauer]

Hi Christopher,

As it turns out, I don't think this problem is the same as OPENJPA-1259.
There is special code in the PostgresDictionary that treats sequences
suffixed with "_SEQ" as system managed sequences.  The comment in
PostgresDictionary.isSystemSequence reads:

// filter out generated sequences used for bigserial cols, which are
// of the form __seq

This explains why the same code worked for me on DB2.  Are you able to
modify the sequence name?  (ex. sequenceName = "seq_obj_item_id")  If not,
please file a new JIRA.   It may/should be possible to make the code a bit
smarter by actually verifying _seq suffixed sequences are for a bigserial
column[1] instead of just making the assumption.

-Jeremy

[1]
http://www.postgresql.org/docs/8.4/static/datatype-numeric.html#DATATYPE-SERIAL

On Mon, Jun 7, 2010 at 2:39 PM, Jeremy Bauer  wrote:

> Christopher,
>
> I am able to reproduce the problem now with PostgreSQL using your code
> snippet. For now, I think I should be able to get by without the original
> code.  Thanks so much for the offer, though.  If you could test the fix
> if/when it is ready, that would be a great.
>
> -Jeremy
>
>
> On Mon, Jun 7, 2010 at 1:51 PM, Christopher Schmidt <
> fakod...@googlemail.com> wrote:
>
>> Hi Jeremy, thx for your answer...
>>
>> If it helps I can push the sources and tests to Github (in a view days)?
>>
>> On Mon, Jun 7, 2010 at 8:33 PM, Jeremy Bauer  wrote:
>> > Hi Christopher,
>> >
>> > . . .
>>
>
>

Re: relation "mySequence" already exists

[Jeremy Bauer]

Christopher,

I am able to reproduce the problem now with PostgreSQL using your code
snippet. For now, I think I should be able to get by without the original
code.  Thanks so much for the offer, though.  If you could test the fix
if/when it is ready, that would be a great.

-Jeremy

On Mon, Jun 7, 2010 at 1:51 PM, Christopher Schmidt  wrote:

> Hi Jeremy, thx for your answer...
>
> If it helps I can push the sources and tests to Github (in a view days)?
>
> On Mon, Jun 7, 2010 at 8:33 PM, Jeremy Bauer  wrote:
> > Hi Christopher,
> >
> > . . .
>

Re: relation "mySequence" already exists

[Jeremy Bauer]

Hi Christopher,

As you found, it looks like you are running into issue OPENJPA-1259.  This
problem appears to be PostgreSQL specific, since I wasn't able to reproduce
the problem on DB2 (the sequence got dropped with DB2).

Not the best solution in the world but, for now, you could specify to ignore
the error.  This allows creation of the remaining DB artifacts to continue
and permits the app to run.



Unless someone else tackles it first, I should have some time to look into
the issue later this week.

hth,
-Jeremy

On Thu, Jun 3, 2010 at 2:17 PM, Christopher Schmidt  wrote:

> Hi all, using OpenJPA 2.0.0 with Postgresql 8.4 JDBC4
>
> I want to create the schema with the following property:
>  value="buildSchema(SchemaAction='drop,add')"/>
>
> The entity is defined as follows:
>
> @Entity
> @Table(name = "obj_item")
> @Inheritance(strategy = InheritanceType.JOINED)
> @SequenceGenerator(name = "obj_item_id_seq", sequenceName =
> "obj_item_id_seq", allocationSize = 1)
> class ObjectItem ...
>
> it seems that the sequence will not be dropped - so I get the
> following exception:
> org.apache.openjpa.persistence.PersistenceException: ERROR: relation
> "obj_item_id_seq" already exists {stmnt 1834517285 CREATE SEQUENCE
> obj_item_id_seq START WITH 1} [code=0, state=42P07]
>at
> org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:556)...
>
> I found a bug here: https://issues.apache.org/jira/browse/OPENJPA-1259
>
> Any advice?
>
> Regards Christopher
>

Re: OpenJPA confusing classes

[Jeremy Bauer]

I started putting together a doc update and found that this compatibility
flag has been around a while.  Can anyone explain why 2.0 behaves
differently than 1.x by default?  (ie.  flag not needed on 1.2, but required
for 2.0)  Did some new 2.0 spec requirement require OpenJPA to behave
differently in this scenario?

-Jeremy

On Tue, May 25, 2010 at 8:09 AM, Jeremy Bauer  wrote:

> Good call, Pinaki!  That fixed the failing testcase.  I did/do not see this
> change documented in our 1.0 -> 2.0 migration considerations.  I'll update
> the JIRA, including the need for documentation.
>
> -Jeremy
>
>
> On Tue, May 25, 2010 at 1:07 AM, Pinaki Poddar  wrote:
>
>>
>> This should work:
>>> value="StrictIdentityValues=true"/>
>>
>>
>> -
>> Pinaki
>> --
>> View this message in context:
>> http://openjpa.208410.n2.nabble.com/OpenJPA-confusing-classes-tp5094249p5097022.html
>> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>>
>
>

Re: OpenJPA confusing classes

[Jeremy Bauer]

Good call, Pinaki!  That fixed the failing testcase.  I did/do not see this
change documented in our 1.0 -> 2.0 migration considerations.  I'll update
the JIRA, including the need for documentation.

-Jeremy

On Tue, May 25, 2010 at 1:07 AM, Pinaki Poddar  wrote:

>
> This should work:
> value="StrictIdentityValues=true"/>
>
>
> -
> Pinaki
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/OpenJPA-confusing-classes-tp5094249p5097022.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: JPA2.0 Criteria API question select()

[Jeremy Bauer]

Zhanming,

Have you generated metamodel classes (_.java) for your
entities?  This section of the OpenJPA manual explains how to generate them.

http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/manual.html#d0e11088
-Jeremy
On Mon, May 24, 2010 at 1:37 PM, Kevin Sutter  wrote:

> Hi,
> Your example looks okay to me.  Your selection is singular.  There should
> be
> no reason for the multiselect.  Maybe Eclipse is complaining about a
> problem
> that doesn't exist.  Which Eclipse are you using?  And, did you
> re-configure
> your Eclipse environment to be using OpenJPA instead of EclipseLink?  Does
> your example compile cleanly outside of Eclipse?  Maybe somebody else can
> spot an error in your example, but it looks like it should work.
>
> Kevin
>
> On Mon, May 24, 2010 at 9:46 AM, Zhanming Qi  wrote:
>
> >
> > Hi,
> >
> > I download OpenJPA2.0 and try to use Criteria Query, and I download
> JPA2.0
> > Spec final release document form jcp.org
> >
> > At page 263, it wrote this:
> >
> > CriteriaBuilder cb = ...
> > CriteriaQuery q = cb.createQuery(String.class);
> > Root customer = q.from(Customer.class);
> > Join order = customer.join(Customer_.orders);
> > Join item = order.join(Order_.lineItems);
> > q.select(customer.get(Customer_.name))
> > .where(cb.equal(item.get(Item_.product).get(Product_.productType),
> > "printer"));
> >
> > and I try it like this
> > @Test
> > public void testCriteriaQueryJoins(){
> >EntityManager em = entityManagerProvider.get();
> >CriteriaBuilder cb = em.getCriteriaBuilder();
> >CriteriaQuery q = cb.createQuery(Corporation.class);
> >Root corporation = q.from(Corporation.class);
> >Join division =
> > corporation.join(Corporation_.divisions);
> >Join department =
> > division.join(Division_.departments);
> >q.select(corporation.get(Corporation_.name))
> >
> > .where(cb.equal(department.get(Department_.division).get(Division_.name),
> > DIVISION_NAME));
> >TypedQuery tq = em.createQuery(q);
> >List result = tq.getResultList();
> >assertThat(result, notNullValue());
> >for (Corporation c : result){
> >System.out.println(c.getName());
> >}
> >em.clear();
> > }
> >
> > But there is something wrong in this example.
> > At this line q.select(corporation.get(Corporation_.name)), and Eclipse
> tell
> > me that: the select method is wrong, and advise me to use
> multiselect(...)
> > instead
> >
> > Is my code wrong? or document wrong? or some other wrong?
> >
> > Thanks,
> > Zhanming.
> > --
> > View this message in context:
> >
> http://openjpa.208410.n2.nabble.com/JPA2-0-Criteria-API-question-select-tp5094119p5094119.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
>

Re: OpenJPA confusing classes

[Jeremy Bauer]

Hi Chris,

I was able to reproduce this problem.  A SQL trace is showing that OpenJPA
is executing the finder against the base table instead of the individual
table(s).  Please file a JIRA for this bug.  I'll get the test code into
trunk and then someone (possibly myself) can look into fixing it.

-Jeremy

On Mon, May 24, 2010 at 11:55 AM, C N Davies  wrote:

> Hi Kevin,
>
>
>
> I have L2 disabled as it has been too problematic for me, so it looks like
> the issue is in the L1 cache.  I don't have a test case  I can send out yet
> since I'm up at 3am in the morning trying to sort out JPA issues, yet
> again.
>
>
>
>
> Chris
>
>
>
>
>
> From: Kevin Sutter [mailto:kwsut...@gmail.com]
> Sent: Tuesday, 25 May 2010 2:23 AM
> To: users@openjpa.apache.org; c...@cndavies.com
> Subject: Re: OpenJPA confusing classes
>
>
>
> Hi Chris,
> This isn't good if the exact same code was working okay in 1.2.2 and it's
> not now.  Now that the configuration and usage of the L2 cache is defined
> by
> the spec, there may be an inconsistency that needs to be resolved.  Do you
> have the L2 DataCache enabled?  It's off by default.
>
> Or, are you referring to the Persistence Context cache (also known as the
> L1
> cache)?
>
> How much have you been able to debug this problem in order to narrow down
> the source?  You mention the "cache", but I'm not sure which one you are
> referring to.  Your scenario looks pretty straight forward.  Have you been
> able to create a simple testcase to demonstrate the problem?  Any
> suggestions for resolution?
>
> Thanks,
> Kevin
>
> On Mon, May 24, 2010 at 10:55 AM, C N Davies  wrote:
>
> Well that would make sense if I wasn't using table per class. I used this
> very same code in 1.2.2 with no issues but 2.0 broke it.
>
> The DB is not enforcing this contraint, it is OpenJPA or more specifically
> the cache
>
> Chris
>
>
>
> -Original Message-
> From: KARR, DAVID (ATTSI) [mailto:dk0...@att.com]
> Sent: Tuesday, 25 May 2010 1:33 AM
> To: users@openjpa.apache.org; c...@cndavies.com
> Subject: RE: OpenJPA confusing classes
>
> > -Original Message-
> > From: C N Davies [mailto:c...@cndavies.com]
> > Sent: Monday, May 24, 2010 8:19 AM
> > To: users@openjpa.apache.org
> > Subject: OpenJPA confusing classes
> >
> > Here's a snippet of my ode,
> >
> > (Department) es.find(Department.class, "N/A");
> >
> > (PrintQueue) es.find(PrintQueue.class, "N/A");
> >
> > Both Department and PrintQueue entities are based upon the same super
> > class
> > but I use table per class so they are in separate tables.
> >
> > As you can see they both have the same key, but if I put the
> department
> > line
> > 1st the find of the print queue will generate a class cast exception
> > trying
> > to cast a Department to a PrintQueue. If I put the PrintQueue line 1st
> > I
> > will get a class cast exception trying to cast a PrintQueue to  a
> > Department.  The second find doesn't generate any SQL  if I have trace
> > logging turned on so it looks to me that it is a cache issue.
> >
> > I can't see anything like this in the JIRA is it a known bug or not?
>
> I would assume keys in an inheritance tree have to be unique across the
> hierarchy.  If not, then there's no way to tell what object it really
> refers to.  The CCEs are due to the fact that caching in the session
> uses the PK as the key (obviously).  You already loaded a Department
> with that PK, so the reference on the next line is going to load it from
> the session, which blows up.
>
>
>
>

Re: Schema version problem upgrading to JPA 2.0

[Jeremy Bauer]

Hi David,

Based on the version and schemaLocation attributes (primarily version),
OpenJPA should provide the proper rsrc file to the XML parser so that it can
validate the orm using the correct version of the schema.  (ie.
version="1.0" - orm-xsd.rsrc ; version="2.0" - orm_2_0-xsd.rsrc)  The
specification uses the same namespace for both versions so that you can move
from one version to the next with minimal changes.

If you are still experiencing this problem can you provide a stripped down
version of your war or ear file?  I don't have WebLogic, but given a
template, I could try to reproduce the issue on another app server.

-Jeremy

On Wed, May 19, 2010 at 9:08 PM, KARR, DAVID (ATTSI)  wrote:

> > -Original Message-
> > From: KARR, DAVID (ATTSI)
> > Sent: Wednesday, May 19, 2010 6:31 PM
> > To: users@openjpa.apache.org
> > Subject: Schema version problem upgrading to JPA 2.0
> >
> > I think I noticed some talk about this before, but I can't find it in
> > the archives now.
> >
> > I tried to upgrade to version 2.0.0 today.  The upgrade with no
> changes
> > worked fine.  Now I'm trying to modify it to use the small number of
> > 2.0
> > features that I'm attempting to use.
> >
> > When I changed the "schemaLocation" attribute to point to the 2.0 xsd
> > (I'm really surprised the namespace didn't change), then Eclipse
> > complained that I had to change the "version" attribute also, which I
> > did (to 2.0).  I then added several "order-column" elements where I
> was
> > previously using the OpenJPA OrderColumn annotation.  When I attempted
> > to build this, I got schema validation errors, claiming that there was
> > no "order-column" element (even though Eclipse validates this).  If I
> > temporarily changed the "version" attribute value back to "1.0", then
> I
> > could get through that part of the build, even though Eclipse is now
> > complaining.  I haven't attempted to run the app in this state.
> >
> > What am I missing?
>
> I noticed that in the openjpa jar file, there are two schema files,
> "orm-xsd.rsrc" and "orm_2_0-xsd.rsrc".  The first is the 1.x schema, and
> the second is clearly the 2.x schema.  I'm really wondering more about
> the fact that the namespace is the same between them.  That can't be
> right.  I wonder what would happen if I removed the 1.x schema from the
> jar file?
>

Re: [VOTE] Apache OpenJPA 2.0.0 release candidate #2

[Jeremy Bauer]

+1  Looks great.  Thanks again, Donald.

-Jeremy

On Mon, Apr 19, 2010 at 1:45 PM, Donald Woods  wrote:

> I've staged a RC2 for OpenJPA 2.0.0 based on r935683 of the code in the
> 2.0.x branch, which was tagged in svn to:
> https://svn.apache.org/repos/asf/openjpa/tags/2.0.0/
>
> The following issues were resolved since the first RC vote on April 11th
> (svn r932976):
>  OPENJPA-1091, OPENJPA-1605, OPENJPA-1628, OPENJPA-1630, OPENJPA-1631
>
> Release Notes:
>
> http://svn.apache.org/viewvc/openjpa/tags/2.0.0/openjpa-project/RELEASE-NOTES.html?view=co
>
> Maven staging repo:
> http://people.apache.org/~dwoods/openjpa/2.0.0/staging-repo/
>
> Site staging:
> http://people.apache.org/~dwoods/openjpa/2.0.0/staging-site/
>
> Distribution artifacts:
>
> http://people.apache.org/~dwoods/openjpa/2.0.0/staging-site/apache-openjpa/downloads/
>
> User's Guide:
>
> http://people.apache.org/~dwoods/openjpa/2.0.0/staging-site/apache-openjpa/docs/
>
> API Docs:
> http://people.apache.org/~dwoods/openjpa/2.0.0/staging-site/apidocs/
>
>
> The RAT and IANAL build checks passed.
> The openjpa and openjpa-all shaded jar content looks good.
> The test-base, test-sources and tests jars are in the staging repo.
>
>
> The vote will be open for 3 days.
>
> [ ] +1
> [ ]  0
> [ ] -1 (and reason why)
>
>
> Thanks,
> Donald
>
>

Re: [ANNOUNCE] Welcome Rick Curtis as the newest member of the OpenJPA PMC

[Jeremy Bauer]

Congrats, Rick!  Well done!

-Jeremy

On Fri, Mar 26, 2010 at 10:08 AM, Michael Dick  wrote:

> All, Please join us in congratulating Rick Curtis as the newest member of
> the OpenJPA *PMC*. It's been great to have Rick working with us as a
> committer on OpenJPA. Even better to have him join us in providing
> oversight
> of the OpenJPA project.
>
> Way to go Rick!!!
>
> The Apache OpenJPA *PMC*
>
> -mike
>

Re: Terms for "catalog" and "schema"

[Jeremy Bauer]

Hi Daniel,

The various database vendors and JDBC drivers have different usage of
catalogs, some not using them at all or treating them the same as a schema.
While many JPA mapping constructs allow you to specify a catalog attribute,
I've found that OpenJPA uses the default catalog.  There is a JIRA[1] filed
to enhance the catalog support at some point, but there hasn't been much/any
call for it.  If you have specific scenarios you'd like to see supported,
please document them in the JIRA or post them and I'll get them added to the
JIRA.  That'll help ensure those scenarios get tested if/when the support is
added.

-Jeremy

[1] https://issues.apache.org/jira/browse/OPENJPA-840

On Thu, Mar 25, 2010 at 7:52 PM, Daniel Toffetti wrote:

>
>Now that I think again, the "catalog" is the specific database I'm
> connecting to... I've been surprised before by the fact that I could get a
> list of catalogs even when I'm connecting to one specific database, but
> anyway with Schemacrawler and with plain JDBC I could get it.
>Perhaps this will be of interest later if I need to support multiple
> database products, but right now I can get the list of tables I'm
> interested
> in.
>Thanks in advance for any comments,
>
> Best,
>
> Daniel
>
>
> Daniel Toffetti wrote:
> >
> >
> > Is there any other term for "catalog" in OpenJPA parlance ??  Am I
> > missing something ??
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Terms-for-catalog-and-schema-tp4801224p4801363.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: Use external classes as entities

[Jeremy Bauer]

This may/may not work depending on your environment and the class
definitions, but you could try defining the mappings and metadata for
ForeignClass1 and ForeignClass2 in an orm.xml file.

Another issue will be getting these classes enhanced and verifying they
still behave properly after enhancement  (ie. the business logic, if any,
still works properly).  If you are in a JSE environment, you could try using
the agent enhancer.  It will enhance the classes as they are loaded (no need
to modify the jar).  You'll likely need to specify the iCal4j jar in a
 element and define the foreign classes in  elements within
your persistence.xml.

-Jeremy

On Wed, Mar 24, 2010 at 2:25 PM, Pinaki Poddar  wrote:

>
> > Any ideas?
>
> Please see [1]
>
> [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#type
>
> -
> Pinaki
> --
> View this message in context:
> http://n2.nabble.com/Use-external-classes-as-entities-tp4787743p4793276.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: [VOTE] OpenJPA 2.0.0-beta3 release candidate

[Jeremy Bauer]

+1  Looks good!

-Jeremy

On Tue, Mar 23, 2010 at 9:36 PM, Donald Woods  wrote:

> I've staged a release candidate for OpenJPA 2.0.0 Beta 3 based on
> r926797 of the code in the 2.0.x branch, which was tagged in svn to:
> https://svn.apache.org/repos/asf/openjpa/tags/2.0.0-beta3/
>
> Release Notes:
>
> http://svn.apache.org/viewvc/openjpa/tags/2.0.0-beta3/openjpa-project/RELEASE-NOTES.html?view=co
>
> Maven staging repo:
> http://people.apache.org/~dwoods/openjpa/2.0.0-beta3/staging-repo/
>
> Site staging:
> http://people.apache.org/~dwoods/openjpa/2.0.0-beta3/staging-site/
>
> Distribution artifacts:
>
> http://people.apache.org/~dwoods/openjpa/2.0.0-beta3/staging-site/apache-openjpa/downloads/
>
> User's Guide:
>
> http://people.apache.org/~dwoods/openjpa/2.0.0-beta3/staging-site/apache-openjpa/docs/
>
> API Docs:
> http://people.apache.org/~dwoods/openjpa/2.0.0-beta3/staging-site/apidocs/
>
> The eventual landing page for Beta 3 on the wiki (most of the links will
> not work until the vote passes and artifacts are published):
> http://cwiki.apache.org/confluence/display/openjpa/OpenJPA+2.0.0+Beta+3
>
>
> The RAT and IANAL build checks passed.
> The openjpa and openjpa-all shaded jar content looks good.
> The test-base, test-sources and tests jars are in the staging repo.
> The build passed the JPA 2.0 TCK.
>
>
> The vote will be open for 72 hours or less.
>
> [ ] +1
> [ ]  0
> [ ] -1 (and reason why)
>
>
> Thanks,
> Donald
>
>
>

Re: Open jpa 2.0 and maven build

[Jeremy Bauer]

Including the schema location to the 2.0 persistence XSD should work and may
be necessary using Spring, since, like JEE containers, it may parse the
persistence.xml and expect the schemaLocation to be present for validation
purposes.  But, I haven't used Spring either so I can say for certain.

http://java.sun.com/xml/ns/persistence";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd";
version="2.0" >
...


-Jeremy

On Thu, Mar 11, 2010 at 2:50 PM, Donald Woods  wrote:

> By the JPA schema version specified in the persistence.xml -
>
> http://java.sun.com/xml/ns/persistence";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> version="2.0">
>
> The above is used in out junits to test the Bean Validation supprt which
> is JPA 2.0 specific.
>
> Not sure if using the reference to the 2_0.xsd works.
>
>
> -Donald
>
>
> On 3/11/10 3:40 PM, Pmoran wrote:
> >
> > That has not helped. let me get back to an earlier question, how does
> OPENJPA
> > determine a given project is version 1.0 versus 2.0?
> > My project does the following:
> > Set openjpa.specification=jpa 2.0
> > persistence.xml is version 2.0
> > no orm.xml
> > only openJPA-2.0.0beta2.jar on path
> > Eclipse (STS version) IDE, maven pom based build
> >
> > What am i missing?
>

Re: Open jpa 2.0 and maven build

[Jeremy Bauer]

Including the schema location to the 2.0 persistence XSD should work and may
be necessary using Spring, since, like JEE containers, it may parse the
persistence.xml and expect the schemaLocation to be present for validation
purposes.  But, I haven't used Spring either so I can say for certain.

http://java.sun.com/xml/ns/persistence";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd";
version="2.0" >
...


-Jeremy

On Thu, Mar 11, 2010 at 2:50 PM, Donald Woods  wrote:

> By the JPA schema version specified in the persistence.xml -
>
> http://java.sun.com/xml/ns/persistence";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> version="2.0">
>
> The above is used in out junits to test the Bean Validation supprt which
> is JPA 2.0 specific.
>
> Not sure if using the reference to the 2_0.xsd works.
>
>
> -Donald
>
>
> On 3/11/10 3:40 PM, Pmoran wrote:
> >
> > That has not helped. let me get back to an earlier question, how does
> OPENJPA
> > determine a given project is version 1.0 versus 2.0?
> > My project does the following:
> > Set openjpa.specification=jpa 2.0
> > persistence.xml is version 2.0
> > no orm.xml
> > only openJPA-2.0.0beta2.jar on path
> > Eclipse (STS version) IDE, maven pom based build
> >
> > What am i missing?
>

Re: Error trying to enhance at build time

[Jeremy Bauer]

Hi remmons,

The PCEnhancer requires the path to the file instead of the package.  For
example:

To compile: javac -cp openjpa-all-2.0.0-beta2.jar;.
com\aurigen\openjpanys\Message.java

then...

To enhance: java -cp openjpa-all-2.0.0-beta2.jar;.
org.apache.openjpa.enhance.PCEnhancer
com\aurigen\openjpanys\Message[.java|.class]

hth,

-Jeremy
On Thu, Mar 4, 2010 at 4:06 PM, Kevin Sutter  wrote:

> Hi remmons,
> Where are your application's java class files?  The exception stack below
> says that it can't find your Message.java file.  Is it in your classpath?
>
>[exec] Caused by: java.io.FileNotFoundException:
> com.aurigen.openjpanys.Message.java (The system cannot find the file
> specified)
>
> Kevin
>
> On Thu, Mar 4, 2010 at 1:24 PM, remmons  wrote:
>
> >
> > I am trying to enhance a class at build time, but I get an error message.
> >
> > Here is my command line:
> >
> > [exec] C:\document\eclipse350\webJava\OpenJpaNys>java -cp
> >
> src\java;build;lib\openjpa-2.0.0-beta2.jar;lib\openjpa-all-2.0.0-beta2.jar
> > org.apache.openjpa.enhance.PCEnhancer com.aurigen.openjpanys.Message.java
> >
> > Here is the error I am getting:
> >
> > [exec] Exception in thread "main"
> > org.apache.commons.lang.exception.NestableRuntimeException: Error
> > extracting
> > class information from "com.aurigen.openjpanys.Message.java".
> > [exec] at
> >
> >
> org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:226)
> > [exec] at
> >
> >
> org.apache.openjpa.lib.meta.ClassArgParser.parseTypes(ClassArgParser.java:161)
> > [exec] at
> > org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4638)
> > [exec] at
> > org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4601)
> > [exec] at
> > org.apache.openjpa.enhance.PCEnhancer$1.run(PCEnhancer.java:4571)
> > [exec] at
> >
> >
> org.apache.openjpa.lib.conf.Configurations.launchRunnable(Configurations.java:725)
> > [exec] at
> >
> >
> org.apache.openjpa.lib.conf.Configurations.runAgainstAllAnchors(Configurations.java:715)
> > [exec] at
> > org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4566)
> > [exec] at
> > org.apache.openjpa.enhance.PCEnhancer.main(PCEnhancer.java:4557)
> > [exec] Caused by: java.io.FileNotFoundException:
> > com.aurigen.openjpanys.Message.java (The system cannot find the file
> > specified)
> > [exec] at java.io.FileInputStream.open(Native Method)
> > [exec] at java.io.FileInputStream.(Unknown Source)
> > [exec] at java.io.FileReader.(Unknown Source)
> > [exec] at
> >
> >
> org.apache.openjpa.lib.meta.ClassArgParser.getFromJavaFile(ClassArgParser.java:339)
> > [exec] at
> >
> >
> org.apache.openjpa.lib.meta.ClassArgParser.parseTypeNames(ClassArgParser.java:219)
> > [exec] ... 8 more
> >
> > Can anyone tell me what is wrong?
> >
> > --
> > View this message in context:
> >
> http://n2.nabble.com/Error-trying-to-enhance-at-build-time-tp4676588p4676588.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
>

Re: Struts 2x + OpenJPA 2.0 M3 + ( Tomcat or Glassfish )

[Jeremy Bauer]

Seth,

Thanks for reporting this problem.  I've opened JIRA OPENJPA-1410[1].  The
code in PersistenceProviderImpl that sets up validation looks like it might
be suspect to classloading issues.  Which version of Tomcat are you using?

-Jeremy

[1] https://issues.apache.org/jira/browse/OPENJPA-1410

On Tue, Dec 1, 2009 at 5:56 AM, seth.jackson wrote:

>
> After further review, using Glassfish 2.1.1 I received this error message
> in
> the server log:
>
> Caused by: java.lang.LinkageError: loader constraint violation: when
> resolving method
>
> "org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(Lorg/apache/openjpa/conf/OpenJPAConfiguration;)Z"
> the class loader (instance of org/apache/catalina/loader/WebappClassLoader)
> of the current class,
> org/apache/openjpa/persistence/PersistenceProviderImpl, and the class
> loader
> (instance of sun/misc/Launcher$AppClassLoader) for resolved class,
> org/apache/openjpa/persistence/validation/ValidationUtils, have different
> Class objects for the type org/apache/openjpa/conf/OpenJPAConfiguration
> used
> in the signature
>
> So it appears to be the WebappClassLoader and the AppClassLoader are both
> loading the OpenJPAConfiguration from the same JAR file, causing the error
> when the class is trying to be resolved in this particular method..
>
>
>
> seth.jackson wrote:
> >
> > It appears something was modified in OpenJPA 2.0 M3 from M2 that causes a
> > LinkageError.
> >
> > In my current environment, I've tested both Glassfish and Tomcat using M2
> > and M3. M2 runs without problems, but M3 throws a linkage error as
> > follows:
> >
> > Caused by: java.lang.LinkageError: loader constraint violation: loader
> > (instance of sun/misc/Launcher$AppClassLoader) previously initiated
> > loading for a different type with name
> > "org/apache/openjpa/conf/OpenJPAConfiguration"
> >   at java.lang.ClassLoader.defineClass1(Native Method)
> >   at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> >   at
> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> >   at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> >   at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
> >   at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> >   at java.security.AccessController.doPrivileged(Native Method)
> >   at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> >   at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> >   at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> >   at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> >   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> >   at
> >
> org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(ValidationUtils.java:53)
> >   at
> >
> org.apache.openjpa.persistence.PersistenceProviderImpl.loadValidator(PersistenceProviderImpl.java:290)
> >   at
> >
> org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:97)
> >   at
> >
> org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:128)
> >   at
> >
> org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:111)
> >   at test_test.user.UserAction.execute(UserAction.java:39)
> >
> >
> > I've already confirmed that the OpenJPA classes in question do NOT exist
> > in any other JARs in the path.
> >
> > ValidationUtils.setupValidation(ValidationUtils.java:53) calls the
> > OpenJPAConfiguration.getConfigurationLog(). The object being referenced
> is
> > JDBCConfigurationImpl, which in other classes retrieves the log reference
> > perfectly fine, before it gets to the offending line.
> >
>
> --
> View this message in context:
> http://n2.nabble.com/Struts-2x-OpenJPA-2-0-M3-Tomcat-or-Glassfish-tp4087312p4093228.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: oracle 11g - operation not allowed: streams type cannot be used in batching

[Jeremy Bauer]

Nick,

I ran into a batching related issue while doing some Oracle testing on trunk
(2.0.0) a short while ago.  The issue was fixed in the 11.2.0.1 version of
the JDBC driver.  It might be worth a shot to try the 11.2.0.1 driver before
disabling statement batching.

-Jeremy

On Tue, Oct 13, 2009 at 9:39 AM, Michael Dick wrote:

> Hi Nick,
>
> It sounds like turning off SQL statement batching will help here's a link
> to
> the section in the manual :
>
> http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/manual.html#ref_guide_dbsetup_stmtbatch
>
> -mike
>
> On Tue, Oct 13, 2009 at 8:26 AM, nick_j_m...@uk.ibm.com <
> nick_j_m...@uk.ibm.com> wrote:
>
> >
> > Just retested this in oracle 10g and appears to be the same issue
> >
> > Oracle 10g R2 using ojdbc14.jar - 10.1.0.2.0
> >
> > Nick
> >
> >
> > nick_j_m...@uk.ibm.com wrote:
> > >
> > > Hi there
> > > While testing my app against oracle 11 g i discover this new error. I'm
> > > using openjpa 1.2.1
> > >
> > > I'm using the ojdbc5.jar - 11.1.0.6.0
> > >
> > > org.apache.openjpa.persistence.PersistenceException: operation not
> > > allowed: streams type cannot be used in batching
> > >
> > > this occuers when trying to insert to a table associated with a pojo
> that
> > > has a Lob annotation
> > >
> > > this works on sqlserver and with oracle 10g
> > >
> >
> > --
> > View this message in context:
> >
> http://n2.nabble.com/oracle-11g-operation-not-allowed-streams-type-cannot-be-used-in-batching-tp3816015p3816032.html
> > Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >
>

Re: StreamingLOB and Derby/Hsql

[Jeremy Bauer]

Rev 816287 corrected many of the Oracle failures, but at least one issue
remains for that platform.

-Jeremy

On Mon, Sep 21, 2009 at 2:35 PM, Donald Woods  wrote:

> After the focus on cleaning up failing junits on non-Derby databases this
> month, TestReaderLob is passing now on MySQL and only has one failure on
> Oracle, but still has 5 failures on MSSQL
>
> Not sure which svn check-in resolved it, as it could have been r816287 for
> Oracle or a number of the other test fixes by Fay to correct case sensitive
> column/table names or schema naming fixes
>
>
> -Donald
>
>
>
> Miłosz Tylenda wrote:
>
>> Hi Simone,
>>
>> OpenJPA currently supports (judging from test cases) streaming LOB with
>> MySQL, Oracle, PostgreSQL and SQL Server. However, even with these databases
>> there are bugs to fix. OPENJPA-1248 [1] contains a few stack traces some of
>> which are similar to yours. Thus the exception you are getting from a newer
>> Derby might be an OpenJPA fault.
>>
>> [1] https://issues.apache.org/jira/browse/OPENJPA-1248
>>
>> Regards,
>> Milosz
>>
>>  Hi all,
>>> I've been experimenting with the streaming LOB on Apache Derby and Hsql.
>>> I'm using OpenJPA 1.2.0.
>>>
>>> On Hsql, it is not supported because it does not support select for
>>> update.
>>>
>>> On Derby 10.1.2.1 (reported as supported in
>>> http://openjpa.apache.org/builds/1.2.0/apache-openjpa-1.2.0/docs/manual/manual.html#supported_databases)
>>> and up to 10.2.2.0 it does not work. An exception [1] is thrown when trying
>>> persisting.
>>>
>>> On Derby 10.4.1.3, 10.4.2.0, 10.3.2.1 it fails with an exception, but not
>>> when writing, during read operation [2]. Looking at derby source, seems like
>>> an IOException is thrown when stream value is null.
>>>
>>> The same application works perfectly on different versions of MySQL, both
>>> on windows and linux.
>>>
>>> Has anyone managed to have streaming lob working on Derby? Am I missing
>>> some configuration option?
>>>
>>> Simone
>>>
>>>
>>>
>>> [1]
>>> Caused by: SQL Exception: Feature not implemented: no details.
>>>at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
>>> Source)
>>>at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
>>> Source)
>>>at org.apache.derby.impl.jdbc.Util.notImplemented(Unknown Source)
>>>at org.apache.derby.impl.jdbc.EmbedBlob.setBinaryStream(Unknown
>>> Source)
>>>at
>>> org.apache.openjpa.jdbc.sql.DBDictionary.updateBlob(DBDictionary.java:4310)
>>>at
>>> org.apache.openjpa.jdbc.meta.strats.LobFieldStrategy.customInsert(LobFieldStrategy.java:112)
>>>at
>>> org.apache.openjpa.jdbc.meta.FieldMapping.customInsert(FieldMapping.java:701)
>>>at
>>> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager$CustomMapping.execute(AbstractUpdateManager.java:352)
>>>at
>>> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:94)
>>>
>>> [2]
>>> Caused by: java.io.IOException
>>>at
>>> org.apache.derby.iapi.services.io.NewByteArrayInputStream.read(Unknown
>>> Source)
>>>at java.io.InputStream.read(InputStream.java:85)
>>>
>>>
>>> --
>>> Simone GianniCEO Semeru s.r.l.   Apache Committer
>>> http://www.simonegianni.it/
>>>
>>>
>>>
>>

Re: metadata api?

[Jeremy Bauer]

Hi Chris,

OpenJPA provides APIs that allow you to interrogate class mappings.  Using a
direct approach (OpenJPA resolves class mapping and metadata as part of
creating an emf/em), this code gives you access to the primary and foreign
keys of an entity via the schema information stored in the mapping.

import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.jdbc.schema.Column;
import org.apache.openjpa.jdbc.schema.ForeignKey;
import org.apache.openjpa.jdbc.schema.PrimaryKey;
import org.apache.openjpa.persistence.JPAFacadeHelper;

...
EntityManager em = emf.createEntityManager();
ClassMapping clsMapping =
(ClassMapping)JPAFacadeHelper.getMetaData(em, SomeEntity.class);

ForeignKey[] fks = clsMapping.getTable().getForeignKeys();
PrimaryKey pk = clsMapping.getTable().getPrimaryKey();

hth,
-Jeremy

On Wed, Sep 9, 2009 at 3:31 AM, Christopher Giblin wrote:

>
> Hi,
> I defined object-relational mappings in orm.xml.  Works fine.
>
> Is an API available which allows querying of the orm definition for a given
> object? I am programming with reflection and would like to know, given an
> object, which of its attributes are primary or foreign keys.
>
> Thanks, chris
>
>

Re: ClassStrategy.

[Jeremy Bauer]

Hi Chris,

As you dive into creating custom strategies, besides reading the OpenJPA
docs, you may also want to check out this blog post[1] on the topic.

-Jeremy

[1]
http://webspherepersistence.blogspot.com/2009/04/custom-orm-with-openjpa.html

On Fri, Aug 7, 2009 at 2:43 AM, C N Davies  wrote:

>
>
> Looking at the docs there should be an interface named
> org.apache.openjpa.jdbc.meta.ClassStrategy  which needs to be implemented
> in
> order to implement a strategy for a custom class. But I cannot find the
> class in any of the OpenJPA 1.2.1 jars.  Is the document wrong or am I just
> stupid?
>
>
>
> Thanks J
>
>
>
> Chris
>
>
>
>

Re: OpenJPA and load timpe weaving

[Jeremy Bauer]

Hi Thierry,

I did not see this in the blog post that Kevin referred to, but it may be
helpful as well.  You can explicitly turn off
OpenJPA's subclassing-based enhancement by specifying this option in your
persistence.xml:

  

If your app is configured properly, classes (which are not pre-enhanced)
should get enhanced by the enhancer agent.  But, if there are those that are
not, subclassing will not occur and OpenJPA will throw an exception stating
that an entity was not enhanced.

hth,

-Jeremy

On Fri, Jul 31, 2009 at 8:17 AM, Kevin Sutter  wrote:

> Thierry,
> I would first reference this blog posting [1] on our Enhancement processing
> (load time weaving) and see if that helps answer your questions.  Or, at
> least it should help narrow the scope of the question...
>
> Thanks,
> Kevin
>
> [1]
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
>
> On Fri, Jul 31, 2009 at 4:36 AM, Thierry Templier 
> wrote:
>
> >
> > Hello,
> >
> > I'm using OpenJPA 1.1.0 and I wonder if it's possible to explicitly
> specify
> > that we want to load time weaving.
> >
> > Thanks for your help,
> > Thierry
> >
> >
> >
> >
>

Re: How to get database information

[Jeremy Bauer]

Martin,

The OpenJPAEntityManagerSPI interface provides a method to access the
underlying JDBC connection used by the em.  You can use that connection to
get db metadata information.  Depending on whether your application uses a
container or application managed em, you may need to call em.getDelegate()
to get the underlying OpenJPA entity manager implementation.  Otherwise,
you'll get a cast exception.  Here's an example:

OpenJPAEntityManagerSPI oem =
(OpenJPAEntityManagerSPI)em.getDelegate();
java.sql.Connection conn = (java.sql.Connection)
oem.getConnection();
java.sql.DatabaseMetaData dbmd = conn.getMetaData();
String dbProductName = dbmd.getDatabaseProductName();
String dbProductVersion = dbmd.getDatabaseProductVersion();
String dbURL = dbmd.getURL();

I ran this code in an app configured to use a data source and it returned
the JDBC URL configured for the data source.  You could potentially parse
the URL for the host system, database name, etc.  I don't recommend using
this connection for other SQL operations since it could end up in state not
suitable for use by OpenJPA.

hth,
-Jeremy

On Thu, Jul 9, 2009 at 9:35 AM, mjdenham  wrote:

>
> Hi,
>
> Is there an easy way to dynamically find the database name and schema name
> being used by an EntityManager at runtime?
>
> We are using OpenJpa 1.0.4 on Websphere and an Oracle datasource.
>
> We would like to make the information accessible on an application screen
> because we have so many environments - dev, test, uvt, uat, integration
> that
> it gets confusing to know which database a tester is using.
>
> Thanks
> Martin
> --
> View this message in context:
> http://n2.nabble.com/How-to-get-database-information-tp3231794p3231794.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>

Re: [VOTE] OpenJPA Logo Contest

[Jeremy Bauer]

First - 14
Second - 7
Third - 9

-Jeremy

On Thu, Jul 2, 2009 at 3:24 PM, Ravi Palacherla
wrote:

> First  - 15
> Second -  8
> Third - 9
>
> - Ravi.
>
> -Original Message-
> From: Donald Woods [mailto:dwo...@apache.org]
> Sent: Thursday, July 02, 2009 2:00 PM
> To: d...@openjpa.apache.org; users@openjpa.apache.org
> Cc: go...@oles.biz
> Subject: [VOTE] OpenJPA Logo Contest
>
> It's time to vote on your favorite logo!
>
> Anyone can vote for up to 3 logos and logo submitters can vote for their
> own logos. For example,
>
> First - #13
> Second - #15
> Third - #7
>
> Please include all of your votes in a single email reply to this thread
> and use the index on the wiki page to denote which entry you are voting
> on (1 - 15.)
>
>
> -Donald
>
>
> Donald Woods wrote:
> > Announcing the OpenJPA Logo Contest!
> >
> > Submissions: Accepted now through June 30, 2009
> > Rules and Guidelines: See the Logo Contest page [1] for more details.
> > Voting: Will occur from July 1 through July 14.
> > Winner: Will be announced on or after July 15.
> >
> > [1] http://cwiki.apache.org/openjpa/logo-contest.html
> >
> >
> > -Donald
> >
>

Re: Best practice to avoid duplicates on @Column(unique=true)

[Jeremy Bauer]

Hi Milosz,

Great observation & questions.  The sentence you refer to means that you can
directly invoke a JSR-303 validator at any time from the application.  ex:

javax.validation.ValidatorFactory factory =
Validation.buildDefaultValidatorFactory();
javax.validation.Validator validator = factory.getValidator();

EntityA a = em.find(EntityA.class, "IdOfA");

Set> cvs = validator.validate(a);

I've only briefly read over how one may create and tie a constraint
validator implementation class to a custom constraint, but I don't see an
immediate way that the constraint validator could get access (outside of
some static helper method) to an em during the validation process.  That
said, I did not read anything in the specs (but, I could easily have missed
something) that would prevent the constraint validator from accessing an em
during application driven validation... so it could potentially be used
during that process.  Care would need to be taken not to cause unintended
side-effects (locks, loading, tx commit/rollback, etc.).

One more thing to keep in mind, application driven validation also requires
a JPA traversable resolver to prevent from validating unloaded or related
entities.  OpenJPA does not provide a resolver, but the plan is to provide
one in a future iteration of 2.0.  Until that is available, validating of
unloaded and related entities (if tagged with @Valid) will occur.

BTW, This scenario will make a great set of test cases.  :-)

-Jeremy


On Mon, Jun 22, 2009 at 12:59 PM, Miłosz Tylenda  wrote:

> Jeremy,
>
> Thanks for the explanation. Maybe you could also explain this sentence from
> the spec:
>
> "Validation can also be achieved by the application calling the validate
> method of a validator
> instance upon an instance of a managed class, as described in the Bean
> Validation specification [8]"
>
> Does it mean we can call validate at whatever time in the persistence
> context? Can we access entity manager then?
>
> Greetings,
> Milosz
>
>
> > David & Milosz,
> >
> > Based on the information provided, I do not think Bean Validation would
> > provide a good solution for this problem.  Used within the context of
> JPA,
> > bean validation gets called when various lifecycle events occur;
> > pre-persist, pre-remove, pre-update.  In order to create a custom
> validation
> > constraint, you'd likely need to invoke some database operations (likely
> > some variant of the query Craig suggested).  Regarding the use of em &
> query
> > operations inside lifecycle events JPA specification states:
> >
> >
> > In general, the lifecycle method of a portable application should not
> invoke
> > EntityManager
> > or Query operations, access other entity instances, or modify
> relationships
> > within the
> > same persistence context.[38] A lifecycle callback method may modify the
> > non-relationship
> > state of the entity on which it is invoked.
> >
> >
> > So using database operations, at least within the same persistence
> context,
> > probably isn't a good idea.  Regardless, I think the net result would be
> > that, application-wise, you'd be back in the nearly same situation as
> > present.  The exception would still occur on the persist, the main
> > difference would be that the exception would be coming from the validator
> > instead of the failed database operation.
> >
> > -Jeremy
> >
> > On Sat, Jun 20, 2009 at 3:30 AM, Miłosz Tylenda  wrote:
> >
> > > David,
> > >
> > > Apart from what Craig has suggested, what came to my mind is that there
> is
> > > an ongoing effort to implement JSR-303 Bean Validation in OpenJPA 2.0.
> Not
> > > sure however, whether it is sufficiently implemented yet and it can be
> used
> > > for your purpose. Might be worth checking though.
> > >
> > > Cheers,
> > > Milosz
> > >
> > > > I realise that this is not strickly an OpenJPA problem, rather a more
> > > > general JPA one, but there are experts here who might know the
> answer.
> > > >
> > > > I have a number of classes which represent tables which have not only
> > > > an Id field, but also various other fields which are marked as
> unique.
> > > >
> > > > When I persist and then try to flush a new object which has a
> non-unique
> > > > value in the object (the user entered bad data) it breaks the
> transaction
> > > > and throws an error.  All of which is quite understandable.
> > > >
> > > > The question is what is the best way to avoid it.  Do I have to build
> the
> > > > checking into the application, or is there a more generic way which I
> > > > can use as a validation technique before I try to persist the object.
> > > >
> > > > David
> > > >
> > >
> >
>

Re: Best practice to avoid duplicates on @Column(unique=true)

[Jeremy Bauer]

David & Milosz,

Based on the information provided, I do not think Bean Validation would
provide a good solution for this problem.  Used within the context of JPA,
bean validation gets called when various lifecycle events occur;
pre-persist, pre-remove, pre-update.  In order to create a custom validation
constraint, you'd likely need to invoke some database operations (likely
some variant of the query Craig suggested).  Regarding the use of em & query
operations inside lifecycle events JPA specification states:


In general, the lifecycle method of a portable application should not invoke
EntityManager
or Query operations, access other entity instances, or modify relationships
within the
same persistence context.[38] A lifecycle callback method may modify the
non-relationship
state of the entity on which it is invoked.


So using database operations, at least within the same persistence context,
probably isn't a good idea.  Regardless, I think the net result would be
that, application-wise, you'd be back in the nearly same situation as
present.  The exception would still occur on the persist, the main
difference would be that the exception would be coming from the validator
instead of the failed database operation.

-Jeremy

On Sat, Jun 20, 2009 at 3:30 AM, Miłosz Tylenda  wrote:

> David,
>
> Apart from what Craig has suggested, what came to my mind is that there is
> an ongoing effort to implement JSR-303 Bean Validation in OpenJPA 2.0. Not
> sure however, whether it is sufficiently implemented yet and it can be used
> for your purpose. Might be worth checking though.
>
> Cheers,
> Milosz
>
> > I realise that this is not strickly an OpenJPA problem, rather a more
> > general JPA one, but there are experts here who might know the answer.
> >
> > I have a number of classes which represent tables which have not only
> > an Id field, but also various other fields which are marked as unique.
> >
> > When I persist and then try to flush a new object which has a non-unique
> > value in the object (the user entered bad data) it breaks the transaction
> > and throws an error.  All of which is quite understandable.
> >
> > The question is what is the best way to avoid it.  Do I have to build the
> > checking into the application, or is there a more generic way which I
> > can use as a validation technique before I try to persist the object.
> >
> > David
> >
>

Re: OpenJPA-2.0.0-snapshot Question with @ManyToMany

[Jeremy Bauer]

Open Gloves,

Apologies.  I did not verify that the insert into the collection actually
took place.  After re-running the test, paying close attention to the trace
output, I found the source of the problem.  During entity enhancement
several warnings were logged of this form:

1656  sample  WARN   [main] openjpa.Enhance - Detected the following
possible violations of the restrictions placed on property access persistent
types:
"entities.Student" uses property access, but its field "teachers" is
accessed directly in method "removeTeacher" defined in "entities.Student".

In short, non-persistent methods in Teacher and Student are accessing fields
directly instead of calling the persistent property methods.  In order for
OpenJPA to effectively track changes in the persistent properties they must
be accessed instead of the fields.  Modifying the addTeacher and
removeTeacher methods as below corrected the problem.

   public void addTeacher(Teacher teacher) {
   if (getTeachers() == null)
   setTeachers(new HashSet());
   getTeachers().add(teacher);
   }
   public void removeTeacher(Teacher teacher) {
   if (getTeachers().contains(teacher)) {
   getTeachers().remove(teacher);
   }
   }

This looks to be another implementation difference between OpenJPA and
Hibernate.

-Jeremy


On Tue, Jun 2, 2009 at 12:51 AM, opengloves  wrote:

>
> Hi,
> Thanks for your response.
> I hardcoded is just for test @ManyToMany and see the effect.
> @GeneratedValue
> is not the point of this issue.
> I also do not think this is the bug of OpenJPA, and I had been modified the
> code like your advice before, and It didn't passed test either. because the
> test code is passed, but it didn't do the right thing because the data is
> not insert into the table STUDENT_TEACHER, this is strange, and I also test
> the hibernate without if block and it works, and I tested the method
> testPersistJoinTable() twice and the table is also contain one record. and
> this is good, this is the META-INF/persistence.xml about hibernate
> 
>
>  org.sample.demo.jpa.entity.manytomany.Student
>org.sample.demo.jpa.entity.manytomany.Teacher
>
>  value="org.hibernate.dialect.DerbyDialect"/>
> value="jdbc:derby://localhost:1527/sample;create=true" />
>  value="org.apache.derby.jdbc.ClientDriver" />
>  value="user" />
> value="secret" />
> value="update"/>
>
>
> Jar Environment: antlr-2.7.6, commons-collections-3.1, dom4j-1.6.1,
> ejb3-persistence, hibernate3, hibernate-annotations,
> hibernate-cglib-repack-2.1_3, hibernate-commons-annotations,
> hibernate-entitymanager, javassist-3.4.GA, jta-1.1, log4j-1.2.15,
> slf4j-api-1.5.2, slf4j-log4j12-1.5.0.
> Other environment and codes are the same.(Student.java, Teacher.java,
> ManyToManyTest.java are the same)
>
> After modified the code, I think this is strange: the test is passed and
> the
> data is not insert into the table.
> And I come here, find help. Or maybe this is a bug?
> I think add this if block is the provider dependence, maybe.
>
> --
> Thanks
> Open Gloves
>
>
> Jeremy Bauer wrote:
> >
> > Hi,
> >
> > Interesting that this works on Hibernate.  The first potential issue I
> > found
> > in the test is that it uses a hardcoded id and your entities are
> annotated
> > with @GeneratedValue.  Depending on how the value is generated, the
> values
> > could be different between test runs and providers.  Storing away the id
> > of
> > the persisted entities (in static fields, for example) is a safer and
> more
> > consistent way to make sure the test accesses the same entities in future
> > test variations.
> >
> > The NPE is the result of the student.teachers collection being null.
> > While
> > the class contains code to set it to new HashSet upon construction,
> > OpenJPA
> > sets it to null after the find operation - since the set did not contain
> > any
> > elements when Student was persisted.  Modifying the addTeacher method as
> > below corrected the NPE and the test passed.
> >
> >public void addTeacher(Teacher teacher) {
> >if (teachers == null)
> >teachers = new HashSet();
> >this.teachers.add(teacher);
> >}
> >
> > Based on the behavior I've seen, I do not think this is a bug in OpenJPA.
> > While I haven't tested with Hibernate, I suspect it is just a difference
> > in
> > how empty/null collections are stored and initialized by each provider.
> >
> > hth,
> > -Jeremy
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/OpenJPA-2.0.0-snapshot-Question-with-%40ManyToMany-tp3006387p3010520.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>

Re: OpenJPA-2.0.0-snapshot Question with @ManyToMany

[Jeremy Bauer]

Hi,

Interesting that this works on Hibernate.  The first potential issue I found
in the test is that it uses a hardcoded id and your entities are annotated
with @GeneratedValue.  Depending on how the value is generated, the values
could be different between test runs and providers.  Storing away the id of
the persisted entities (in static fields, for example) is a safer and more
consistent way to make sure the test accesses the same entities in future
test variations.

The NPE is the result of the student.teachers collection being null.  While
the class contains code to set it to new HashSet upon construction, OpenJPA
sets it to null after the find operation - since the set did not contain any
elements when Student was persisted.  Modifying the addTeacher method as
below corrected the NPE and the test passed.

   public void addTeacher(Teacher teacher) {
   if (teachers == null)
   teachers = new HashSet();
   this.teachers.add(teacher);
   }

Based on the behavior I've seen, I do not think this is a bug in OpenJPA.
While I haven't tested with Hibernate, I suspect it is just a difference in
how empty/null collections are stored and initialized by each provider.

hth,
-Jeremy

On Mon, Jun 1, 2009 at 9:03 AM, opengloves  wrote:

>
> IDE Environment: Eclipse-3.4
> DB Environment: Apache-Derby-10.5.1.1
> JDK Environment: Sun JDK-1.6.0_07
> Jar Environment: from
>
> http://openjpa.apache.org/builds/latest/downloads/apache-openjpa-2.0.0-SNAPSHOT-binary.zip
> Eclipse PlugIn Environment:Apache-Derby, JUnit4
>
> I want to test the @ManyToMany(the example is Teacher and Student, many to
> many)
>
> The code is this:
> Student.java
> @Entity
> public class Student {
>private int id;
>private String name;
>private Set teachers = new HashSet();
>@Id
>@GeneratedValue
>public int getId() {
>return id;
>}
>public void setId(int id) {
>this.id = id;
>}
>@Column(length = 10, nullable = false)
>public String getName() {
>return name;
>}
>public void setName(String name) {
>this.name = name;
>}
>@ManyToMany(cascade = { CascadeType.REFRESH })
>@JoinTable(
>name = "STUDENT_TEACHER",
>inverseJoinColumns = @JoinColumn(name = "TEACHER_ID"),
>joinColumns = @JoinColumn(name = "STUDENT_ID")
>)
>public Set getTeachers() {
>return teachers;
>}
>public void setTeachers(Set teachers) {
>this.teachers = teachers;
>}
>public void addTeacher(Teacher teacher) {
>this.teachers.add(teacher);
>}
>public void removeTeacher(Teacher teacher) {
>if (this.teachers.contains(teacher)) {
>this.teachers.remove(teacher);
>}
>}
> }
> Teacher.java
> @Entity
> public class Teacher {
>private int id;
>private String name;
>private Set students = new HashSet();
>@Id
>@GeneratedValue
>public int getId() {
>return id;
>}
>public void setId(int id) {
>this.id = id;
>}
>@Column(length=10, nullable=false)
>public String getName() {
>return name;
>}
>public void setName(String name) {
>this.name = name;
>}
>@ManyToMany(cascade={CascadeType.REFRESH}, mappedBy="teachers" )
>public Set getStudents() {
>return students;
>}
>public void setStudents(Set students) {
>this.students = students;
>}
>@Override
>public int hashCode() {
>final int prime = 31;
>int result = 1;
>result = prime * result + id;
>return result;
>}
>@Override
>public boolean equals(Object obj) {
>if (this == obj)
>return true;
>if (obj == null)
>return false;
>if (getClass() != obj.getClass())
>return false;
>Teacher other = (Teacher) obj;
>if (id != other.id)
>return false;
>return true;
>}
> }
> ManyToManyTest.java
> public class ManyToManyTest {
>@Test
>public void testPersist(){
>EntityManagerFactory emf =
> Persistence.createEntityManagerFactory("sample");
>EntityManager em = emf.createEntityManager();
>EntityTransaction et = em.getTransaction();
>et.begin();
>Student student = new Student();
>student.setName("student1");
>Teacher teacher = new Teacher();
>teacher.setNa

Re: correct way to load persistent metadata at startup

[Jeremy Bauer]

Heather,

Have you looked into creating a custom sequence generator[1]?  Within the
generator, the persistent class and/or fields could be interrogated for
annotations and you could generate a value based on them.  This is more of a
runtime vs. init-time solution, though.

Here's an example:

package generator;

import java.lang.reflect.AccessibleObject;

import org.apache.openjpa.jdbc.conf.JDBCConfiguration;
import org.apache.openjpa.jdbc.kernel.JDBCStore;
import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.meta.FieldMetaData;

public class MyGenerator extends
org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq
{
@Override
public JDBCConfiguration getConfiguration() {
return null;
}

@Override
protected Object nextInternal(JDBCStore arg0, ClassMapping arg1)
throws Exception {

FieldMetaData fmd = arg1.getFieldMapping("someField");
AccessibleObject fld = (AccessibleObject)fmd.getBackingMember();
MyAnnotation anno =
(MyAnnotation)fld.getAnnotation(MyAnnotation.class);
// Return the value of the annotation.  This will get persisted in
the DB column.
return anno.value();
}
}


@Entity
@SequenceGenerator(name="myGenerator",
sequenceName="generator.MyGenerator()")
public class GenValue {

@MyAnnotation("FieldValue")
@GeneratedValue(generator="myGenerator",
strategy=GenerationType.SEQUENCE)
public String someField;

...
}

[1]
http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_sequence.html

-Jeremy

On Fri, May 15, 2009 at 2:06 PM, Kevin Sutter  wrote:

> Hi Heather,
> Interesting use of the OpenJPA metadata processing.  Just from your brief
> description, I would be careful on depending on an implementation versus
> defined interfaces.  Even if we could get this initialization done earlier
> for you, unless there was some defined mechanism to force this (ie. the
> openjpa.InitializeEagerly property), I wouldn't count on it.  In this
> particular case, the metadata repository is meant for OpenJPA processing.
>
> I know with OpenJPA the lines may not be crystal clear between public
> API's,
> provider SPI's, or internal classes.  Of course, since this is an
> open-source project, you are welcome to peruse the complete contents of the
> code base and see if a solution is doable or not.  I would just be careful
> on being too dependent on a specific implementation.
>
> Kevin
>
> On Fri, May 15, 2009 at 9:30 AM, Heather Sterling 
> wrote:
>
> > Thanks Kevin.
> >
> > Our scenario is that we have added product-specific annotations to the
> > persistent classes. In particular, we have some annotations that we need
> in
> > our perPersist entity listener to generate unique identifiers before the
> > object is persisted. We're currently initializing all of the metadata at
> the
> > beginning. We essentially iterate through the persistent classes and
> create
> > maps that hold this extra information. I guess it's possible for us to
> > lazily load this data in the entity listener if it hasn't been loaded for
> a
> > particular class. I also looked to see if there was another hook we could
> > potentially use, but didn't see any that seemed to fit the problem.
> >
> >
> > Heather Sterling
> > Systems Management Development
> > Phone: 919-254-7163 T/L: 444-7163
> > Cell: 919-423-3143
> > Email: hst...@us.ibm.com
> >
> >
> > [image: Inactive hide details for Kevin Sutter ---05/12/2009 12:53:30
> > PM---Heather,]
> > Kevin Sutter ---05/12/2009 12:53:30 PM---Heather,
> >
> >
> >
> >
> > *Kevin Sutter *
> >
> > 05/12/2009 12:48 PM
> > Please respond to users
> >
> >
> >
> >  To: users@openjpa.apache.org
> >  cc:
> >  Subject: Re: correct way to load persistent metadata at startup
> >
> >
> > Heather,
> > Good question...  :-)  This topic has come up recently due to some
> > potential
> > locking issues (serialized access) when reading the metadata repository
> in
> > a
> > multi-threaded environment.  At this point, there is not a clear cut
> answer
> > for forcing the initialization of the metadata repository.  The code for
> > the
> > new openjpa.InitializeEagerly property was committed to trunk last August
> > (after the 1.2.0 release was created), but we've since determined that it
> > may not be complete for all cases.  You are welcome to try it out from
> > either the 1.3.x or trunk branches and see if it helps in your particular
> > situation.
> >
> > Let us know what you find out.  Also, can you explain your need for
> getting
> > this data eagerly vs letting the lazy loading process play out?  Thanks!
> >
> > Kevin
> >
> >
> >
> > On Mon, May 11, 2009 at 2:40 PM, Heather Sterling 
> > wrote:
> >
> > >
> > >
> > > I am attempting to load all the persistent class metadata eagerly.  I
> > > realize this isn't great performance-wise, but I need to do it for the
> > > time-being.   I had wanted to call:
> > >
> > >ClassMetaData[] classMetaDatas =
> > > conf.getMe

Re: Can't query against a MappedSuperclass

[Jeremy Bauer]

Hi Fay,

The JPA 1.0 and 2.0 draft spec clearly state that this isn't a requirement
of JPA, but a note in the OpenJPA documentation (section 1.3) seems to
indicate that OpenJPA does support it as an OpenJPA extension.



Unlike true entities, you cannot query a mapped superclass, pass a mapped
superclass instance to any EntityManager or Query methods, or declare a
persistent relation with a mapped superclass target.

...then
Note

OpenJPA allows you to query on mapped superclasses. A query on a mapped
superclass will return all matching subclass instances. OpenJPA also allows
you to declare relations to mapped superclass types; however, you cannot
query across these relations.


Using a mapped superclass with the em.find() operation over very simple
entity subclasses seemed to work fine, but JPQL queries do not.

-Jeremy

On Tue, Apr 21, 2009 at 11:32 AM, Fay Wang  wrote:

>
> Just found that in JPA 2.0 Proposed Final Draft (March 13, 2009):
>
> Spec 2.11.2:
> A mapped superclass, unlike an entity, is not queryable and cannot be
> passed as an argument to EntityManager or Query operations.
>
>
> --- On Tue, 4/21/09, Jeremy Bauer  wrote:
>
> > From: Jeremy Bauer 
> > Subject: Re: Can't query against a MappedSuperclass
> > To: users@openjpa.apache.org
> > Date: Tuesday, April 21, 2009, 8:52 AM
> > Hi Jim,
> >
> > It looks like there are inconsistencies in the manual and
> > provider.  I was
> > able use the em.find() operation with a mapped superclass,
> > but could not run
> > a JPQL query which used one.  To perform the find
> > operation, OpenJPA queried
> > known entity subclasses of the mapped superclass until it
> > found one that
> > matched the specified ID.  I tried using mapped
> > superclasses with the base
> > 1.0 release to make sure this capability hadn't regressed
> > and 1.0 behaved
> > the same. So, it doesn't look like this ever worked with
> > JPQL.
> >
> > Have you taken a look at using entity enheritance and the
> > various entity
> > inheritance strategies?  The TABLE_PER_CLASS strategy
> > may map fairly well to
> > a domain model that currently uses mapped superclass over
> > multiple disparate
> > entities.  It provides query capabilities over the
> > superclass entity type.
> >
> > I've opened JIRA OPENJPA-1043[1] for this issue.
> > Minimally, the docs should
> > be updated to reflect that mapped superclasses are only
> > supported on a find
> > until such a time they can be supported in a query.
> >
> > -Jeremy
> >
> > [1] https://issues.apache.org/jira/browse/OPENJPA-1043
> >
> > On Mon, Apr 20, 2009 at 4:33 PM, Fay Wang 
> > wrote:
> >
> > >
> > > Hi,
> > > According to openjpa manual:
> > >
> > > "Unlike true entities, you cannot query a mapped
> > superclass"
> > >
> > >
> > >
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#jpa_overview_meta_embeddablesuper
> > >
> > >
> > >
> > > --- On Mon, 4/20/09, jim weaver 
> > wrote:
> > >
> > > > From: jim weaver 
> > > > Subject: Can't query against a MappedSuperclass
> > > > To: users@openjpa.apache.org
> > > > Date: Monday, April 20, 2009, 12:38 PM
> > > >
> > > > I have the following:
> > > >
> > > > @MappedSuperclass class A { }
> > > > @Entity class B extends A { }
> > > > @Entity class C extends A { }
> > > >
> > > > and I try to do this type of query: SELECT a FROM
> > A a
> > > >
> > > > I receive error message "An error occurred while
> > parsing
> > > > the query filter
> > > > "SELECT a FROM A a".  Error
> > > > message:   The name "A" is not a
> > recognized
> > > > entity or identifier.  Perhaps you meant B,
> > which is a
> > > > close match.  Known
> > > > entity names: [B, C]"
> > > >
> > > > A is defined in my persistence.xml and my tables
> > do have
> > > > the inherited
> > > > fields from it so I'm pretty sure jpa is
> > recognizing it.
> > > >
> > > > The OpenJPA doc says that the query is
> > supported.this
> > > > is from the 1.2.0
> > > > doc:
> > > >
> > > > Note
> > > > OpenJPA allows you to query on mapped
> > superclasses. A query
> > > > on a mapped
> > > > superclass will return all matching subclass
> > instances.
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > >
> http://n2.nabble.com/Can%27t-query-against-a-MappedSuperclass-tp2665700p2665700.html
> > > > Sent from the OpenJPA Users mailing list archive
> > at
> > > > Nabble.com.
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
>
>
>

Re: Can't query against a MappedSuperclass

[Jeremy Bauer]

Hi Jim,

It looks like there are inconsistencies in the manual and provider.  I was
able use the em.find() operation with a mapped superclass, but could not run
a JPQL query which used one.  To perform the find operation, OpenJPA queried
known entity subclasses of the mapped superclass until it found one that
matched the specified ID.  I tried using mapped superclasses with the base
1.0 release to make sure this capability hadn't regressed and 1.0 behaved
the same. So, it doesn't look like this ever worked with JPQL.

Have you taken a look at using entity enheritance and the various entity
inheritance strategies?  The TABLE_PER_CLASS strategy may map fairly well to
a domain model that currently uses mapped superclass over multiple disparate
entities.  It provides query capabilities over the superclass entity type.

I've opened JIRA OPENJPA-1043[1] for this issue.  Minimally, the docs should
be updated to reflect that mapped superclasses are only supported on a find
until such a time they can be supported in a query.

-Jeremy

[1] https://issues.apache.org/jira/browse/OPENJPA-1043

On Mon, Apr 20, 2009 at 4:33 PM, Fay Wang  wrote:

>
> Hi,
> According to openjpa manual:
>
> "Unlike true entities, you cannot query a mapped superclass"
>
>
> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#jpa_overview_meta_embeddablesuper
>
>
>
> --- On Mon, 4/20/09, jim weaver  wrote:
>
> > From: jim weaver 
> > Subject: Can't query against a MappedSuperclass
> > To: users@openjpa.apache.org
> > Date: Monday, April 20, 2009, 12:38 PM
> >
> > I have the following:
> >
> > @MappedSuperclass class A { }
> > @Entity class B extends A { }
> > @Entity class C extends A { }
> >
> > and I try to do this type of query: SELECT a FROM A a
> >
> > I receive error message "An error occurred while parsing
> > the query filter
> > "SELECT a FROM A a".  Error
> > message:   The name "A" is not a recognized
> > entity or identifier.  Perhaps you meant B, which is a
> > close match.  Known
> > entity names: [B, C]"
> >
> > A is defined in my persistence.xml and my tables do have
> > the inherited
> > fields from it so I'm pretty sure jpa is recognizing it.
> >
> > The OpenJPA doc says that the query is supported.this
> > is from the 1.2.0
> > doc:
> >
> > Note
> > OpenJPA allows you to query on mapped superclasses. A query
> > on a mapped
> > superclass will return all matching subclass instances.
> >
> >
> > --
> > View this message in context:
> http://n2.nabble.com/Can%27t-query-against-a-MappedSuperclass-tp2665700p2665700.html
> > Sent from the OpenJPA Users mailing list archive at
> > Nabble.com.
> >
> >
>
>
>
>

Re: support for persisting primitive arrays

[Jeremy Bauer]

Hi Heather,

OpenJPA supports persisting primitive arrays, but IIRC, you must either:

a) Annotate your primitive array with @Lob.  The array will get stored as a
serialized bytes in the database (and deserialized when retrieved).  ex:

@Lob
double[] mDoubleArray;

b) Use the OpenJPA @org.apache.openjpa.persistence.PersistentCollection
annotation.  This will result in the primitive array being stored in a
separate table in the database.  JPA 2.0 has an equivalent annotation
@ElementCollection, so switching from an OpenJPA specific annotation to
standard JPA annotation will be straight forward when moving from OpenJPA
1.2 to OpenJPA 2.0 if/when you choose to do so.  Arguably, this is a cleaner
approach since it uses typed columns in the database vs. serialized bytes.
However, using lobs may prove to perform better.  If you want the array to
retain to proper order use the @OrderColumn annotation as well.ex:

@PersistentCollection
@OrderColumn
double[] myDoubleArray;

It appears that OpenJPA treats an array of primitive wrappers (Double[]) as
if it were tagged as a Lob.  Perhaps we should be doing the same with arrays
of primitives?

hth,
-Jeremy

On Fri, Apr 10, 2009 at 3:45 PM, Heather Sterling  wrote:

>
>
> I am trying to understand whether OpenJPA supports primitive arrays or not.
> I am able to persist arrays just fine if they are primitive wrapper classes
> ( e.g. Double[]).  However,  I get the following exception for primitive
> arrays (e.g. double[]):
>
> 
> org.apache.openjpa.util.MetaDataException: The type of field
>
> "com.ibm.sysmgmt.resource.caching.jpa.test.entities.PropertyTestElement.mDoubleArray"
>  isn't supported by declared persistence strategy "Basic".  Please choose a
> different strategy.
>  at
>
> org.apache.openjpa.persistence.AnnotationPersistenceMetaDataParser.parseBasic
> (
> AnnotationPersistenceMetaDataParser.java:1264)
>
> The OpenJPA manual claims the following::
>
> OpenJPA also supports arrays, java.lang.Number, java.util.Locale, all JDK
> 1.2 Set, List, and Map
> types, and many other mutable and immutable field types. OpenJPA also
> allows you to plug in support for custom types.
>
> 1) Are primitive arrays supported?  If so, what strategy should be used
> besides Basic?
> 2) Should I use the wrapper classes when persisting arrays?
>
> Thanks
>
> Heather Sterling
> Systems Management Development
> Phone:  919-254-7163 T/L: 444-7163
> Cell: 919-423-3143
> Email: hst...@us.ibm.com

Re: Could I generate ID without the OPENJPA_SEQUENCE_TABLE table?

[Jeremy Bauer]

Are you constrained to using an integral column type for the ID?  If not,
another option may be to use an OpenJPA UUID-based generator[1] with a
string id column.  These generators create a value within OpenJPA provider
and have no database-specific dependencies. For example:

...
@Id
@GeneratedValue(generator="uuid-hex")
private String id;
...

[1]
http://openjpa.apache.org/builds/latest/docs/manual/jpa_overview_meta_field.html#jpa_overview_meta_gen

-Jeremy


2009/3/31 Michael Dick 

> Hi,
>
> Disclosure I'm not an expert on SQLServer, and I don't have access to a
> SQLServer instance to test with at the moment.
>
> It looks like SQLServer doesn't support sequences but there are some
> alternatives besides an IDENTITY column [1]. From a JPA standpoint I think
> you'd annotate the field in the same manner as you would when using
> IDENTITY
> though.
>
> [1]
>
> http://www.sqljunkies.ddj.com/Article/4067A1B1-C31C-4EAF-86C3-80513451FC03.scuk
>
> OTOH this is probably the same thing you're trying to avoid by not having
> IDENTITY columns. If that's the case then you'll have to generate a table
> (similar to OPENJPA_SEQUENCE_TABLE) or manually manage the primary key
> column in your app.
>
> Hope this helps,
> -mike
>
> 2009/3/29 乔木 
>
> > SQL Server (without IDENTITY Column)
> >
> > 2009/3/29 Paul Copeland 
> >
> > > Your alternatives depend on the database you are using. What database?
> > >
> > > On 3/28/2009 6:24 PM, 乔木 wrote:
> > > > I don't want openjpa to create that table
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Best wishes,
> > 乔木
> > MOE KLINNS Lab and SKLMS Lab, Xi'an Jiaotong University
> > Department of Computer Science and Technology, Xi’an Jiaotong University
> > TEL: 15991676983
> > E-mail: qiao...@gmail.com
> >
>

Re: how to store collection of enums as strings

[Jeremy Bauer]

Craig,

The latest public draft (3/13/2009) of the JPA 2.0 specification defines the
ability to apply the Enumeration (also Temporal and Lob) annotation to
element collection.  Support within OpenJPA trunk will follow in the weeks
to come.

-Jeremy

On Tue, Mar 31, 2009 at 12:04 PM, Craig L Russell wrote:

> I'd like to see a simple way to persist an EnumSet (which if I understand
> this use case is really what is desired):
>
> @Enumerated(STRING)
> @ElementCollection
> private EnumSet myEnums = new EnumSet();
>
> If no volunteers to implement this one (too bad it's not in the
> specification) then this would be my second choice:
>
> @Enumerated(STRING)
> @ElementCollection
> private Set myEnums = new HashSet();
>
> The @Enumerated tells us that you want the String value of the enum to be
> persisted (not the int value); the @ElementCollection tells us to persist
> the values individually and not as a serialized blob.
>
> Craig
>
>
> On Mar 31, 2009, at 8:46 AM, Jody Grassel wrote:
>
>  It sounds like you're trying to persist a collection of enumerations as a
>> set of data and not as a reference to other entities, is that correct?
>>
>> If so, wouldn't a combination of @PersistentCollection and Externalization
>> (section 6.6 in the manual) provide the function you are looking for?
>>
>>
>> On Wed, Mar 25, 2009 at 11:48 AM, Tedman Leung  wrote:
>>
>>  Anyone know how to store a collection of enums as Strings instead of
>>> their
>>> ordinal values? (preferably with annotations...)
>>>
>>> i.e.
>>>  @ManyToMany
>>>  private Set myEnums=new HashSet();
>>>
>>>
>>> --
>>> Ted Leung
>>> ted...@sfu.ca
>>>
>>> It's time for a new bike when the bulb in your shift light burns out.
>>>
>>>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:craig.russ...@sun.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Is JPA 2 going to have something like JAXBs @XmlJavaTypeAdapter ?

[Jeremy Bauer]

Ryan,

I agree, this would be a useful feature to have standardized by the JPA
specification.  My guess is that it would be too late to try to get
something into JPA 2.0, but one could recommend this feature for inclusion
in a future version of the spec.  Pinaki and Kevin (cc'd) participate in the
expert group so they may have recommendations for submitting feature
requests.

Currently, you can do the conversion yourself within your business logic (or
create separate entities or embeddables for the mappings), which can result
in an indirect and sometimes quirky OR mapping..  or you can use OpenJPA's
@Strategy extension to specify a custom value mapping handler. Here is an
example handler for UUID:

package strat;

import java.util.UUID;

import org.apache.openjpa.jdbc.kernel.JDBCStore;
import org.apache.openjpa.jdbc.meta.ValueMapping;
import org.apache.openjpa.jdbc.meta.strats.AbstractValueHandler;
import org.apache.openjpa.jdbc.schema.Column;
import org.apache.openjpa.jdbc.schema.ColumnIO;
import org.apache.openjpa.meta.JavaTypes;

public class UUIDValueHandler extends AbstractValueHandler {

public Column[] map(ValueMapping vm, String name, ColumnIO io,
boolean adapt) {
Column col = new Column();
col.setName(name);
col.setJavaType(JavaTypes.STRING);
return new Column[]{ col };
}

public boolean isVersionable() {
return true;
}

/**
 * Convert the object value to its datastore equivalent.
 */
public Object toDataStoreValue(ValueMapping vm, Object val,
JDBCStore store) {
if (val == null)
return null;

UUID uuid = (UUID) val;
return uuid.toString();
}

/**
 *  Convert the datastore value to its object equivalent.
 */
public Object toObjectValue(ValueMapping vm, Object val) {
if (val == null)
return null;

String uuidStr = (String)val;
return UUID.fromString(uuidStr);
}
}

@Entity
public class EntityA {
...
@Strategy("strat.UUIDValueHandler")
private UUID uuid;
...
}

Using this custom value handler, UUID will be mapped internally to/from a
string type. In addition, the schema factory (if used) will create the
appropriate database column type(s).  The OpenJPA unit test suite has an
additional example usage of @Strategy which maps an object to/from multiple
database columns.  Search for @Strategy in
org.apache.openjpa.persistence.jdbc.annotations.NonstandardMappingEntity.

hth,
-Jeremy


On Mon, Mar 30, 2009 at 9:28 AM, Ryan Fogarty
wrote:

> I use @XmlJavaTypeAdapter a lot to manipulate our data model for classes
> that just don't naturally fit into an XML model (like custom containers
> and the sort). Seems to be one of the most intuitive and powerful tools
> in JAXBs toolbox but I can't find anything like it in JPA 1 or 2.
>
> For instance, I can't seem to do the simplest thing with JPA such as
> take a java.util.UUID and have OpenJPA map it into a STRING.
>
> It looks like there is no chance of getting this into JPA 2 since they
> are in final draft. I just can't imagine such a useful tool *not*
> existing in a powerful API like JPA, so what gives? Have I missed
> something fundamental?
>
> Thank you,
> Ryan
>
>
>

Re: Questions about classpath for OpenJPA

[Jeremy Bauer]

Hi Paul,

For Tomcat related information, you may be able to derive some information
from this thread [1].  It began as a data source related issue but got into
some configuration issues as well.

I've only used Tomcat 5.5 with OpenJPA.  I'm not sure about Tomcat 6, but
5.5 did not come with geronimo spec api jars (or equivalents).  Here are the
OpenJPA bundled jars that I needed to copy into the tomcat/common/lib
directory:

- openjpa-1.2.0.jar
- serp-1.13.1.jar
- geronimo-jta_1.1_spec-1.1.jar
- geronimo-jpa_3.0_spec-1.0.jar
- commons-collections-3.2.jar
- commons-lang-2.1.jar

You'll also need to make your JDBC driver jar(s) available to your app(s).
I added them to common/lib.  You may also be able to bundle all these jars
in your WAR, but I found it cleaner to make them common libs.

You may choose to use JNDI data sources with Tomcat vs. direct
configuration.  Here is a an article for configuring pooled data sources
with Tomcat.[2]  Until you make the jump to Tomcat, here is a link for
configuring pooled datasources with OpenJPA in a JSE environment using
dbcp.[3]

JRE 1.5.0_05 is fairly old.  I'd try updating to a newer JRE.  I'm currently
using 1.5.0_15.  Just a guess, but something may be relying on parser
related updates in newer versions of the JRE.

[1]
http://n2.nabble.com/Using-datasource-from-tomcat-with-openjpa-tt1449575.html#a1449832

[2]
http://www.onjava.com/pub/a/onjava/2006/04/19/database-connection-pooling-with-tomcat.html

[3]
http://webspherepersistence.blogspot.com/2009/01/jpa-connection-pooling.html

hth,
-Jeremy

On Thu, Mar 19, 2009 at 2:33 PM, Paul Copeland  wrote:

> I am just getting started and created a simple standalone (not in an app
> server container) JPA application working with both TopLink and OpenJPA 1.2
> and tested with both MySQL and Postgres.  This is with Java SE 1.5.0_05
> building with Ant (not in in an IDE).
>
> By trial and error I found I needed the jar files downloaded in the
> apache-openjpa-1.2.0 lib directory. I also needed xercesImpl.jar.  I did not
> find these dependencies documented in the release notes, or in the manual,
> or on the Quickstart page  (http://openjpa.apache.org/quick-start.html).
>
> These were the necessary jars at either compile time or runtime -
>
> commons-collections-3.2.jar
> commons-lang-2.1.jar
> geronimo-jpa_3.0_spec-1.0.jar
> geronimo-jta_1.1_spec-1.1.jar
> openjpa-1.2.0.jar
> serp-1.13.1.jar
> xercesImpl.jar
>
> Probably I will also need commons-pool-1.3.jar or something similar for
> Connection pooling.
>
> Presumably the geronimo jars are not needed in a Java 5 EE container.  I'm
> not sure why xerces is required since Java SE 1.5 has a SAX parser.  I guess
> all the other jars need to be deployed in the classpath in most other
> contexts.
>
> This kind of dependency information might be usefully documented somewhere.
>  Every new user has to figure this stuff out.
>
> BTW - My target runtime environment will be Tomcat 6 + Java SE 1.6 +
> OpenJPA 1.2 + Postgres 8.2.x
>
> Any experience or advice about what jars are required or is this already
> documented somewhere?
>
> Thanks - Paul
>
>
>

Re: Slow performance with OpenJPA when selecting from a ManyToMany relation.

[Jeremy Bauer]

Shubbis,

Thanks for your reply and for your willingness to give my suggestion a try.
My question was mainly to (indirectly) point out that emf & em creation is
costly (especially emf) and that it could skew results.  Since your
measurement procedure tosses out high & low values, even if you create the
em during the first exec in your test cycle the measurement procedure would
likely toss out that result.  That being the case, creating the em ahead of
time should not show any better results.  Unless your test suite executes
the ManyToMany tests first and reuses that em for all following tests,
which, from your description is not the case, other tests should have been
similarly affected.  But, it may still be worth verifying.

What issue did you have with the 1.2.x nightly build?  A vote is currently
underway to publish a new 1.2.x release soon so please post if you've found
a problem.

-Jeremy

On Thu, Mar 12, 2009 at 2:26 PM, Shubbis  wrote:

>
> Hi Jeremy!
>
> Our tests get (or create) the em when we begin the measurement. This is
> done
> on all the frameworks and all the tests (selects, inserts, updates,
> deletes,
> etc.). We then remove the highest and lowest numbers from all the results
> and gather an average. Should this really be affected? I mean, wouldn't
> that
> be a problem on all the selects and not only the ManyToMany if that was the
> case?
>
> Don't get me wrong, I'm going to give it a go, but I just want to make sure
> our scenario is understood.
>
> Also we are using MySQL 5.1.
>
> I've also tried to run the test on my local mysql installation and the
> results are similar, actually a bit slower..
>
>
>
> Jeremy Bauer wrote:
> >
> > Hi Shubbis,
> >
> > Does your measurement include the time it takes to create the entity
> > manager
> > factory and/or entity manager or are they created before you execute the
> > find operations?  I'm guessing you create the em ahead of time, since the
> > ManyToMany result is atypical. But if so, could you try creating the em
> > before taking measurement?  That would factor out any em initialization
> > related issues. Also, which db platform are you using for the tests?
> >
> > -Jeremy
> >
> > On Thu, Mar 12, 2009 at 8:48 AM, Shubbis 
> > wrote:
> >
> >>
> >> Hi Kevin,
> >>
> >> Thanks for the reply!
> >>
> >> We are enhancing the files. I have an Ant script enhancing the files
> >> before
> >> every run of OpenJPA, so that is not the problem.
> >> Although it did give me strange results the first time I tried openjpa
> >> and
> >> did not enhance ;)
> >>
> >> -Shubbis
> >>
> >>
> >> Kevin Sutter wrote:
> >> >
> >> > Hi Shubbis,
> >> > Thanks for asking before posting any results...  :-)  Much
> appreciated.
> >> >
> >> > The first thing that comes to mind is whether you are "enhancing" your
> >> > Entities that are used with OpenJPA.  For optimal performance, OpenJPA
> >> > uses
> >> > a byte-code weaving technique to enhance the Entity objects.  This
> >> > enhancement allows for more efficient interaction between the Entity
> >> > objects
> >> > and the OpenJPA runtime.
> >> >
> >> > This blog entry explains the various enhancement mechanisms available
> >> for
> >> > an
> >> > OpenJPA environment (build vs runtime):
> >> >
> >>
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
> >> >
> >> > FYI, if you do not perform the byte-code enhancement either statically
> >> at
> >> > build time or dynamically at runtime, then OpenJPA falls back to a
> >> simpler
> >> > subclassing approach.  This subclassing approach is meant for simple
> >> > out-of-the-box examples, and not for production or performance
> >> > comparisons.
> >> > This performance concern becomes especially noticeable with Eager type
> >> > relationship fetching like it looks your example is doing.
> >> >
> >> > Let's start with this enhancement processing.  If you are doing
> >> > enhancement
> >> > and you are still hitting this performance concern, then we need to
> dig
> >> > further because we definitely do not see this type of performance
> >> concern
> >> > when we do our comparisons...  :-)
> >> >
> >> > Thanks,
> >> > Kevin
> >> >
> >

Re: Slow performance with OpenJPA when selecting from a ManyToMany relation.

[Jeremy Bauer]

Hi Shubbis,

Does your measurement include the time it takes to create the entity manager
factory and/or entity manager or are they created before you execute the
find operations?  I'm guessing you create the em ahead of time, since the
ManyToMany result is atypical. But if so, could you try creating the em
before taking measurement?  That would factor out any em initialization
related issues. Also, which db platform are you using for the tests?

-Jeremy

On Thu, Mar 12, 2009 at 8:48 AM, Shubbis  wrote:

>
> Hi Kevin,
>
> Thanks for the reply!
>
> We are enhancing the files. I have an Ant script enhancing the files before
> every run of OpenJPA, so that is not the problem.
> Although it did give me strange results the first time I tried openjpa and
> did not enhance ;)
>
> -Shubbis
>
>
> Kevin Sutter wrote:
> >
> > Hi Shubbis,
> > Thanks for asking before posting any results...  :-)  Much appreciated.
> >
> > The first thing that comes to mind is whether you are "enhancing" your
> > Entities that are used with OpenJPA.  For optimal performance, OpenJPA
> > uses
> > a byte-code weaving technique to enhance the Entity objects.  This
> > enhancement allows for more efficient interaction between the Entity
> > objects
> > and the OpenJPA runtime.
> >
> > This blog entry explains the various enhancement mechanisms available for
> > an
> > OpenJPA environment (build vs runtime):
> >
> http://webspherepersistence.blogspot.com/2009/02/openjpa-enhancement.html
> >
> > FYI, if you do not perform the byte-code enhancement either statically at
> > build time or dynamically at runtime, then OpenJPA falls back to a
> simpler
> > subclassing approach.  This subclassing approach is meant for simple
> > out-of-the-box examples, and not for production or performance
> > comparisons.
> > This performance concern becomes especially noticeable with Eager type
> > relationship fetching like it looks your example is doing.
> >
> > Let's start with this enhancement processing.  If you are doing
> > enhancement
> > and you are still hitting this performance concern, then we need to dig
> > further because we definitely do not see this type of performance concern
> > when we do our comparisons...  :-)
> >
> > Thanks,
> > Kevin
> >
> > On Thu, Mar 12, 2009 at 7:22 AM, Shubbis 
> > wrote:
> >
> >>
> >> First post so bare with me, and I've search for quite a while and not
> >> found
> >> any answers.
> >>
> >> I'm working on a school project where we are testing performance with
> >> different ORM's compared to JDBC and I'm having a big issue with OpenJPA
> >> when using a ManyToMany relation.
> >>
> >> We're trying to do a simple select case where we run a for loop with 500
> >> iterations while calling a findById method that returns the instance.
> >>
> >> Wearhouse instance = getOJPAEntityManager().find(Wearhouse.class, id);
> >>
> >> This takes roughly 1~ sec on JDBC and 1.2~ EclipseLink while it takes
> 10+
> >> sec on OpenJPA.
> >> This only happens with ManyToMany! We have plenty of insert tests,
> select
> >> tests etc and all of them are much more similar, with openjpa winning
> and
> >> losing a few.
> >>
> >> Now, I'll gladly admit we dont have to much experience with this, but
> >> this
> >> strikes me as very odd. So, if anyone has any tips, comments or info
> I'll
> >> be
> >> glad to try it out.
> >>
> >> Thanks in advance!
> >>
> >> Marius
> >>
> >> Here are the two entities in question:
> >>
> >> package project.common.model;
> >>
> >> import java.util.*;
> >>
> >> import javax.persistence.*;
> >>
> >> @Entity
> >> public class Wearhouse {
> >>
> >>@Id
> >>@GeneratedValue(strategy = GenerationType.IDENTITY)
> >>private Integer wearhouseNr;
> >>private String wearhouseName;
> >>
> >>@ManyToMany(cascade={CascadeType.PERSIST}, fetch =
> >> FetchType.EAGER)
> >>@JoinTable(
> >>name="wearhouse_storagecategory",
> >>joincolum...@joincolumn(name="wearhouseNr"),
> >>
> >>  inversejoincolum...@joincolumn(name="storagecategoryNr")
> >>)
> >>private List storageCategories;
> >>
> >>public Wearhouse() {
> >>}
> >>
> >>public Wearhouse(String wearhouseName) {
> >>this.wearhouseName = wearhouseName;
> >>storageCategories = new ArrayList();
> >>}
> >>
> >>public Integer getWearhouseNr() {
> >>return this.wearhouseNr;
> >>}
> >>
> >>public void setWearhouseNr(Integer wearhouseNr) {
> >>this.wearhouseNr = wearhouseNr;
> >>}
> >>
> >>public String getWearhouseName() {
> >>return this.wearhouseName;
> >>}
> >>
> >>public void setWearhouseName(String wearhouseName) {
> >>this.wearhouseName = wearhouseName;
> >>}
> >>
> >>public void setStorageCategories(List
> >> storageCategory){
> >>this.storageCategories = storag

Re: Removing entity with Embedded field

[Jeremy Bauer]

Hi Marcin,

I observe the same behavior when the base entity contains an embeddable.
Without an embeddable, the provider issues a single delete (as expected).
Since OpenJPA is operating on a single table, I don't see why multiple
deletes are necessary.  Unless I'm missing something, this appears to be a
bug in the provider.  Please open a JIRA.

-Jeremy

On Thu, Feb 19, 2009 at 6:37 AM,  wrote:

> Hi,
>
> I have a following beans:
>
> @Embeddable
> class A {
> int field1
> }
>
> @Entity
> class B {
> @Id
> long id;
>
> int field2
>
> @Embedded
> A field3
> }
>
> When I trying to delete all instances of B entity from data storage by
> "delete from B" I got:
>
> 1. Query ("select" statement) for all B instances
> 2. For each instance from 1. delete statement
>
> Why this is not delete by simple "delete from B" sql statement?
>
> Regards,
> Marcin
>

Re: Eclipse - javaagent enhancement

[Jeremy Bauer]

Adam,

Provided you have your pu's defined separately, the agent allows you to
specify a particular persistence unit for enhancement.  Example:

-javaagent:C:/eclipse.workspaces/3.2.2/openjpa-1.2.0/openjpa-all/target/openjpa-1.2.0.jar=pu=OpenJPAPU

-Jeremy

On Fri, Jan 30, 2009 at 11:05 AM, Adam Hardy wrote:

> Hi Kevin,
>
> whilst on the subject, I'm using this in Eclipse too but there is one thing
> that it appears cannot be done.
>
> One of the projects I work on is a framework that is designed to be used
> with any JPA provider, and the testing runs against OpenJPA as well as
> Hibernate and Toplink Essentials.
>
> Obviously I don't want the javaagent to act on my entity classes when I'm
> running Hibernate or Toplink, but there appears to be no easy way to stop it
> from one test to another in a batch run.
>
> It would be interesting to know whether there are plans to abandon the byte
> code rewriting, and what the history behind its adoption is. I would assume
> that it's performance but I haven't had seen any comparative stats between
> the different JPA providers.
>
> Regards
> Adam
>
>
>
>
> Kevin Sutter on 30/01/09 15:57, wrote:
>
>> Hi Gianny,
>> I use this all the time.  On my Run configuration for the application that
>> I
>> am running I will put something like the following as a JVM argument...
>>
>>
>> -javaagent:C:/eclipse.workspaces/3.2.2/openjpa-1.2.0/openjpa-all/target/openjpa-1.2.0.jar
>>
>> This should kick in the PCEnhancerAgent for the Entity classes that are
>> being loaded.
>>
>> Kevin
>>
>> On Fri, Jan 30, 2009 at 3:53 AM, Gianny Damour <
>> gianny.dam...@optusnet.com.au> wrote:
>>
>>  Hi,
>>>
>>> I am unable to get javaagent based enhancement work within Eclipse.
>>>
>>> Based on a cursory review of PCEnhancerAgent, I can see that no
>>> ClassFileTransformer is installed when
>>>
>>>   List anchors = Configurations.
>>>   getFullyQualifiedAnchorsInPropertiesLocation(opts);
>>>
>>> returns an empty list, which it does in my case when I simply specify the
>>> following JVM arg
>>>
>>> -javaagent:/openjpa-1.2.0.jar
>>>
>>
>

Re: out of memory issues

[Jeremy Bauer]

Adam,
I've found that if you want to run enhancement on a specific pu you can
target it by using the -p parameter with the path to your persistence file
suffixed by an anchor followed by the specific pu name.

example:

java -cp %ENHANCER_PATH% org.apache.openjpa.enhance.PCEnhancer -p
META-INF\persistence.xml#OpenJPAPU

If you are using the ant variation you should be able to do something
similar.

-Jeremy

On Wed, Jan 28, 2009 at 11:44 AM, Adam Hardy wrote:

> I'm now trying the build-time enhancement. My set-up is not playing well
> with the PCEnhancer. I get this:
>
> 158  OpenJPA  INFO   [main] openjpa.Tool - No targets were given.  Running
> on all classes in your persistent classes list, or all metadata files in
> classpath directories if you have not listed your persistent classes.  Use
> -help to display tool usage information.
> Exception in thread "main" java.util.MissingResourceException:
> org.apache.openjpa.persistence.PersistenceProductDerivation:java.util.MissingResourceException:
> Persistence provider "org.hibernate.ejb.HibernatePersistence" specified in
> persistence unit "Hibernate" in "META-INF/persistence.xml" is not a
> recognized provider.
>at
> org.apache.openjpa.lib.conf.ProductDerivations.reportErrors(ProductDerivations.java:365)
>at
> org.apache.openjpa.lib.conf.ProductDerivations.load(ProductDerivations.java:270)
>at
> org.apache.openjpa.lib.conf.Configurations.populateConfiguration(Configurations.java:344)
>at org.apache.openjpa.enhance.PCEnhancer.run(PCEnhancer.java:4438)
>
>
> Is there by some remote chance an undocumented config param to set the
> persistence unit I want it to look at in my persistence.xml?
>
> This is a framework I'm working on which is theoretically
> JPA-implementation neutral.
>
>
>
>
> Adam Hardy on 28/01/09 17:04, wrote:
>
>> Sorry, didn't mean compile-time enhancement, I was just mindlessly
>> parroting the words I was reading :$
>>
>> I started off using nothing, making no changes. No javaagent, nada.
>>
>> Now I've upgraded to Java 1.6 and I'm trying to get that working but
>> today's not being very productive. However "Java 6 class retransformation"
>> certainly sounds hopeful.
>>
>> I do see on my workstation that I still get the warning in my test run
>> that
>>
>> " This means that your application will be less efficient than it would if
>> you ran the OpenJPA enhancer. (openjpa)"
>>
>> although at least it doesn't tell me what it did with Java 1.5:
>>
>> " Additionally, lazy loading will not be available for one-to-one and
>> many-to-one persistent attributes in types using field access; they will be
>> loaded eagerly instead."
>>
>>
>>
>> Jeremy Bauer on 28/01/09 16:35, wrote:
>>
>>> Adam,
>>>
>>> Did you mean runtime enhancement is being used?  (Want to make sure I
>>> didn't
>>> steer you down the wrong path - I don't think so, based on your statement
>>> about adding enhancement to the maven build).
>>> I'm not sure if 1.6 will help, but it may be worth a shot.  (Anyone?)
>>>  Besides using compile-time enhancement you could also try to configure
>>> your
>>> web app server to use the agent enhancer.
>>>
>>> -Jeremy
>>>
>>> On Wed, Jan 28, 2009 at 9:51 AM, Adam Hardy >> >wrote:
>>>
>>>  Hi Jeremy,
>>>>
>>>> compile-time enhancement is being used.
>>>>
>>>> I figured it would have to be something like that. I just upgraded to
>>>> JDK
>>>> 1.6 to see if the enhancement provided that way is better, so fingers
>>>> crossed.
>>>>
>>>> Otherwise I'll have to build in the enhancement stage into the maven
>>>> build
>>>> and from what it looks like, the current way of doing that hasn't been
>>>> changed since OpenJPA v0.9.6.
>>>>
>>>>
>>>> regards
>>>> Adam
>>>>
>>>>
>>>> Jeremy Bauer on 28/01/09 14:35, wrote:
>>>>
>>>>  Adam,
>>>>> Are you using compile time enhancement or does the web container do
>>>>> enhancement?  If not, runtime enhancement will be used and I've seen
>>>>> cases
>>>>> where non-agent runtime enhancement can significantly increase memory
>>>>> usage.
>>>>>
>>>>> If you aren't certain, an easy way to ch

Re: out of memory issues

[Jeremy Bauer]

Adam,

Did you mean runtime enhancement is being used?  (Want to make sure I didn't
steer you down the wrong path - I don't think so, based on your statement
about adding enhancement to the maven build).
I'm not sure if 1.6 will help, but it may be worth a shot.  (Anyone?)
 Besides using compile-time enhancement you could also try to configure your
web app server to use the agent enhancer.

-Jeremy

On Wed, Jan 28, 2009 at 9:51 AM, Adam Hardy wrote:

> Hi Jeremy,
>
> compile-time enhancement is being used.
>
> I figured it would have to be something like that. I just upgraded to JDK
> 1.6 to see if the enhancement provided that way is better, so fingers
> crossed.
>
> Otherwise I'll have to build in the enhancement stage into the maven build
> and from what it looks like, the current way of doing that hasn't been
> changed since OpenJPA v0.9.6.
>
>
> regards
> Adam
>
>
> Jeremy Bauer on 28/01/09 14:35, wrote:
>
>> Adam,
>> Are you using compile time enhancement or does the web container do
>> enhancement?  If not, runtime enhancement will be used and I've seen cases
>> where non-agent runtime enhancement can significantly increase memory
>> usage.
>>
>> If you aren't certain, an easy way to check is to disable runtime
>> enhancement via:
>>
>>  > value="unsupported"/>
>>
>> If your classes are not enhanced, the app will fail with an exception to
>> that effect.
>>
>> -Jeremy
>>
>> On Wed, Jan 28, 2009 at 4:39 AM, Adam Hardy > >wrote:
>>
>>  Hi Mike,
>>>
>>> thanks for the input.
>>>
>>> The child objects are mapped entities and they total around 25 * 300, so
>>> 7500.
>>>
>>> This is their structure:
>>>
>>>   private Long id;
>>>   private BigDecimal total;
>>>   private DollarReturn dollarReturn;
>>>   private TestAnalysis testAnalysis;
>>>
>>> where DollarReturn and TestAnalysis are also mapped entities.
>>> TestAnalysis
>>> will have 7500 of these in its child list. They extend a superclass:
>>>
>>>   private Long version;
>>>   private Long ownerId;
>>>   private Date created;
>>>   private Date modified;
>>>
>>> For what it's worth, they also have several transient properties.
>>>
>>> I didn't get a heap dump before. Now I have changed the architecture a
>>> bit
>>> to try to streamline the process, and the process doesn't crash now, it
>>> just
>>> takes a very long time.
>>>
>>> Regards
>>> Adam
>>>
>>>
>>>
>>> Michael Dick on 27/01/09 16:31, wrote:
>>>
>>>  Hi Adam, just some quick thoughts,
>>>>
>>>> How many child objects are we talking about, and are they entities or
>>>> just
>>>> objects which are persisted to the database?
>>>>
>>>> If you have heap dumps it might be interesting to see which object(s)
>>>> are
>>>> taking up the most memory. It sounds like the likely culprit is the
>>>> number
>>>> of child objects and any OpenJPA objects associated with them.
>>>>
>>>> -mike
>>>>
>>>> On Mon, Jan 26, 2009 at 11:46 AM, Adam Hardy <
>>>> adam@cyberspaceroad.com
>>>>
>>>>> wrote:
>>>>>
>>>>  The webapp I am working on uses OpenJPA (or Hibernate depending on bugs
>>>>
>>>>> blocking progress) and I have just hit a problem that currently looks
>>>>> like
>>>>> it will only be solved by violating the current architecture.
>>>>>
>>>>> I'm hoping I'm wrong and thought I'd ask first.
>>>>>
>>>>> The scenario is that the user can choose a whole range of financial
>>>>> instruments to put in a portfolio, and the webapp grabs them all on
>>>>> submission of the request and builds the object graph.
>>>>>
>>>>> The Manager class which is also the transactional interface then
>>>>> creates
>>>>> an
>>>>> Analysis entity to hold performance stats, and which may create for
>>>>> itself a
>>>>> large number of small child objects representing past performance.
>>>>>
>>>>> When the Analysis is done, the Manager call finishes and the
>>>>> transaction
>>>>> commits (or I commit the transaction in my unit test), and I get an
>>>>> out-of-memory exception.
>>>>>
>>>>> Presumably it's all the child object inserts causing the problem.
>>>>>
>>>>> Obviously I would like to do a flush before I run out of memory, but
>>>>> the
>>>>> Analysis entity object has no access to the entity manager. Or at least
>>>>> it
>>>>> shouldn't have.
>>>>>
>>>>> The other problem is that the Analysis entity can't really be saved
>>>>> until
>>>>> the child objects are all created, so I would have to think of a dirty
>>>>> work-around to allow me to save it first, to allow me to flush the
>>>>> child
>>>>> objects.
>>>>>
>>>>>
>>
>

Re: out of memory issues

[Jeremy Bauer]

Adam,
Are you using compile time enhancement or does the web container do
enhancement?  If not, runtime enhancement will be used and I've seen cases
where non-agent runtime enhancement can significantly increase memory usage.

If you aren't certain, an easy way to check is to disable runtime
enhancement via:

  

If your classes are not enhanced, the app will fail with an exception to
that effect.

-Jeremy

On Wed, Jan 28, 2009 at 4:39 AM, Adam Hardy wrote:

> Hi Mike,
>
> thanks for the input.
>
> The child objects are mapped entities and they total around 25 * 300, so
> 7500.
>
> This is their structure:
>
>private Long id;
>private BigDecimal total;
>private DollarReturn dollarReturn;
>private TestAnalysis testAnalysis;
>
> where DollarReturn and TestAnalysis are also mapped entities. TestAnalysis
> will have 7500 of these in its child list. They extend a superclass:
>
>private Long version;
>private Long ownerId;
>private Date created;
>private Date modified;
>
> For what it's worth, they also have several transient properties.
>
> I didn't get a heap dump before. Now I have changed the architecture a bit
> to try to streamline the process, and the process doesn't crash now, it just
> takes a very long time.
>
> Regards
> Adam
>
>
>
> Michael Dick on 27/01/09 16:31, wrote:
>
>> Hi Adam, just some quick thoughts,
>>
>> How many child objects are we talking about, and are they entities or just
>> objects which are persisted to the database?
>>
>> If you have heap dumps it might be interesting to see which object(s) are
>> taking up the most memory. It sounds like the likely culprit is the number
>> of child objects and any OpenJPA objects associated with them.
>>
>> -mike
>>
>> On Mon, Jan 26, 2009 at 11:46 AM, Adam Hardy > >wrote:
>>
>>  The webapp I am working on uses OpenJPA (or Hibernate depending on bugs
>>> blocking progress) and I have just hit a problem that currently looks
>>> like
>>> it will only be solved by violating the current architecture.
>>>
>>> I'm hoping I'm wrong and thought I'd ask first.
>>>
>>> The scenario is that the user can choose a whole range of financial
>>> instruments to put in a portfolio, and the webapp grabs them all on
>>> submission of the request and builds the object graph.
>>>
>>> The Manager class which is also the transactional interface then creates
>>> an
>>> Analysis entity to hold performance stats, and which may create for
>>> itself a
>>> large number of small child objects representing past performance.
>>>
>>> When the Analysis is done, the Manager call finishes and the transaction
>>> commits (or I commit the transaction in my unit test), and I get an
>>> out-of-memory exception.
>>>
>>> Presumably it's all the child object inserts causing the problem.
>>>
>>> Obviously I would like to do a flush before I run out of memory, but the
>>> Analysis entity object has no access to the entity manager. Or at least
>>> it
>>> shouldn't have.
>>>
>>> The other problem is that the Analysis entity can't really be saved until
>>> the child objects are all created, so I would have to think of a dirty
>>> work-around to allow me to save it first, to allow me to flush the child
>>> objects.
>>>
>>
>

Re: using UserTransaction problem

[Jeremy Bauer]

Glad you found the culprit.  If you are using an EJB 3 container, the use of
an AroundInvoke interceptor may provide a means to handle runtime exceptions
and maintain the state of the transaction.
-Jeremy

On Thu, Jan 22, 2009 at 1:39 PM, is_maximum  wrote:

>
> Thanks Jeremy
>
> I just found that persist() method has thrown a runtime exception and there
> was no log to see and because I hadn't handled the exception to rollback
> the
> transaction, the next begin-transaction encounters an undecided transaction
> and of course the message was true.
>
> but now my question is I cant put a try-catch to catch all the runtime
> exceptions and rollback the tx. is there any other way to manage this?
>
> thanks anyway
>
>
>
> Jeremy Bauer wrote:
> >
> > Hi,
> > If you are using UserTransaction, does your SLSB use bean managed
> > transactions?  In EJB 3.0, container managed transactions are the
> default,
> > so TX configuration is very easy to overlook.  Depending on the app
> > server,
> > using UserTransaction within a container managed tx bean will likely have
> > ill effects.  If you are certain that transactions are bean managed, are
> > there any places where you may be starting a global TX but not completing
> > it
> >  (in a web module, perhaps)?  There are many other possibilities as well,
> > but I'd start with these.  If everything looks good, please send more
> > details - such as the app server you are using, OpenJPA version, and more
> > details about your app - and if possible, test code.
> >
> > -Jeremy
> >
> > On Wed, Jan 21, 2009 at 2:33 AM, is_maximum  wrote:
> >
> >>
> >> Hi
> >> I am using UserTransaction in my stateless session bean and got this
> >> error
> >> and all the process will stop
> >>
> >> ERROR - The stateless session bean started a transaction but did not
> >> complete it.
> >>
> >> there is a method in which some other private methods is being called.
> >>
> >> can anyone help me out
> >> --
> >> View this message in context:
> >>
> http://n2.nabble.com/using-UserTransaction-problem-tp2191081p2191081.html
> >> Sent from the OpenJPA Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/using-UserTransaction-problem-tp2191081p2199698.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>

Re: using UserTransaction problem

[Jeremy Bauer]

Hi,
If you are using UserTransaction, does your SLSB use bean managed
transactions?  In EJB 3.0, container managed transactions are the default,
so TX configuration is very easy to overlook.  Depending on the app server,
using UserTransaction within a container managed tx bean will likely have
ill effects.  If you are certain that transactions are bean managed, are
there any places where you may be starting a global TX but not completing it
 (in a web module, perhaps)?  There are many other possibilities as well,
but I'd start with these.  If everything looks good, please send more
details - such as the app server you are using, OpenJPA version, and more
details about your app - and if possible, test code.

-Jeremy

On Wed, Jan 21, 2009 at 2:33 AM, is_maximum  wrote:

>
> Hi
> I am using UserTransaction in my stateless session bean and got this error
> and all the process will stop
>
> ERROR - The stateless session bean started a transaction but did not
> complete it.
>
> there is a method in which some other private methods is being called.
>
> can anyone help me out
> --
> View this message in context:
> http://n2.nabble.com/using-UserTransaction-problem-tp2191081p2191081.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>

Re: orm.xml / element-collection / trunk

[Jeremy Bauer]

Hi Frank,
I'm very glad to hear that you are trying out some of the new JPA 2.0
features.  I've found that the issue you found isn't specific to OpenJPA
2.0.  This problem also exists on previous releases (1.0.2) of OpenJPA.  In
short, if an entity is defined only in the orm.xml and not all fields are
defined, an exception is thrown.  Annotating the class with @Entity or
defining all fields in the orm.xml corrects the problem.

This entity definition corrected the problem:


   
   
   
   
   
   
   
   
   


Based on what I've read in the JPA spec, this looks like a bug.  OpenJPA
should consider firstName and lastName persistent fields by default.  I've
opened JIRA OPENJPA-859  for
this issue.

-Jeremy

On Sun, Jan 11, 2009 at 12:45 PM, Frank Schwarz  wrote:

>
> Hi,
>
>
> testing some of the advertised JPA2 features (see
>
> http://openjpa.apache.org/2008/12/23/openjpa-20-iteration-1-is-complete.html
>
> http://openjpa.apache.org/2008/12/23/openjpa-20-iteration-1-is-complete.html
> ) I came across an issue with collections of primitives:
>
> model:
>
> entity Person with fields long id, String firstName, String lastName,
> Set addresses
>
> mapping is done via orm.xml:
>
> 
>
>
>
>
>
>
>
> 
>
>
> This gives me an irritating exception about missing metadata for firstName
> and lastName:
>
> Exception in thread "main"
> org.apache.openjpa.persistence.ArgumentException: Fields
> "Person.firstName, model.Person.lastName" are not a default
> persistent type, and do not have any annotations indicating their
> persistence strategy.  If you do not want these fields to be persisted,
> annotate them with @Transient.
>at
>
> org.apache.openjpa.persistence.PersistenceMetaDataFactory.validateStrategies(PersistenceMetaDataFactory.java:399)
>at
>
> org.apache.openjpa.persistence.PersistenceMetaDataFactory.load(PersistenceMetaDataFactory.java:205)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:474)
>at
>
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:294)
>at
>
> org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingRepository.java:286)
>at
> org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:676)
>at
> org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:748)
>at
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:646)
>at
>
> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:153)
>at
>
> org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl(JDBCBrokerFactory.java:119)
>at
>
> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:196)
>at
>
> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142)
>at
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:197)
>at
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:150)
>at
>
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:61)
>at
>
> oopex.openjpa2.jpa2.relationships.CollectionOfPrimitivesMain.insert(CollectionOfPrimitivesMain.java:69)
>at
>
> oopex.openjpa2.jpa2.relationships.CollectionOfPrimitivesMain.main(CollectionOfPrimitivesMain.java:49)
>
>
>
> A bug?
>
>
> -- Frank
> --
> View this message in context:
> http://n2.nabble.com/orm.xml---element-collection---trunk-tp2142331p2142331.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>


Re: Entitymanager lookup using JNDI on webshpere


2009-01-13

Thread
Jeremy Bauer
Devu,
Apologies. I should have clarified.  You can do the lookup from your POJO as
long as the POJO method is called from a method of your EJB.

example:

MYEjb {

   public void mymethodwhichneedsacachevalue() {
 CachePOJO.getValue(key);
  }

}

CachePOJO {

   private void initialize() {
 InitialContext ctx = new InitialContext();
 Entitymanger mgr = ctx.lookup("java:comp/env/MyPCJndi");
 //use mgr to load values from DB.
 
  }

public String getValue(String key) {
// initialize is called if not initialized?
...
}
}

Question - does your cache store a static reference to the entity manager or
does it only get used once during initialization?  If it is a one time
usage, this pattern should work fine.  If you need to store the entity
manager, this pattern likely will not work.  (There are various transaction
and thread safety issues to consider.)  Alternately, you'll could look up
the entity manager upon each usage or switch to an application managed
design.

-Jeremy

On Tue, Jan 13, 2009 at 2:37 AM, devu213  wrote:

>
> Hi Kevin /Jeremy,
>
> Thanks for your replies.
>
> In the code that you mention, I would have to follow a pattern like this...
>
> MYEjb {
>
>  EntityManager em = null;
>InitialContext ctx = new InitialContext();
>em = (EntityManager)ctx.lookup("java:comp/env/MyPCJndi");
>
> public void mymethodwhichneedsacachevalue() {
>  Cache.getValue(key, manager); // the manager is passed to
> the cache. Don't want this
>   }
>
> }
>
> CachePOJO {
>


>
> public String getValue(String key, EntityManager manager) {
> //singleton...uses manager to initialize from database for the
> first time
>}
>
> }
>
>
> What I really want is
>
>
> CachePOJO {
>
>private void initialize() {
>  InitialContext ctx = new InitialContext();
>  Entitymanger mgr = ctx.lookup(jndinameofmgr);
>  //use mgr to load values from DB.
>   }
>
> }
>
> Yes, the cache is accessed from an EJB, but I don't want to be passing the
> manager around. In fact, I have this pattern problem repeatedly because we
> have DAO classes that always now need to get initialized with the manager
> which is passed from the EJB class (session facade). I end up having to
> pass
> my entitymanager around.
>
>
> In a previous project with hibernate, I remember being able to get the
> sessions directly from the container using JNDI and they would be bound to
> a
> transaction if there was one existing.  I want to be able to work with a
> similar pattern but stumble since the only place I am able to get a manager
> from right now is inside an EJB which I then have to pass around to lower
> layers.
>
> Thanks in advance.
>
> Devu.
>
> Jeremy, I don't have an option to go to WAS 7 right now, I will have to
> live
> with the fix packs. Will try out the method in Kevin's link.
>
>
>
> Kevin Sutter wrote:
> >
> > Devu213,
> > Besides Jeremy's references below, I want to be aware of WebSphere's
> > support
> > of OpenJPA.  I started to cover this the WebSphere and Java Persistence
> > blog
> > [1], but to cover your specific situation...  You are correct that the
> > version shipped with the WebSphere EJB3 Feature Pack was OpenJPA 1.0.
> > But,
> > we have created a service stream for this release in OpenJPA (1.0.x).  If
> > any problems are discovered in the 1.0 release, then we can fix them in
> > OpenJPA 1.0.x.  This updated version of OpenJPA will then get picked up
> > for
> > WebSphere iFixes and FixPacks.  So, you are not "stuck" with OpenJPA 1.0.
> > It will get updated just like the rest of your WebSphere offering as
> > additional FixPacks are applied.
> >
> > WebSphere v7 shipped a version of 1.2 OpenJPA.  This version will get
> > supported via the 1.2.x branch of OpenJPA.  You could follow Jeremy's
> > references below to use this newer version of OpenJPA with the EJB3
> > Feature
> > Pack, but then you no longer have access to the WebSphere extensions that
> > sit on top of the OpenJPA binaries.  It is an option though.
> >
> > Good luck,
> > Kevin
> >
> > [1]
> >
> http://webspherepersistence.blogspot.com/2008/09/support-for-openjpa.html
> >
> >
> > On Mon, Jan 12, 2009 at 10:42 AM, Jeremy Bauer 
> > wrote:
> >
> >> Hi devu213,
> >> To use JNDI to lookup an EM or EMF in WebSphere app server you can
> define
> 

Re: Entitymanager lookup using JNDI on webshpere


2009-01-12

Thread
Jeremy Bauer
Hi devu213,
To use JNDI to lookup an EM or EMF in WebSphere app server you can define a
class level annotation (or via XML in your ejb module deployment descriptor)
on your session bean or servlet and use the "name" attribute to specify the
JNDI name.  For example:

@Stateless
@PersistenceContext(unitName="MyPC", name="MyPCJndi")
public class JPABean implements JPALocal, JPARemote {
...
@Resource SessionContext sessionCtx;

public void beanMethod() {

// 1) Lookup via comp/env namespace of the initial/current context
EntityManager em = null;
InitialContext ctx = new InitialContext();
em = (EntityManager)ctx.lookup("java:comp/env/MyPCJndi");

//  or 2) Use direct lookup from the injected session ctx of the session
bean
em = (EntityManager)sessionCtx.lookup("MyPCJndi");

}

Looking up an EntityManagerFactory via @PersistenceUnit works similarly.

Notice though, that lookup is via the ENC of the EJB.  I don't know how/if
global JNDI can be used to get a factory. (Anyone?) So, if you initialize
your POJO cache within the context of the EJB, the lookup will work.  If you
need to initialize the cache outside of a container,
Persistence.createEntityManagerFactory should work for you.  I'd verify that
all of your jars specified in your jar-file entry are available on the
classpath of your application.  You may need to add the jars to the class
path entry in the manifest of your module.

Here's an IBM infocenter document that explains how to configure an
alternate persistence provider[1].  The key items when using an alternate
version of OpenJPA is to make sure you've included all the necessary OpenJPA
jars in your application or via shared library and the application
classloader is configured to load PARENT_LAST.  This allows the OpenJPA jars
provided by the application (or shared lib) to be loaded before those
provided by the app server.

[1]
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.ejbfep.multiplatform.doc/info/ae/ae/tejb_jpa3rdparty.html

Hope this helps,
-Jeremy

On Sat, Jan 10, 2009 at 4:25 AM, devu213  wrote:

>
> Hi Kevin,
>
> Thanks for taking interest despite this being a Websphere question. Here is
> the information that might help:
>
> 1. Yes am using the EJB3 featurepack. My server is at version 6.1.0.17 with
> EJB and Webservices FP installed.
> 2. The code snippet Persistence.createEntityManager() works on stand-alone
> even with the jar tags(but fails in the container).
> 3. I am using the openJPA shipped with Websphere.
>
> Having given you the above it looks from your answer that I have erred by
> not stating my question properly. The issue is, I don't know what name is
> used to bind the factory and the manager. So the issue is not that I'm not
> able to lookup but that I don't know the JNDI name to look up and so
> haven't
> even tried it. Somehow, I did not find any documentation on the Websphere
> sites or google.
>
> Also on similar lines, I would like to see some documentation on how to
> override the default openJPA shipped with WAS because I want to be able to
> use the latest version but the one being picked up by the classloader is
> always the 1.0 version.
>
> Thanks in advance.
>
>
>
> Kevin Sutter wrote:
> >
> > Hi devu213,
> > Just to clarify...  Are you using the EJB3 Feature Pack on top of
> > WebSphere
> > v6.1.  Are you using the version of OpenJPA that ships with the Feature
> > Pack, or something newer?  It sounds like you are using container-managed
> > persistence (ie. the injection support), so it sounds like you are using
> > the
> > EJB3 Feature Pack.  But, I just want to make sure.
> >
> > With the EJB3 Feature Pack, the JNDI lookup of an EntityManager should
> > work
> > as well as the injection support.  You mention that you are getting a SAX
> > parser error with your persistence.xml file.  Do you get any parsing
> > errors
> > when running OpenJPA standalone?  Or, is all of your testing within a
> > container?  Can you provide more details on the specific parsing errors
> > you
> > are getting?
> >
> > You should also be able to use application-managed persistence within the
> > Container.
> >
> > Off the top of my head, I'm not aware of any problems with what you are
> > attempting.  Unfortunately, I can't highlight anything you're doing
> > incorrectly.  If you can provide some additional details, maybe we can
> > help
> > get you running.
> >
> > FYI...  Just a reminder.  This forum is for questions and issues specific
> > to
> > OpenJPA.  Since some of us are intimate with WebSphere, we attempt to
> help
> > with related WebSphere questions.  In this particular case, it sounds
> like
> > you might be hitting a problem with the EJB Container within WebSphere.
> > We
> > can help with the triage of this case, but we won't be able to resolve
> the
> > problem with OpenJPA (if it turns out to be a problem with the
> Container).
> >
> > Thanks,
> > Kevin
> >
> > On Wed, Jan 7, 2009 at 2

Re: How to configure openjpa logs from "inside" tomcat (6.0)?


2009-01-07

Thread
Jeremy Bauer
Andrei,
If you haven't solved this issue, the simplest way I've found to enable
OpenJPA logging within Tomcat is to:

1) add this property to your persistence.xml



2) create a logging.properties file with the following content and add it to
the WEB-INF/classes directory of your war.

handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

org.apache.juli.FileHandler.level = ALL
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = openjpa.

java.util.logging.ConsoleHandler.level = ALL
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter

# enable SQL logging
openjpa.jdbc.SQL.level=ALL

OpenJPA should log to a file with a name prefixed with "openjpa" in the
tomcat logs directory.  The *.ConsoleHandler.* properties enable logging to
the console so you may/may not want to include those.

hth,
-Jeremy

On Tue, Dec 30, 2008 at 9:50 PM, Andrei Tchijov  wrote:

>
> Sorry if this topic was discussed before (and will be very glad just to get
> pointer to previous discussion).
> I am having difficulties with controlling opnejpa logging when it is
> running
> "inside" tomcat (6.0).  So far I have tried following:
> - specifying openjpa.Log property in persistence.xml file,
> - passing openjpa.Log property(among others) to
> createEntityManagerFactory(),
> - adding "openjpa. ... .level=..." lines to conf/logging.properties file
> What I want is to be able to see SQL statements (and I can see them when I
> run my code outside of tomcat), what I got is two messages:
>  ...  openjpa.Runtime - Starting OpenJPA 1.2.0
>  ...  openjpa.jdbc.JDBC - Using dictionary class
> "org.apache.openjpa.jdbc.sql.MySQLDictionary".
> Your advice will be highly appreciated,
>
> Andrei Tchijov
> --
> View this message in context:
> http://n2.nabble.com/How-to-configure-openjpa-logs-from-%22inside%22-tomcat-%286.0%29--tp2094916p2094916.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>
>



  1   2    >  

    

      
    
    
 1 - 100 of 149 matches
    

    
Advanced search


Search the list




    
    

      

                               Site Navigation
      
      

        
The Mail Archive home
        

          users - all messages
        

          users  - about the list
        
Expand
      
    

    

      

  				Mail list logo
      
      
    
  

    

	        	      Footer information
    
    

      
The Mail Archive home
      
Add your mailing list
      
FAQ
      
Support
      
Privacy