Inject EJB into Eclipselink SessionCustomizer to provide Oracle schema name

Question

In a Java EE 6 application running on GlassFish (3.1.2.2b5), suppose you have a ConfigurationService, which reads some properties files and hands out property values accordingly:

@Local
public interface ConfigurationService { ... }

---

@Singleton  
public class ConfigurationServiceImpl implements ConfigurationService { ... }

There also is an Eclipselink SessionCustomizer, because the schema name of one of the persistence units (Oracle database) in the application needs to be programmatically set, i.e. be configurable from the properties files mentioned before. The SessionCustomizer is configured in a persistence.xml and the implementation contains a reference to the ConfigurationService:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"...
    <persistence-unit name="myPU" transaction-type="JTA">
        <property name="eclipselink.session.customizer" value="MySessionCustomizer"/>
        ...

---

public class MySessionCustomizer implements SessionCustomizer {
    @EJB
    private ConfigurationService configurationService;
    @Override
    public void customize(Session session) {
        session.getLogin().setTableQualifier(configurationService.getSchemaName());
        ...

Is it possible to have the ConfigurationService injected in such a way, so that it's available when the SessionCustomizer is instantiated? The above fails since the ConfigurationService instance is still null, i.e. the injection hasn't happened yet. This observation corresponds to the server's log entries. It seems like the dependency injection mechanism is invariably started after the persistence units - and thus the SessionCustomizer - are instatiated. I've messed around with various annotations (@Startup, @DependsOn(...), ...) but to no avail. Is my conclusion correct or is there another way to have the EJB instantiated and injected sooner?

Answer 1

Since the session customizer is created by EclipseLink (not by your container), the container is not responsible for injecting the dependencies.

Use JNDI lookup.