Class DataSourceConfig

java.lang.Object
ubic.gemma.core.config.DataSourceConfig
@Configuration public class DataSourceConfig extends Object
Renovations Phase 3: Java-config replacement for applicationContext-dataSource.xml.

Ports four concerns from the XML, preserving bean ids exactly (the dataSource id is referenced by name from applicationContext-hibernate.xml's sessionFactory, from applicationContext-dataSourceInitializer.xml's test-profile DataSourceInitializer beans, and from many @Autowired DataSource injections in persistence code — breaking the name would break the world):

  1. Production / dev dataSource — Hikari, pointed at gemma.db.*.
  2. Test dataSource — Hikari, pointed at gemma.testdb.*.
  3. groupAgentSecurityContext — lazy factory bean used by the scheduler to run scheduled jobs under the GROUP_AGENT identity; the test profile uses different credentials.
  4. mailSender — real JavaMailSenderImpl in production, a DummyMailSender elsewhere.
The XML also declared two stub java.lang.Object beans named createDatabaseInitializer and dataSourceInitializer under the production/dev profile so that applicationContext-hibernate.xml's depends-on="createDatabaseInitializer" would resolve. In the test profile, applicationContext-dataSourceInitializer.xml provides real DataSourceInitializer beans under the same ids. We preserve that arrangement by declaring the stubs here under @Profile("!test & !testdb"); the test-profile XML's beans then live alongside (different profile) without collision.

The MySQL-specific connection properties bean (dataSourceProps) is preserved as a private helper rather than a Spring bean — it was only ever referenced by the two dataSource bean definitions in the same XML, never by name from outside.

  • Constructor Details

    • DataSourceConfig

      public DataSourceConfig()

  • Method Details

    • maxExecutionTimeOf

      @Nullable public static Long maxExecutionTimeOf(@Nullable String sessionVariables)
      Read back the statement timeout withMaxExecutionTime(String, String) composed, in milliseconds, or null when the list carries none.

      It lives beside the composer so the two cannot drift, and it exists because the setting is otherwise invisible from outside the JVM: the deployment sets an environment variable, the variable becomes a Connector/J property, and nothing between there and MySQL says whether it arrived. GET /admin/db/pool reports what this returns, so "is the cap on?" is a question the running server answers about itself rather than one answered by reading env files and inferring.

      Parameters:
      sessionVariables - a Connector/J session-variable list, possibly null

    • dataSource

      @Bean(name="dataSource", destroyMethod="close") @Profile({"production","dev"}) public DataSource dataSource(@Value("${gemma.db.user}") String user, @Value("${gemma.db.password}") String password, @Value("${gemma.db.url}") String url, @Value("${gemma.db.maximumPoolSize}") int maximumPoolSize, @Value("${gemma.db.minimumIdle}") int minimumIdle)
      Production / dev datasource. Active under the production and dev profiles (Gemma uses the same physical database in both — dev points at the prod schema for local-against-prod debugging; only the connection pool sizes differ via gemma.db.* property overrides).

    • testDataSource

      @Bean(name="dataSource", destroyMethod="close") @Profile({"test","testdb"}) public DataSource testDataSource(@Value("${gemma.testdb.user}") String user, @Value("${gemma.testdb.password}") String password, @Value("${gemma.testdb.url}") String url, @Value("${gemma.testdb.maximumPoolSize}") int maximumPoolSize, @Value("${gemma.testdb.minimumIdle}") int minimumIdle)
      Test datasource. Active under test (unit + integration tests) and testdb (Flyway baseline / migration verification against a disposable schema). Bean id is the same as the prod datasource — only one of the two definitions is active at a time, so downstream @Autowired DataSource injections work uniformly. The test-profile DataSourceInitializer beans in applicationContext-dataSourceInitializer.xml reference dataSource by name and so consume whichever of these two is active.

    • groupAgentSecurityContext

      @Bean(name="groupAgentSecurityContext") @Lazy @Profile({"production","dev"}) public ManualAuthenticationServiceBasedSecurityContextFactory groupAgentSecurityContext(ManualAuthenticationService manualAuthenticationService, @Value("${gemma.agent.userName}") String userName, @Value("${gemma.agent.password}") String password)
      Lazy factory for the GROUP_AGENT SecurityContext. Only built when the scheduler actually launches a job. Active under production / dev where gemma.agent.* properties are populated.

      Returned as the ManualAuthenticationServiceBasedSecurityContextFactory (a Spring FactoryBean); Spring unwraps it for @Autowired SecurityContext injections and exposes it as the raw factory for BeanFactory#getBean("&...") callers.

    • testGroupAgentSecurityContext

      @Bean(name="groupAgentSecurityContext") @Lazy @Profile({"test","testdb"}) public ManualAuthenticationServiceBasedSecurityContextFactory testGroupAgentSecurityContext(ManualAuthenticationService manualAuthenticationService, @Value("${gemma.testdb.agent.userName}") String userName, @Value("${gemma.testdb.agent.password}") String password)
      Test-profile variant of groupAgentSecurityContext(ManualAuthenticationService, String, String): same bean id, different credential keys (gemma.testdb.agent.*) so test runs don't authenticate against production credentials.

    • mailSender

      @Bean(name="mailSender") @Profile("production") public org.springframework.mail.MailSender mailSender(@Value("${mail.host}") String host, @Value("${mail.protocol}") String protocol, @Value("${mail.username}") String username, @Value("${mail.password}") String password)

    • dummyMailSender

      @Bean(name="mailSender") @Profile("!production") public org.springframework.mail.MailSender dummyMailSender()

    • createDatabaseInitializerStub

      @Bean(name="createDatabaseInitializer") @Profile({"production","dev"}) public Object createDatabaseInitializerStub()
      Dummy createDatabaseInitializer stub. applicationContext-hibernate.xml's sessionFactory declares depends-on="createDatabaseInitializer" so that in test runs the empty gemdtest DB exists before Hibernate's hbm2ddl=create fires; the real DataSourceInitializer bean by this id is provided by applicationContext-dataSourceInitializer.xml under @Profile("test"). Outside the test profile that bean isn't loaded, so depends-on would fail resolution — hence the stub here under the complementary profile.

    • dataSourceInitializerStub

      @Bean(name="dataSourceInitializer") @Profile({"production","dev"}) public Object dataSourceInitializerStub()
      Dummy dataSourceInitializer stub. Mirrors createDatabaseInitializerStub(); other beans (test-only) may declare depends-on="dataSourceInitializer" and the legacy XML kept a stub for symmetry. Preserved here verbatim.