openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: Unenhanced Classes
Date Fri, 10 Aug 2007 22:44:27 GMT
Hi,

What's your environment? Are you using Java 5 or 6? Are you using an
agent? If in 5 and you have your own agent, it'd definitely be better
if you could make a call to our agent to get things set up.

> Anyway, any ideas on a work around for these problems or is this
> something I can help with?

Failing tests would be swell -- just make the test name be 'xtestFoo'
or something so that we don't pick it up.

The permanent lazy loading problem is that without redefinition, with
all field access  instances, and with field or prop access with
user-created instances, automatic lazy loading for single-valued
fields is unavailable, since we cannot receive notification of when to
do the lazy load. I believe that we have code in place to ignore the
lazy directive in these situations, but that could be broken /
unimplemented.

-Patrick

On 8/10/07, Dain Sundstrom <dain@iq80.com> wrote:
> This feature is almost working perfectly for me.  I am seeing 3
> errors repeated though out my test cases.
>
> 1 ==================
>
> The first exception happens when I have a complex primary key.
>
> <1.0.0-SNAPSHOT-SNAPSHOT nonfatal general error>
> org.apache.openjpa.persistence.PersistenceException: null
>         at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2437)
>         at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2251)
>         at org.apache.openjpa.kernel.DelegatingBroker.persist
> (DelegatingBroker.java:1010)
>         at org.apache.openjpa.persistence.EntityManagerImpl.persist
> (EntityManagerImpl.java:541)
>         at org.apache.openejb.persistence.JtaEntityManager.persist
> (JtaEntityManager.java:97)
>         at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.createBean
> (JpaCmpEngine.java:142)
>         at org.apache.openejb.core.cmp.CmpContainer.createEJBObject
> (CmpContainer.java:642)
>          ......
> Caused by: java.lang.NullPointerException
>         at org.apache.openjpa.util.ApplicationIds
> $PrimaryKeyFieldManager.retrieve(ApplicationIds.java:555)
>         at org.apache.openjpa.util.ApplicationIds
> $PrimaryKeyFieldManager.fetchStringField(ApplicationIds.java:540)
>         at org.apache.openjpa.enhance.openejb$org$apache$openejb$test$entity
> $cmp$ComplexCmpBeanX$pcsubclass.pcCopyKeyFieldsToObjectId(Unknown
> Source)
>         at org.apache.openjpa.enhance.PCRegistry.copyKeyFieldsToObjectId
> (PCRegistry.java:160)
>         at org.apache.openjpa.util.ApplicationIds.fromPKValues
> (ApplicationIds.java:182)
>         at
> org.apache.openjpa.enhance.ReflectingPersistenceCapable.pcNewObjectIdIns
> tance(ReflectingPersistenceCapable.java:257)
>         at org.apache.openjpa.util.ApplicationIds.create(ApplicationIds.java:
> 381)
>         at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2405)
>         ... 30 more
>
> This is an CMP primary key so the fields are public:
>
> public class ComplexCmpBeanPk implements Serializable {
>      public String firstName;
>      public String lastName;
>      ...
> }
>
> And the bean is a CMP 1.1 class so the fields are public also (yes I
> know this is bad practice but it is how the CMP specs worked).
>
> 2 ==================
>
> The second exception occurs with auto generated primary keys:
>
> <1.0.0-SNAPSHOT-SNAPSHOT nonfatal general error>
> org.apache.openjpa.persistence.PersistenceException: null
>         at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2437)
>         at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2251)
>         at org.apache.openjpa.kernel.DelegatingBroker.persist
> (DelegatingBroker.java:1010)
>         at org.apache.openjpa.persistence.EntityManagerImpl.persist
> (EntityManagerImpl.java:541)
>         at org.apache.openejb.persistence.JtaEntityManager.persist
> (JtaEntityManager.java:97)
>         at org.apache.openejb.core.cmp.jpa.JpaCmpEngine.createBean
> (JpaCmpEngine.java:142)
>         at org.apache.openejb.core.cmp.CmpContainer.createEJBObject
> (CmpContainer.java:642)
>          ......
> Caused by: java.lang.NullPointerException
>         at org.apache.openjpa.util.ApplicationIds.fromPKValues
> (ApplicationIds.java:155)
>         at
> org.apache.openjpa.enhance.ReflectingPersistenceCapable.pcNewObjectIdIns
> tance(ReflectingPersistenceCapable.java:257)
>         at org.apache.openjpa.util.ApplicationIds.create(ApplicationIds.java:
> 381)
>         at org.apache.openjpa.kernel.BrokerImpl.persist(BrokerImpl.java:2405)
>         ... 30 more
>
> 3 ==================
>
> The final problem is that it appears that collection valued
> relationship fields are always null.  I always access the JPA beans
> from within a transaction, so this isn't a disconnected problem.  Is
> this the lazy load problem you mentioned below?
>
> ==================
>
>
> Anyway, any ideas on a work around for these problems or is this
> something I can help with?
>
> -dain
>
>
> On Aug 9, 2007, at 8:05 PM, Dain Sundstrom wrote:
>
> > On Aug 9, 2007, at 6:26 PM, Patrick Linskey wrote:
> >
> >> Hi,
> >>
> >> Some brief notes:
> >>
> >>>    In Java5 without an agent and enhancement, what doesn't work
> >>> perfectly (I don't care about performance issues)?
> >>
> >> - Lazy loading on user-created instances after flush
> >
> > What is this and is this something the user would notice?  Also, is
> > this something that can be fixed or is this just the way it works?
> >
> >> - generated value field / property access will not materialize the
> >> generated value automatically
> >
> > Can I force the generated value to materialize somehow, and as
> > above is this something that we can fix?
> >
> >>>    Does the Java6 redefine code work?
> >>
> >> Yes, in at least Sun's Java 6 configurations.
> >
> > Super cool!  I can't wait to read that code over.
> >
> >>>    In OpenEJB we don't use the OpenJPA agent (we have our own).
> >>> What
> >>> do we have to do to get Java6 redefine working with OpenJPA?
> >>
> >> Nothing. But if you've got your own agent and you know the list of
> >> persistent types up-front, you might want to consider doing automatic
> >> runtime enhancement instead of automatic runtime redefinition.
> >
> > We do, but there are some embedded cases where a class can be
> > loaded before we are even launched.  So how do you get ahold of the
> > Instrumentation instance (so you can call redefine) if your agent
> > isn't loaded?
> >
> > -dain
>
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message