5 Replies Latest reply on Jun 27, 2014 3:59 AM by tommysdk

    Arquillian + JEE container is too slow

    alberto.gori
    alberto.gori Jun 10, 2014 5:14 PM

      I think that Arquillian is a great project. Anyway I failed to adopt it in my enterprise level application because of a couple of drawbacks.

       

      First, the idea to deploy just some classes using shrinkwrap could be very useful in small and well-designed applications, but become almost useless in large enterprise applications where it is very hard to isolate EJBs that have dependencies with the rest of the application. This means that at the end you just have to deploy the whole application.

       

      Second, although modern Application Servers start very fast, deploying an EAR is still quite time consuming. To reduce startup time you could choose a remote container, but this means that after some tests you got the well-known java.lang.OutOfMemoryError: PermGen space. Also ignoring this problem, deploy remains time consuming.

       

      I have found that running the application without a container (for example as a simple JPA project) is a much faster way to run tests. The problem here is that you have to develop and maintain an home-made container to manage dependecies and interceptors. This approach is hard to develop and error prone.

       

      Here CDI comes to the rescue! Look at this very simple project: https://github.com/NovaTecConsulting/BeanTest. With just a simple CDI extension you can manage EJB dependencies and interceptors without mocks. Ok, it can't be used for real integration tests, anyway it can run 95% of your EJB code wihout a container! And believe me, it is much faster then Arquillian + Application Servers.

       

      Maybe Arquillian could provide something like BeanTest for large enterprise applications that needs to run fast tests. What do you think?

      • 2981 Views
      • Tags:
        • 1. Re: Arquillian + JEE container is too slow
          aslak
          aslak Jun 11, 2014 8:56 AM (in response to alberto.gori)

          note on the technical part of the request;

           

          BeanTest doesn't seem to do much more then boot up a CDI container and introduce a EntityManagerProducer.

           

          Arquillian does have support for Weld-SE/Weld-EE as a Container which just boots up the CDI BeanContainer so that part is 'done'.

          Adding a EntityManagerProducer / TransactionInterceptor to your own test suite should provide the rest.. ?

           

          I think this is a fairly common request as well; something very lightweight, how ever real/fake it might be.

           

          I'd be happy to help guide you in the processes of creating a container like that for Arquillian, Let's call it a non Technology Container, but a Use case container or something..

           

          I think the first step would be to fork the weld-se container, then add some simple mechanics for adding a tiny extension model to create/produce 'non ee' connected versions of ee components (tx, em)

           

          ?

            • Actions
          • 2. Re: Arquillian + JEE container is too slow
            alberto.gori
            alberto.gori Jun 11, 2014 6:16 PM (in response to aslak)

            Thanks Aslak.

             

            Features covered by BeanTest are:

             

            -producing an injectable @PersistenceContext EntityManger

            -enabling transactions ala EJB (rollback if some exception is seen by the interceptor and commit otherwise)

            -replacing every @EJB annotation with @Inject thanks to CDI extensions

             

            and not much more. What is still missing is support for resources injected through @Resource and JNDI.

             

            Why do you suggest a fork of the weld-se-container? Wouldn't be enough to write a CDI extension on top of it or do you see limitations in this approach?

              • Actions
            • 3. Re: Arquillian + JEE container is too slow
              aslak
              aslak Jun 12, 2014 3:06 AM (in response to alberto.gori)

              Just in general to not change the current one into something else. As we start to see how the weld-se-container needs to change based on this, it might simply end up being as you say a few enabled extensions that could be enabled via a flag in the config.. 

                • Actions
              • 4. Re: Arquillian + JEE container is too slow
                alberto.gori
                alberto.gori Jun 12, 2014 12:05 PM (in response to aslak)

                Ok I'll try this route, though I have to read documentation about Arquillian containers first.

                  • Actions
                • 5. Re: Arquillian + JEE container is too slow
                  tommysdk
                  tommysdk Jun 27, 2014 3:59 AM (in response to alberto.gori)

                  "but become almost useless in large enterprise applications" - The problem with most large enterprise applications is that everything is packed in one big fat EAR file that has to be deployed all at once with fingers crossed. It's an architecture model that almost encourages couplings in your codebase, which makes testing slower and unnecessary difficult.. A component based (or micro service) architecture is beneficial not only from a test perspective but also from a development delivery process perspective. I understand that it might not be possible for everyone to redo their whole enterprise architecture, but I think it's still important to highlight that issue. I've used Arquillian for both component based projects as well as the traditional approach where the whole application resides in one big EAR and the component based architecture is not only more attractive from a test perspective but also makes burdens of development, release and deploy easier.

                    • Actions