Issues with FetchType.LAZY and weaving after EL 4.0.x migration

[ADunnOE]

Hello all,

I am working on migrating a legacy Java 11, Spring 5/data/jpa, and EclipseLink 2.7 cloud server application to Java 17, Spring 6.1.x, and EclipseLink 4.0.x. We use load-time-weaving with aspectj and spring-instrument agents.

The specific dependency versions currently in use are:

AspectJ 1.9.22.1
Eclipse Persistence JPA 4.0.4
Jakarta Persistence API 3.1.0
Spring Framework 6.1.14
Spring Data JPA 3.3.5
Spring Security 6.3.4

We use single table multitenancy and heavily rely on FetchType.LAZY for entity relationship mappings (@OneToOne, @OneToMany, etc). I have enabled FINE logging for EclipseLink and confirmed that the entity classes are being found and registered by the EL weaver, with logs such as:

[EL Finer]: weaver: 2024-11-12 22:31:43.751--ServerSession(1790122770)--Class [package.Foo] registered to be processed by weaver.

With the updated dependencies, during server start-up EclipseLink reports the following warning for most/all of our entities that use FetchType.LAZY:

[EL Warning]: metadata: 2024-11-11 16:37:10.357--ServerSession(960557461)-- Reverting the lazy setting on the OneToOne or ManyToOne attribute [foo] for the entity class [class bar] since weaving was not enabled or did not occur.

Previously when we were running Spring 5/EclipseLink 2.7 no warnings of this type were logged. This has led me to believe that the weaving of entity classes is not working correctly, and I have not been able to figure out why. During server start up, we are also seeing exceptions such as:

Exception Description: The method [_persistence_set_foo_vh] or [_persistence_get_foo_vh] is not defined in the object [package.bar].
Internal Exception: java.lang.NoSuchMethodException: package.bar._persistence_get_foo_vh()
Mapping: org.eclipse.persistence.mappings.OneToOneMapping[foo]

I've been able to temporarily get around this issue by deleting the entity relationship mappings/joins out of the entity classes and replacing them with external manual database operations. We only have couple entities that are being accessed while the server is starting up which completely halts it from launching.

However this is only a bandaid fix and does not fix the underlying problem. Certain API's/web pages can be accessed on our site while the user is not logged in and thus not yet associated to a tenant id. In these contexts the 'eclipselink.tenant-id' jpa property is null. When fetching an entity that has a relationship with another entity annotated @Multitenant EclipseLink throws an error such as the following:

[EL Warning]: 2024-11-12 22:31:58.282--UnitOfWork(243428664)--Exception [EclipseLink-6174] (Eclipse Persistence Services - 4.0.4.v202407190748-059428cdd2583c46f1f3e50d235854840a6fa9a7): org.eclipse.persistence.exceptions.QueryException
Exception Description: No value was provided for the session property [eclipselink.tenant-id]. This exception is possible when using additional criteria or tenant discriminator columns without specifying the associated contextual property. These properties must be set through EntityManager, EntityManagerFactory or persistence unit properties. If using native EclipseLink, these properties should be set directly on the session.
Query: ReadObjectQuery(...

We do have a custom implementation of EntityManagerFactory that sets the 'eclipselink.tenant-id' property. I have hit a breakpoint where the exception is being thrown and confirmed that the property does exist in the jpa property map, but it is null (as expected) due to the user being in a tenantless context. I believe the above error is caused by lazy loading being broken, so associated multitenant entities are being eagerly fetched and then failing due to the null tenant id when they were not being fetched previously due to the lazy fetching.

We do not configure EclipseLink through persistence.xml and instead use Java configuration via Spring's LocalContainerEntityManagerFactoryBean:

@Bean
@Primary
public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
    final EclipseLinkJpaVendorAdapter vendorAdapter = new EclipseLinkJpaVendorAdapter();

    final Database dbType = Database.MYSQL;
    final String platform = "org.eclipse.persistence.platform.database.MySQLPlatform";

    vendorAdapter.setDatabase(dbType);
    vendorAdapter.setDatabasePlatform(platform);

    final LocalContainerEntityManagerFactoryBean factory = new MultitenantAwareEntityManagerFactoryBean();
    factory.setJpaVendorAdapter(vendorAdapter);
    factory.setPackagesToScan(ENTITY_PACKAGES_TO_SCAN); // Root project package
    factory.setDataSource(dataSource());
    factory.setJpaDialect(new EclipseLinkJpaDialect());
    factory.setLoadTimeWeaver(loadTimeWeaver); // Using Spring's InstrumentationLoadTimeWeaver

    final Map<String, String> props = new HashMap<>();

    props.put(PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false");
    props.put(PersistenceUnitProperties.WEAVING, "true");
    props.put(PersistenceUnitProperties.WEAVING_LAZY, "true");
    factory.setJpaPropertyMap(props);

    return factory;
}

Our entities are defined like this and share a BaseEntity abstract parent class annotated with @MappedSuperclass:

@Entity
@Table(name = "FOO")
@Multitenant
@TenantDiscriminatorColumn(
        discriminatorType = DiscriminatorType.INTEGER,
        columnDefinition = "BIGINT NOT NULL"
)
public class Foo extends BaseEntity<Long> {
    // Fields
    private Bar bar;
    
    @OneToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "BAR_ID", insertable = false, updatable = false)
    public Bar getBar() { return bar; }

    public setBar(Bar bar) { this.bar = bar; }
}

Apologies for the long-winded post, but I was hoping someone might have some ideas on what is causing our issue with entity weaving and FetchType.LAZY. I am not sure what has changed in between these dependency versions that have caused this issue, and I've been unable to find useful migration documentation between EclipseLink 2.7 and 4.0.x. We are seeing the same issue on EclipseLink 3.x. Thank you for your time, Andrew

[rfelcman]

Maybe this is not related, but we did some AspectJ related fix in #1841
I don't know how AspectJ is used in Your project, but I see there possible collision with EclipseLink weaving.
There are two weavings:

• AspectJ
• EclipseLink props.put(PersistenceUnitProperties.WEAVING, "true"); , generates _persistence_set_foo_vh

try to disable EclipseLink props.put(PersistenceUnitProperties.WEAVING, "false");
or play with order

[ADunnOE]

Thank you for the quick reply. We launch the server with the following JVM -agent args (In this order):

-javaagent:src\agents\aspectjweaver.jar -javaagent:src\agents\spring-instrument.jar

I tried swapping the order of the javaagent arguments but did not see a difference in behavior. We configure aspectj through one of our spring configuration beans:

@Configuration
@EnableSpringConfigured
@EnableLoadTimeWeaving(aspectjWeaving = AspectJWeaving.ENABLED)
@EnableTransactionManagement(mode = AdviceMode.ASPECTJ)
@EnableJpaRepositories(repositoryFactoryBeanClass = MultitenantAwareJpaRepositoryFactoryBean.class, basePackageClasses = {
        // ...
})
public class DataConfig {
    // ...

    @Bean
    @Primary
    public LocalContainerEntityManagerFactoryBean entityManagerFactory() {
        final EclipseLinkJpaVendorAdapter vendorAdapter = new EclipseLinkJpaVendorAdapter();
        
        final Database dbType = Database.MYSQL;
        final String platform = "org.eclipse.persistence.platform.database.MySQLPlatform";
        
        vendorAdapter.setDatabase(dbType);
        vendorAdapter.setDatabasePlatform(platform);
        
        final LocalContainerEntityManagerFactoryBean factory = new MultitenantAwareEntityManagerFactoryBean();
        factory.setJpaVendorAdapter(vendorAdapter);
        factory.setPackagesToScan(ENTITY_PACKAGES_TO_SCAN); // Root project package
        factory.setDataSource(dataSource());
        factory.setJpaDialect(new EclipseLinkJpaDialect());
        factory.setLoadTimeWeaver(loadTimeWeaver); // Using Spring's InstrumentationLoadTimeWeaver
        
        final Map<String, String> props = new HashMap<>();
        
        props.put(PersistenceUnitProperties.CACHE_SHARED_DEFAULT, "false");
        props.put(PersistenceUnitProperties.WEAVING, "true");
        props.put(PersistenceUnitProperties.WEAVING_LAZY, "true");
        factory.setJpaPropertyMap(props);
        
        return factory;
    }
}

I tried setting PersistenceUnitProperties.WEAVING to "false", and you are correct that the _persistence_set_foo_vh related exception no longer occurred, however weaving also appears to not be happening.

On the older Spring 5 + EclipseLink 2.7 version of the project, during the server startup the following code snippet passes and does not throw, but it fails on the updated Spring 6 + EclipseLink 4 version regardless if PersistenceUnitProperties.WEAVING is set to "true" or "false".

import org.eclipse.persistence.internal.weaving.PersistenceWeaved;

//...

UserEntity p = new UserEntity();
if (!(p instanceof PersistenceWeaved)) {
    throw new SecurityException("WeaveTest Failed! UserEntity was not woven!");
}

I attempted to temporarily remove our dependency on AspectJ and replace it with the eclipselink agent to see if it allows the entities to be woven, but our project is heavily dependent on ApsectJ and transactions, so ripping it out is not an easy thing to do. I'm not sure we can do it without significant code changes.

[ADunnOE]

Not sure if it is useful but here's what our aop.xml looks like:

<?xml version="1.0"?>
<aspectj>
    <weaver options="-Xset:weaveJavaxPackages=true -Xreweavable">
        <include within="base_project_package..*"/>
        <include within="org.springframework.data..*"/>
        <include within="jakarta.persistence..*"/>
        <exclude within="base_project_package.configuration.*"/>
    </weaver>
    <aspects>
        <aspect .... />
        <aspect .... />
        <aspect .... />
    </aspects>
</aspectj>

I'm not sure if the -Xset:weaveJavaxPackages=true option is still relevant. I've been unable to find if a java 17/jakarta version of that property exists.