9 Replies Latest reply on Jan 2, 2012 4:37 AM by sekt

    JBoss 7 - packed / unpacked EAR deployment differences

    sekt Newbie

      Hello,

       

      shorthand: we've a set of EAR bundles (unpacked) deployed due our development on JBoss 7.0.2-FINAL (e.g. eclipse server configuration).

      This works very fine.

       

      But when we deploy the same set of EAR bundles (packed e.g. with maven), JBoss 7 runs in errors when trying to register timedObjects for some common EJBs bundled within our set of EARs.

       

      Does somebody know this behaviour? What can we do

       

      Thx in advance,

           SK

        • 1. Re: JBoss 7 - packed / unpacked EAR deployment differences
          Wolf-Dieter Fink Master

          I would suppose that the exploded (unpacked) deployment is correct and the deployment packed by maven include some jar's that are provided by JBoss.

           

          Could you post what kind of error do you have and how the structure of both ear's is, maybe you see the difference

          • 2. Re: JBoss 7 - packed / unpacked EAR deployment differences
            sekt Newbie

            Ok - at first - the topic was wrong, because I got confused about the strange behaviour.

             

            I'm now sure, the reason for timedObject registration-errors are not compressed bundles.

             

            Now to the problem:

            Our EARs are very simple and the structure is the same at all:

             

            EAR1

            +-- common.ejb.jar

            +-- bundle1.ejb.jar

             

            EAR1

            +-- common.ejb.jar

            +-- bundle2.ejb.jar

             

            EAR3

            +-- common.ejb.jar

            +-- bundle3.ejb.jar

             

            In both, common and bundleX ejb jars are simple @Stateless EJBs with @Local interfaces. The EJBs are dependants of PersistenceUnits.

            EJBs of 'commen.ejb.jar' are deployed for each EAR. The local binding of common EJBs in that EARs is the same at all.

             

            The build with maven has the same structure and resulting bundles as the IDE build.

             

            I think there is a problem with TimerServiceRegistration, which loggs a warning when sun shines, and stops jboss-deployment if not.

             

            Here are some outputs:

             

            2011-12-21 23:40:30,858 WARN  [org.jboss.as.ejb3.timerservice.mk2.TimerServiceFactoryImpl] (MSC service thread 1-10) Unregistered an already registered Timerservice with id BEAN1 and a new instance will be registered

            2011-12-21 23:40:30,858 WARN  [org.jboss.as.ejb3.timerservice.mk2.TimerServiceFactoryImpl] (MSC service thread 1-13) Unregistered an already registered Timerservice with id BEAN2 and a new instance will be registered

            2011-12-21 23:40:30,860 WARN  [org.jboss.as.ejb3.timerservice.mk2.TimerServiceFactoryImpl] (MSC service thread 1-3) Unregistered an already registered Timerservice with id BEAN3 and a new instance will be registered

            2011-12-21 23:40:30,904 WARN  [org.jboss.as.ejb3.timerservice.mk2.TimerServiceFactoryImpl] (MSC service thread 1-16) Unregistered an already registered Timerservice with id BEAN4 and a new instance will be registered

            2011-12-21 23:40:30,906 WARN  [org.jboss.as.ejb3.timerservice.mk2.TimerServiceFactoryImpl] (MSC service thread 1-15) Unregistered an already registered Timerservice with id BEAN5  and a new instance will be registered

            ..

             

            n.ejb.timerService: Failed to start service

                    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]

                    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.7.0]

                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.7.0]

                    at java.lang.Thread.run(Thread.java:722) [:1.7.0]

            Caused by: java.lang.IllegalStateException: Timer service with timedObjectId: BEANX is already registered

                    at org.jboss.as.ejb3.timerservice.mk2.TimerServiceRegistry.registerTimerService(TimerServiceRegistry.java:44)

                    at org.jboss.as.ejb3.timerservice.mk2.TimerServiceFactoryImpl.createTimerService(TimerServiceFactoryImpl.java:100)

                    at org.jboss.as.ejb3.timerservice.TimerServiceService.start(TimerServiceService.java:71)

                    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]

                    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]

                    ... 3 more

             

            If the same J7AS instance is started from eclipse, the timedObject registration loggs warnings too, but does not leave the jboss-deployment with an error.

             

            Very strange

            • 3. Re: JBoss 7 - packed / unpacked EAR deployment differences
              Wolf-Dieter Fink Master

              I play around with the timer service a couple of days, but 7.1, and I havn't such behaviour (ok I never deployed by eclipse).

              So can you figure out one reason i.e. one of the beans and attach the source of it and the ear?

              Also you might check whether 7.1 works.

              • 4. Re: JBoss 7 - packed / unpacked EAR deployment differences
                Wolf-Dieter Fink Master

                It looks like that the registration of timers will be different for AS7.1. The package ..timerserver.mk2 is not longer available in AS7.1

                I suppose that a registration of similar beans will work with the new version.

                • 5. Re: JBoss 7 - packed / unpacked EAR deployment differences
                  sekt Newbie

                  Ok, thanks Wolf I will try to migrate to 7.1.

                  But can you explain, why timers are necessary for our EJBs? What kind of timing issues are addressed with the timer-registration. We've e.g. no @Schedule annotations at our EJBs. The JBoss is running with standalone-ha. An a MDB (JMS) is used in only one EAR. Does the PersistenceContext require such timer events? I need to understand, how / why JBoss behaves.

                   

                  Thanks,

                       Steffen

                  • 6. Re: JBoss 7 - packed / unpacked EAR deployment differences
                    Wolf-Dieter Fink Master

                    According to the ejb spec the container must provide a timerservice.

                    It might be a bit confusing that all beans are registered without having a timer, but for each SLSB you might start a timer during runtime.

                    So I think this will be the reason why every bean is registered during startup.

                    • 8. Re: JBoss 7 - packed / unpacked EAR deployment differences
                      jaikiran pai Master

                      We did actually fix a similar issue sometime back in 7.x https://issues.jboss.org/browse/AS7-2449. So yeah, try the 7.1.0.CR1 which should work fine.

                      • 9. Re: JBoss 7 - packed / unpacked EAR deployment differences
                        sekt Newbie

                        Hello,

                         

                        the problem seems to be fixed with 7.1.0.CR1

                         

                        Thanks & a happy new year