Search code examples
javadatabasespringdaoapplicationcontext

Spring: run code before a persistence context is loaded


I have spring based multimodule application. And in my DAO module the DB (embedded derby) is started and created by the class the implements ApplicationListener.

Problem that in the logs the huge stacktrace from Spring which say that there is no db(couldn't get connection).

Still, my application works without any problems. This stacktrace appeared before the ApplicationListener invoked and the db is created. Actually, I see it only when I am starting the application the first time on the machine, because the db created only this time, than it just used.

So my question is whow to avoid this exception in logs? Maybe there is spring or hibenate setup not connect to the db before the application context fully loaded? Or invoke the code that creates db by some other listener?


Solution

  • Well here is the way I do : the ROOT context contains the datasource, the dao, the service and the transaction manager. In XML config, the declaration of the database is :

    <bean id="datasource" class="org.springframework.jdbc.datasource.DriverManagerDataSource"
          p:url="jdbc:derby:/path/to/database;create=TRUE" 
          p:username="user" p:password="pwd"
          p:driverClassName="org.apache.derby.jdbc.EmbeddedDriver"/>
    

    it can then be used to declare a session factory for hibernate and an associated DAO as :

    <bean class="org.springframework.orm.hibernate4.LocalSessionFactoryBean"
          id="sessionFactory" p:dataSource-ref="datasource">
        <!-- hibernate config -->
        ...
    </bean>
    <bean class="org.springframework.orm.hibernate4.HibernateTransactionManager"
          name="transactionManager" p:sessionFactory-ref="sessionFactory"/>
    <tx:annotation-driven transaction-manager="transactionManager"/>
    <bean id="myDao" class="... .myDaoImpl" p:sessionFactory-ref="sessionFactory" .../>
    

    That way all is created by spring, that ensures that the creation order is correct. Of course the same is possible in Java config with the same logic.