Left Join Fetch on Embeddable ElementColection fails & NamedQuery wit…

[kalinchan]

credit to @Pandrex247 and @Cousjava

Left Join Fetch

The error occurs when the Entities are compared to see if there is any change done and thus an update needs to be done to the database.

[2020-09-01T12:05:10.724+0200] [Payara 5.201] [WARNING] [] [javax.enterprise.web] [tid: _ThreadID=107 _ThreadName=http-thread-pool::http-listener-1(4)] [timeMillis: 1598954710724] [levelValue: 900] [[
StandardWrapperValve[be.rubus.payara.support.ticket1455.ApplicationConfig]: Servlet.service() for servlet be.rubus.payara.support.ticket1455.ApplicationConfig threw exception
java.lang.NullPointerException
at org.eclipse.persistence.internal.descriptors.InstanceVariableAttributeAccessor.getAttributeValueFromObject(InstanceVariableAttributeAccessor.java:83)
at org.eclipse.persistence.mappings.DatabaseMapping.getAttributeValueFromObject(DatabaseMapping.java:691)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.compareObjects(AbstractDirectMapping.java:412)
at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.compareForChange(AbstractDirectMapping.java:386)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.createObjectChangeSetThroughComparison(DeferredChangeDetectionPolicy.java:192)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.createObjectChangeSet(DeferredChangeDetectionPolicy.java:152)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChanges(DeferredChangeDetectionPolicy.java:95)
at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChangesForExistingObject(DeferredChangeDetectionPolicy.java:61)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(UnitOfWorkImpl.java:713)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1568)
at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.issueSQLbeforeCompletion(UnitOfWorkImpl.java:3258)
at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.issueSQLbeforeCompletion(RepeatableWriteUnitOfWork.java:357)
at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:160)
at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:70)
at com.sun.enterprise.transaction.JavaEETransactionImpl.commit(JavaEETransactionImpl.java:480)

When not using Left Join Fetch, no error occurs.

Named Query

When defining a NamedQuery that has EclipseLink hints, the query fails with an exception

Exception [EclipseLink-7081] (Eclipse Persistence Services - 2.7.6.payara-p1): org.eclipse.persistence.exceptions.ValidationException
Exception Description: The aggregate object [class be.rubus.payara.support.ticket1455.model.Tag] cannot be directly registered in the UnitOfWork. It must be associated with the source (owner) object.
at org.eclipse.persistence.exceptions.ValidationException.cannotRegisterAggregateObjectInUnitOfWork(ValidationException.java:622)

The offending NamedQuery, org.eclipse.persistence.config.QueryHints

@NamedQuery(
        name = "getAllBlogPosts_fail",
        query = "SELECT i FROM BlogPost i",
        hints = {
                @QueryHint(
                        name = QueryHints.REFRESH,
                        value = HintValues.TRUE
                ),
                @QueryHint(
                        name = QueryHints.LEFT_FETCH,
                        value = "i.tags"
                )
        }
)

[rfelcman]

Sorry, but NullPointerException handling in this context doesn't suite project coding style.
It looks like more some workaround.
Please add test there which is used as a descriptor and prevent any regression in the future.
Good candidate for a test is following Maven module/location.
https://github.com/eclipse-ee4j/eclipselink/tree/master/jpa/eclipselink.jpa.testapps/jpa.test.fetchgroups/src/test/java/org/eclipse/persistence/testing/tests/jpa/fetchgroups

[kalinchan]

Do you have a suggestion on how this should be handled instead?

[rfelcman]

Find where NPE happens and avoid this call by something like if (someObject != null) .....

[lukasj]

well, the proper way is to figure out what is null and if it can be null - if yes adding a null check is appropriate and if not - which is more likely - something needs to be set by some other code on a different place

[lukasj]

also from the stack trace - it looks like this happens with no weaving. Does it work with dynamic or static weaving on?