1 3 4 5 6 7 Previous Next 96 Replies Latest reply: Jul 31, 2012 1:14 PM by Jakub Narloch Go to original post RSS
  • 75. Re: GSoC - Arquillian Spring Integration
    Dan Allen Master

    You're getting this error because you are including the Java EE APIs twice, once in the main dependency list and once when you include the Embedded GlassFish library (Embedded GlassFish bundles the Java EE APIs). The best practice is to only include the Java EE APIs in a Maven profile, and leave them out of profiles for embedded containers.

     

    I haven't had a chance to do a full review yet, but I have made some recommended changes. I sent https://github.com/jmnarloch/arquillian-container-spring/pull/1 to:

     

    • update the dependency configuration to be consistent with the Arquillian best practices
    • get the integration tests working in Embedded GlassFish

     

    The tests only work on Embedded GlassFish in the Servlet 3 integration test module. They don't work on the Servlet 2.5 integration test module because you have the VFSClassPathXmlApplicationContext hardcoded in the test.

     

    @SpringConfiguration(value = {"applicationContext.xml"}, contextClass = VFSClassPathXmlApplicationContext.class)
    

     

    This context class is only applicable to JBoss AS, so it should be clear why it cases the test to fail on Embedded GlassFish. You may want to consider making this setting an external configuration (such as in arquillian.xml or arquillian.properties). Another option is to allow multiple contextClasses to be specified and only select the one that loads properly. We may have to think more about it.

  • 76. Re: GSoC - Arquillian Spring Integration
    Dan Allen Master

    To really test the Servlet 2.5 support, I recommend running the tests on Managed Tomcat 6  (or Embedded, but I prefer Managed). You'll face the same problem w/ the contextClass setting though, so you may need to resolve that first.

  • 77. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    Thanks Dan, this exactly what I was looking for. I had applied the changes.

     

     

    Dan Allen wrote:

     

    You're getting this error because you are including the Java EE APIs twice, once in the main dependency list and once when you include the Embedded GlassFish library (Embedded GlassFish bundles the Java EE APIs). The best practice is to only include the Java EE APIs in a Maven profile, and leave them out of profiles for embedded containers.

     

    I haven't had a chance to do a full review yet, but I have made some recommended changes. I sent https://github.com/jmnarloch/arquillian-container-spring/pull/1 to:

     

    • update the dependency configuration to be consistent with the Arquillian best practices
    • get the integration tests working in Embedded GlassFish

     

    The tests only work on Embedded GlassFish in the Servlet 3 integration test module. They don't work on the Servlet 2.5 integration test module because you have the VFSClassPathXmlApplicationContext hardcoded in the test.

     

    @SpringConfiguration(value = {"applicationContext.xml"}, contextClass = VFSClassPathXmlApplicationContext.class)

     

    You're entirely correct, the tests for Spring 2.5 in current form were suppose to run only in JBoss so it's my omission to include the profile for the Glassfish.

    It dosen't seem that making a custom context class configurable through a arquillian.xml will be much problem. The question is, if I would like to use current implementation, will I be able to access the descriptor from the container? I already know that there is no problem with that on the "client" side, but is it possible to do that from test deployment?

  • 78. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    Hi Dan,

     

    I had made the initial support for registering the context class through arquillin.xml, but still I will have to add additional tests for that.

  • 79. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    Good news.

     

    The integration test for Glassfish are running correctly.

  • 80. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    Hi again,

     

    I came up with new idea. Currently Spring 3 extension doesn't allow activating Spring profiles (http://blog.springsource.com/2011/06/21/spring-3-1-m2-testing-with-configuration-classes-and-profiles/) I would like to add the @SpringActiveProfiles annotation. The only problem is that the profiles and supporting environement hasn't been introduced until Spring 3.1. So the question is if introducing third artifact for Spring 3.1 would be a good idea?

     

    Another idea would be to introduce a way for configuring the strategy for creating and destroying application context e.g. after executing test class or after each test method (this resembles the Spring @DirtiesContext - http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/test/annotation/DirtiesContext.html) I would like to introduce a annotation for that, currently thinking a name for it.

  • 81. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    On the implementation side my solution for above problem would be introducing ApplicationContext lifecycle events, in particular:

    • ApplicationContextCreatead
    • ApplicationContextInvalidated
    • ApplicationContextDestroyed

     

    Then I could simply add the proper handler for e.g. activating proper profile or for destroying the context after execution of the test method.

  • 82. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    New thought based on todays discusion with Marius:

     

    In future version the artifacts should be structured rather by functionality then the version of the Spring that they are ment for, so I propose introducing fallowing artifacts:

     

    • arquillian-service-deployer-spring-core
    • arquillian-service-deployer-spring-inject
    • arquillian-service-deployer-spring-javaconfig
    • arquillian-service-deployer-spring-profiles

     

    We could also create "pre-configured" Maven BOM for concreate spring version (like for example: arquillian-service-deployer-spring-2.5, arquillian-service-deployer-spring-3.0, arquillian-service-deployer-spring-3.1),

    although that would still require to explicilty add the <dependency/> tags in the project pom with all the required artifacts.

  • 83. Re: GSoC - Arquillian Spring Integration
    Dan Allen Master

    That's definitely a good idea to consider. And BOMs are always good to keep version management DRY.

     

    Keep in mind we are also working from the other end by proposing the @ExcludeServices annotation which allows you to disable services available to the deployment despite what is on the classpath. See https://issues.jboss.org/browse/ARQ-918

     

    One way to avoid explicit dependency tags in the project pom is to honor a standard syntax for property names that represent versions. That way, you can use Maven property references to define all the versions, without having to include dependencies explicitly. That might even be a nice feature for ShrinkWrap Resolvers, though you could implement it ahead of time in the Spring extension.

  • 84. Re: GSoC - Arquillian Spring Integration
    Dan Allen Master

    I like the idea to support profiles and I also like the idea of using events.

     

    Keep in mind that there are two parts of introducing an event. You can fire the event into the Arquillian runtime, which you can observe using an Arquillian observer extension [1]. You can also route that event to the test so that you can create observer methods in the test class out of the box. I'm open to providing both.

     

    [1] example: https://github.com/arquillian/arquillian-showcase/blob/master/extensions/lifecycle/src/main/java/org/jboss/arquillian/showcase/extension/lifecycle/LifecycleExecuter.java

  • 85. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    After the release of Alpha 1 of the extension there is a plan to improve it farther by implementing fallowing functionality:

     

    • ARQ-219 - implement an embedded container, the advantage may be reduced test execution time

     

    • ARQ-958 - support for Spring declarative transactions and wrapper around PlatformTransactionManager.

     

    • ARQ-959 -  enabling Spring profiles for the given tests case.
  • 86. Re: GSoC - Arquillian Spring Integration
    Aslak Knutsen Master

    Jakub Narloch wrote:

     

    • ARQ-958 - support for Spring declarative transactions and wrapper around PlatformTransactionManager.

     

    The Arquillian Persistence Extension also support Transactions: https://github.com/arquillian/arquillian-extension-persistence/blob/master/api/src/main/java/org/jboss/arquillian/persistence/Transactional.java

     

    While it's nice to support the native programming models Transactions annotations, you tend to end up with a sligtly different usecase when using them for Testing. e.g. Rollback in After: https://github.com/arquillian/arquillian-extension-persistence/blob/master/api/src/main/java/org/jboss/arquillian/persistence/TransactionMode.java

     

    It's been in the back of my head that Transaction should probably be it's own extension. If we extracted it out from Persistence Extension, Transactions could be used for resources outside of JPA, for instance JMS. And with a defined SPI, the same extension could also be used by the Spring extension. Then Spring only knows how to get the Spring Framework TransactionManager, the Transaction Extension handles all the comit/rollback logic.

  • 87. Re: GSoC - Arquillian Spring Integration
    Aslak Knutsen Master

    Jakub Narloch wrote:

     

    In future version the artifacts should be structured rather by functionality then the version of the Spring that they are ment for, so I propose introducing fallowing artifacts:

     

    • arquillian-service-deployer-spring-core
    • arquillian-service-deployer-spring-inject
    • arquillian-service-deployer-spring-javaconfig
    • arquillian-service-deployer-spring-profiles

     

     

    In the new Arquillian lingo, a service-deployer will only handle the 'packaging/preparation' of running the Service(Spring) in a non native supported Container. The general framework integration would be called Service Integration. The Service Integration bits should be reused between the native supported containers(e.g. Spring Embedded Container) and Service Deployer + Other Container (e.g. Spring Deployer 2.5 and JBoss AS)

     

    Naming would in that case be:

     

    * arquillian-service-deployer-spring-2.5

    * arquillian-service-deployer-spring-3.0 (if there is a difference in packaging between between versions)

    * arquillian-service-integration-spring-inject

    * arquillian-service-integration-spring-javaconfig

    * arquillian-service-container-spring-2.5

    * arquillian-service-container-spring-3.0 (if there is a difference in starting the spring contianer between versions)

  • 88. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

     

    Aslak Knutsen wrote:

     

    The Arquillian Persistence Extension also support Transactions: https://github.com/arquillian/arquillian-extension-persistence/blob/master/api/src/main/java/org/jboss/arquillian/persistence/Transactional.java

     

    While it's nice to support the native programming models Transactions annotations, you tend to end up with a sligtly different usecase when using them for Testing. e.g. Rollback in After: https://github.com/arquillian/arquillian-extension-persistence/blob/master/api/src/main/java/org/jboss/arquillian/persistence/TransactionMode.java

     

    It's been in the back of my head that Transaction should probably be it's own extension. If we extracted it out from Persistence Extension, Transactions could be used for resources outside of JPA, for instance JMS. And with a defined SPI, the same extension could also be used by the Spring extension. Then Spring only knows how to get the Spring Framework TransactionManager, the Transaction Extension handles all the comit/rollback logic.

     

     

    Sounds good.

     

    Besiclly I could extract the API for transaction support plus the https://github.com/arquillian/arquillian-extension-persistence/blob/master/impl/src/main/java/org/jboss/arquillian/persistence/core/lifecycle/TransactionHandler.java. Then transactions handling  could be delegated to concreate implementation through events.

     

    Do you have any preferences for namming, also where would You like to put this new extension?

  • 89. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    I had open a new discussion reagarding the deployer issue: https://community.jboss.org/message/738328#738328. The only difference would be probobly the default version of the packaged Spring artifacts.

     

    As for the container I have to explore this area in grater depth, currently I'm not sure if we can have something like standalone Spirng container it would be rather a combination of spring-container spring-deployer and for example spring-inject to be able to run any kind of tests.

     

    I also see potential need of spliting the spring-inject into spring-inject-2.5 and spring-inject-3

    Aslak Knutsen wrote:

     

    In the new Arquillian lingo, a service-deployer will only handle the 'packaging/preparation' of running the Service(Spring) in a non native supported Container. The general framework integration would be called Service Integration. The Service Integration bits should be reused between the native supported containers(e.g. Spring Embedded Container) and Service Deployer + Other Container (e.g. Spring Deployer 2.5 and JBoss AS)

     

    Naming would in that case be:

     

    * arquillian-service-deployer-spring-2.5

    * arquillian-service-deployer-spring-3.0 (if there is a difference in packaging between between versions)

    * arquillian-service-integration-spring-inject

    * arquillian-service-integration-spring-javaconfig

    * arquillian-service-container-spring-2.5

    * arquillian-service-container-spring-3.0 (if there is a difference in starting the spring contianer between versions)

1 3 4 5 6 7 Previous Next