Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EclipseLink » NPE in MethodAttributeAccessor.getAttributeValueFromObject()
NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #915881] Tue, 18 September 2012 02:36 Go to next message
Knut Wannheden is currently offline Knut Wannheden
Messages: 287
Registered: July 2009
Senior Member
Hi all,

Before I go through the trouble of creating a simple reproducable test
case I would first like to check if what I am doing is out of the
ordinary and possibly not even supported by EclipseLink (or JPA).

I have two persistence units A and B. The persistence unit A contains an
entity A:

@Entity
public class A {
@Id private Long id;
}

And the persistence unit B contains an entity B:

@Entity
public class B {
@ElementCollection
@CollectionTable("B_AS")
private Collection<AId> as;
}

and with AId as:

@Embeddable
public class AId {
private Long id;
public Long getId() { return id; }
}

As you can see B thus indirectly references A.

The problem I now have is that when I write JPQL queries against B I
sometimes get NPEs thrown from EclipseLink (2.3.2):

javax.persistence.PersistenceException: Exception [EclipseLink-70]
(Eclipse Persistence Services - 2.3.2.v20111125-r10461):
org.eclipse.persistence.exceptions.DescriptorException
Exception Description: A NullPointerException was thrown while
extracting a value through the method [getId] in the object [pua.AId].
Internal Exception: java.lang.NullPointerException
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[id-->ID]
Descriptor: RelationalDescriptor(pua.AId --> [DatabaseTable(PUB.B_AS)])
at
org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:786)
at
org.eclipse.persistence.internal.jpa.EJBQueryImpl.performPreQueryFlush(EJBQueryImpl.java:1298)
at
org.eclipse.persistence.internal.jpa.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:434)
at
org.eclipse.persistence.internal.jpa.EJBQueryImpl.getResultList(EJBQueryImpl.java:742)
at
com.avaloq.tools.repository.internal.server.ResourceEntityManager.namedQueryResults(ResourceEntityManager.java:338)
at
com.avaloq.tools.repository.internal.delivery.server.CategoryServiceDelegate.getByCustomerIssue(CategoryServiceDelegate.java:168)
at
com.avaloq.tools.repository.internal.delivery.server.CategoryService.getByCustomerIssue(CategoryService.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1052)
at
org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1124)
at
com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5388)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:619)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:571)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:861)
at
com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:800)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:370)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5360)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5348)
at
com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:214)
.... 44 more
Caused by: Exception [EclipseLink-70] (Eclipse Persistence Services -
2.3.2.v20111125-r10461):
org.eclipse.persistence.exceptions.DescriptorException
Exception Description: A NullPointerException was thrown while
extracting a value through the method [getId] in the object [pua.AId].
Internal Exception: java.lang.NullPointerException
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[id-->ID]
Descriptor:
RelationalDescriptor(com.avaloq.tools.model.issue.common.IssuePrimaryKey
--> [DatabaseTable(PUB.B_AS)])
at
org.eclipse.persistence.exceptions.DescriptorException.nullPointerWhileGettingValueThruMethodAccessor(DescriptorException.java:1272)
at
org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor.getAttributeValueFromObject(MethodAttributeAccessor.java:92)
at
org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor.getAttributeValueFromObject(MethodAttributeAccessor.java:61)
at
org.eclipse.persistence.mappings.DatabaseMapping.getAttributeValueFromObject(DatabaseMapping.java:516)
at
org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.compareObjects(AbstractDirectMapping.java:440)
at
org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.compareForChange(AbstractDirectMapping.java:392)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.createObjectChangeSetThroughComparison(DeferredChangeDetectionPolicy.java:177)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.createObjectChangeSet(DeferredChangeDetectionPolicy.java:137)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChanges(DeferredChangeDetectionPolicy.java:89)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChangesForExistingObject(DeferredChangeDetectionPolicy.java:54)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(UnitOfWorkImpl.java:643)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.writeChanges(RepeatableWriteUnitOfWork.java:433)
at
org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:780)
.... 72 more
Caused by: java.lang.NullPointerException
at
org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor.getAttributeValueFromObject(MethodAttributeAccessor.java:82)
.... 83 more


Does the setup as explained look correct to you? Should I try to create
a reproducable test case for this?

Regards,

--knut
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #916073 is a reply to message #915881] Tue, 18 September 2012 09:45 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
Feel free to file a bug. The issue though isn't with the query itself, but with a flush of changes that exist in the context at the time of the query. You should be able to reproduce it by calling flush directly instead of executing a query.

A way to avoid this is to not use an embeddable to wrap a single field when you can use that field directly. The collection should probably just contain Long values directly, and Long used as A's pk instead of creating an AId class to wrap the Long.

Best Regards,
Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #916074 is a reply to message #915881] Tue, 18 September 2012 09:45 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
Feel free to file a bug. The issue though isn't with the query itself, but with a flush of changes that exist in the context at the time of the query. You should be able to reproduce it by calling flush directly instead of executing a query.

A way to avoid this is to not use an embeddable to wrap a single field when you can use that field directly. The collection should probably just contain Long values directly, and Long used as A's pk instead of creating an AId class to wrap the Long.

Best Regards,
Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #916075 is a reply to message #915881] Tue, 18 September 2012 09:46 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
Feel free to file a bug. The issue though isn't with the query itself, but with a flush of changes that exist in the context at the time of the query. You should be able to reproduce it by calling flush directly instead of executing a query.

A way to avoid this is to not use an embeddable to wrap a single field when you can use that field directly. The collection should probably just contain Long values directly, and Long used as A's pk instead of creating an AId class to wrap the Long.

Best Regards,
Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #916078 is a reply to message #915881] Tue, 18 September 2012 09:45 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
Feel free to file a bug. The issue though isn't with the query itself, but with a flush of changes that exist in the context at the time of the query. You should be able to reproduce it by calling flush directly instead of executing a query.

A way to avoid this is to not use an embeddable to wrap a single field when you can use that field directly. The collection should probably just contain Long values directly, and Long used as A's pk instead of creating an AId class to wrap the Long.

Best Regards,
Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #916079 is a reply to message #915881] Tue, 18 September 2012 09:45 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
Feel free to file a bug. The issue though isn't with the query itself, but with a flush of changes that exist in the context at the time of the query. You should be able to reproduce it by calling flush directly instead of executing a query.

A way to avoid this is to not use an embeddable to wrap a single field when you can use that field directly. The collection should probably just contain Long values directly, and Long used as A's pk instead of creating an AId class to wrap the Long.

Best Regards,
Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #916080 is a reply to message #915881] Tue, 18 September 2012 09:46 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
Feel free to file a bug. The issue though isn't with the query itself, but with a flush of changes that exist in the context at the time of the query. You should be able to reproduce it by calling flush directly instead of executing a query.

A way to avoid this is to not use an embeddable to wrap a single field when you can use that field directly. The collection should probably just contain Long values directly, and Long used as A's pk instead of creating an AId class to wrap the Long.

Best Regards,
Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #916171 is a reply to message #916073] Tue, 18 September 2012 12:42 Go to previous messageGo to next message
Knut Wannheden is currently offline Knut Wannheden
Messages: 287
Registered: July 2009
Senior Member
Hi Chris,

Thank you for your (many :-)) prompt answers.

From what you are saying I gather that there is indeed an EclipseLink
bug lurking here somewhere.

In the example I provided I by accident omitted an important detail: The
AId class is also annotated with @Access(AccessType.PROPERTY). Removing
this or explicitly setting FIELD does however result in another very
similar exception.

I will look into the possibility of skipping the embeddable, but I am
afraid that may be difficult as that is the way the code is being
generated by a framework I am using. So I would have to get that
changed. If that isn't possible I will file a bug instead.

Best regards,

--knut

On 9/18/12 15:45, Chris Delahunt wrote:
> Feel free to file a bug. The issue though isn't with the query itself,
> but with a flush of changes that exist in the context at the time of the
> query. You should be able to reproduce it by calling flush directly
> instead of executing a query.
> A way to avoid this is to not use an embeddable to wrap a single field
> when you can use that field directly. The collection should probably
> just contain Long values directly, and Long used as A's pk instead of
> creating an AId class to wrap the Long.
> Best Regards,
> Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #918720 is a reply to message #916171] Fri, 21 September 2012 05:26 Go to previous messageGo to next message
Knut Wannheden is currently offline Knut Wannheden
Messages: 287
Registered: July 2009
Senior Member
Hi again,

I have now also encountered this problem with the report query executed
in isolation. I.e. not as part of the pre-query-flush. Here is the
stacktrace:

Exception [EclipseLink-70] (Eclipse Persistence Services -
2.3.2.v20111125-r10461):
org.eclipse.persistence.exceptions.DescriptorException
Exception Description: A NullPointerException was thrown while
extracting a value through the method [getId] in the object [pua.AId].
Internal Exception: java.lang.NullPointerException
Mapping: org.eclipse.persistence.mappings.DirectToFieldMapping[id-->ID]
Descriptor:
RelationalDescriptor(com.avaloq.tools.model.issue.common.IssuePrimaryKey
--> [DatabaseTable(PUB.B_AS)])
at
org.eclipse.persistence.exceptions.DescriptorException.nullPointerWhileGettingValueThruMethodAccessor(DescriptorException.java:1272)
at
org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor.getAttributeValueFromObject(MethodAttributeAccessor.java:92)
at
org.eclipse.persistence.internal.descriptors.MethodAttributeAccessor.getAttributeValueFromObject(MethodAttributeAccessor.java:61)
at
org.eclipse.persistence.mappings.DatabaseMapping.getAttributeValueFromObject(DatabaseMapping.java:516)
at
org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.compareObjects(AbstractDirectMapping.java:440)
at
org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.compareForChange(AbstractDirectMapping.java:392)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.createObjectChangeSetThroughComparison(DeferredChangeDetectionPolicy.java:177)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.createObjectChangeSet(DeferredChangeDetectionPolicy.java:137)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChanges(DeferredChangeDetectionPolicy.java:89)
at
org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChangesForExistingObject(DeferredChangeDetectionPolicy.java:54)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(UnitOfWorkImpl.java:643)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1490)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3143)
at
org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:346)
at
org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:157)
at
org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
at
com.sun.jts.jta.SynchronizationImpl.before_completion(SynchronizationImpl.java:99)
at
com.sun.jts.CosTransactions.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:158)
at
com.sun.jts.CosTransactions.TopCoordinator.beforeCompletion(TopCoordinator.java:2548)
at
com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:279)
at
com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:250)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:633)
at
com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:332)
...

What I also find strange is that when I execute the report query again I
don't get this NPE.

Best regards,

--knut
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #918928 is a reply to message #918720] Fri, 21 September 2012 09:45 Go to previous messageGo to next message
Chris Delahunt is currently offline Chris Delahunt
Messages: 1016
Registered: July 2009
Senior Member
The stack trace shows that this is occuring on a transaction commit, not on a query as you stated. It seems to be the same problem you originally posted - once your context has the problem with the embeddable, the NPE will occur on any flush or transaction commit.

Since you are reusing the AId in both a collection and as A's pk class, are you reusing the same object in both as well? They should not be shared - B should have its own AId instance in its collection that is a different from the instance in A, even though the values held might be the same. Embeddable instances should not be shared, and might result in this exception.

Best Regards,
Chris
Re: NPE in MethodAttributeAccessor.getAttributeValueFromObject() [message #919997 is a reply to message #918928] Sat, 22 September 2012 12:01 Go to previous message
Knut Wannheden is currently offline Knut Wannheden
Messages: 287
Registered: July 2009
Senior Member
Hi Chris,

It seems like I will have to try to narrow this down. Yes, you are
right, the problem is occurring as part of a transaction commit. The
transaction commit is occurring since the report query is being executed
within a container-managed JTA transaction. But the only thing the
transaction does is to execute a JPQL report query as simple as:

select b.as
from b b
where b.id = :id

It seems like the query execution registers objects in the unit of work
which on commit are checked for possible changes. So I suppose a
workaround may be to call EntityManager#clear() before the transaction ends.

Regards,

--knut

On 9/21/12 15:45, Chris Delahunt wrote:
> The stack trace shows that this is occuring on a transaction commit, not
> on a query as you stated. It seems to be the same problem you originally
> posted - once your context has the problem with the embeddable, the NPE
> will occur on any flush or transaction commit.
> Since you are reusing the AId in both a collection and as A's pk class,
> are you reusing the same object in both as well? They should not be
> shared - B should have its own AId instance in its collection that is a
> different from the instance in A, even though the values held might be
> the same. Embeddable instances should not be shared, and might result in
> this exception.
>
> Best Regards,
> Chris
Previous Topic:Location of jaxb.index for JAXB
Next Topic:HashPartitioningPolicy fails for large IDs of type long
Goto Forum:
  


Current Time: Wed Jul 30 07:17:55 EDT 2014

Powered by FUDForum. Page generated in 0.03021 seconds