Tapestry 5
  1. Tapestry 5
  2. TAP5-631

Contributed ApplicationInitializer not always executed when using tapestry-spring

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 5.1.0.0, 5.1.0.1, 5.1.0.2, 5.1.0.3
    • Fix Version/s: 5.1.0.4
    • Component/s: tapestry-spring
    • Labels:
      None

      Description

      I noticed something very odd : sometimes the ApplicationInitilizer is not executed. The difference between two launches ? At first sight : none (no code changed, db is always recreated).

      What I am sure of :

      • ApplicationInitializer ( and my contribution ) is always created : I can see them in logs
      • I don't change anything between 2 tries. Just "maven jetty:run" launched from Eclipse, then stop then launched again.
      • If I execute the same app with T5.0.18 => No problem : ApplicationInitializer is always launched
      • If I switch back to T5.1.0.2 => random phenomenon appears again

      At this point... I am not sure it is a real bug... But I don't know were to look at. One thing is important. This behaviour occured after I added Spring/JPA (before that I was using tapestry-hibernate Module).

      This are the result of two consecutive launches :

      Success :

      [INFO] services.PlanningModuleInitializer Create PlanningModuleInitializer
      >>>>>>>>>>>>>>>> PlanningModuleInitializer.initializeApplication <<<<<<<<<<<<<<<<<<<<<<<
      Hibernate: select count as col_0_0_ from TBL_USER userimpl0_ limit ?
      [DEBUG] impl.AbstractDaoImpl Count 'class com.makheia.planning.model.impl.UserImpl' Entities : 0 records
      [INFO] impl.UserDaoImpl Initialising UserDao default datas
      Hibernate: select userfuncti0_.USERFUNCTION_ID as USERFUNC1_3_3_, [............]
      [DEBUG] impl.AbstractDaoImpl Persisting class com.makheia.planning.model.impl.UserImpl - Object : [User [Id=0][FullName=admin admin][Email=admin@localhost]]
      [DEBUG] interceptors.TimeStampInterceptor Update [createdDate] value to Mon Apr 06 13:14:47 CEST 2009
      [DEBUG] interceptors.TimeStampInterceptor Update [updatedDate] value to Mon Apr 06 13:14:47 CEST 2009
      [DEBUG] interceptors.TimeStampInterceptor Change TimeStamp before saving [[User [Id=0][FullName=admin admin][Email=admin@localhost]]] : TS = Mon Apr 06 13:14:47 CEST 2009
      Hibernate: insert into TBL_USER (TS_CREATEDDATE, TS_LASTMODIFIEDBY, TS_UPDATEDDATE, USER_ACCOUNT_NON_EXPIRED, USER_ACCOUNT_NON_LOCKED, USER_CREDENTIALS_NON_EXPIRED, USER_EMAIL, USER_ENABLED, USER_FIRSTNAME, USER_GROUP_ID, USER_LASTNAME, USER_PASSWORD, USER_PHONENUMBER, USER_SALUTATION, userFunction, USER_USERNAME) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
      [INFO] spring.SpringModule Spring version 2.5.6 with 58 defined beans.

      Failure (launched 10 sec later without changing anything) :

      [INFO] services.PlanningModuleInitializer Create PlanningModuleInitializer
      [INFO] spring.SpringModule Spring version 2.5.6 with 58 defined beans.

      1. Planning.zip
        144 kB
        Martin Papy

        Activity

        Hide
        Martin Papy added a comment -

        This is a working copy of the project I work on.

        With command line you should just have to run mvn jetty:run (It runs with HSQLDB)

        Show
        Martin Papy added a comment - This is a working copy of the project I work on. With command line you should just have to run mvn jetty:run (It runs with HSQLDB)
        Hide
        Howard M. Lewis Ship added a comment -

        If you could remove all the Spring related code contributed into the ApplicationInitializer service configuration and verify that it all runs, that would be helpful. I suspect that this is Spring related.

        Show
        Howard M. Lewis Ship added a comment - If you could remove all the Spring related code contributed into the ApplicationInitializer service configuration and verify that it all runs, that would be helpful. I suspect that this is Spring related.
        Hide
        Martin Papy added a comment -

        You are right. As soon as I comment the piece of code that calls the Spring service involved, the initializeApplication(context,initilizer) is allways called again...

        Here I just commented the line >>> aDaoService.initDao();

        public void initializeApplication(Context context, ApplicationInitializer initializer) {
        for (DaoService<?> aDaoService : _lDaoServices)

        { aDaoService.initDao(); }

        initializer.initializeApplication(context);
        }

        Show
        Martin Papy added a comment - You are right. As soon as I comment the piece of code that calls the Spring service involved, the initializeApplication(context,initilizer) is allways called again... Here I just commented the line >>> aDaoService.initDao(); public void initializeApplication(Context context, ApplicationInitializer initializer) { for (DaoService<?> aDaoService : _lDaoServices) { aDaoService.initDao(); } initializer.initializeApplication(context); }
        Hide
        Martin Papy added a comment -

        If I replace tapestry-spring 5.1.0.x module with 5.0.18 version of the same module (leaving the rest of the app in 5.1.0.x) => Bug disappear

        Show
        Martin Papy added a comment - If I replace tapestry-spring 5.1.0.x module with 5.0.18 version of the same module (leaving the rest of the app in 5.1.0.x) => Bug disappear
        Hide
        Howard M. Lewis Ship added a comment -

        There are differences between tapestry-spring 5.0.18 and 5.1.0.x that are documented in the upgrade notes. You can set a servlet-context parameter to revert to 5.0.18 behavior, or make minor changes to your configuration to use 5.1.0.x behavior.

        Show
        Howard M. Lewis Ship added a comment - There are differences between tapestry-spring 5.0.18 and 5.1.0.x that are documented in the upgrade notes. You can set a servlet-context parameter to revert to 5.0.18 behavior, or make minor changes to your configuration to use 5.1.0.x behavior.
        Hide
        Martin Papy added a comment -

        Heu... I already read the upgrade notes. I correctly set the parameter to use external spring context ( ie : tapestry.use-external-spring-context ).

        It does not explain me why with tapestry-spring 5.1.0.x the ApplicationInitializer is launched correctly on about 50% of the launches...

        Show
        Martin Papy added a comment - Heu... I already read the upgrade notes. I correctly set the parameter to use external spring context ( ie : tapestry.use-external-spring-context ). It does not explain me why with tapestry-spring 5.1.0.x the ApplicationInitializer is launched correctly on about 50% of the launches...
        Hide
        Howard M. Lewis Ship added a comment -

        Try explicitly ordering your initializer after SpringContextInitialization.

        I think what's happening is that initialization is happening in a somewhat random order, with the necessary Spring initialization happening in the middle. Explicit ordering will solve that problem.

        Show
        Howard M. Lewis Ship added a comment - Try explicitly ordering your initializer after SpringContextInitialization. I think what's happening is that initialization is happening in a somewhat random order, with the necessary Spring initialization happening in the middle. Explicit ordering will solve that problem.
        Hide
        Howard M. Lewis Ship added a comment -

        Ah, here's the problem. the SpringContextInitialization filter doesn't continue the initialization chain; anything contributed after it (or otherwise ordered after it) does not execute! Sorry I closed this earlier, this is a definite bug.

        Show
        Howard M. Lewis Ship added a comment - Ah, here's the problem. the SpringContextInitialization filter doesn't continue the initialization chain; anything contributed after it (or otherwise ordered after it) does not execute! Sorry I closed this earlier, this is a definite bug.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Martin Papy
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development