1 2 3 4 5 Previous Next 96 Replies Latest reply: Jul 31, 2012 1:14 PM by Jakub Narloch Go to original post RSS
  • 30. Re: GSoC - Arquillian Spring Integration
    Jakub Narloch Novice

    I had some time to work a bit more on the code and experiment with it.

     

    I had added a @SpringWebConfiguration that marks that the beans in annotated test should be injected from WebApplicationContext. So now it's possible to run very simple tests of Spring MVC controllers in the container.

     

    More details can be found here: https://github.com/jmnarloch/arquillian-container-spring

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

    I take a look in the Spring internals more deeply.

    Until now I'd though that it's only possible to enquire the Spring root web context, created by ContextLoaderListener or ContextLoaderServlet, but after some research I have found that by default each DispatcherServlet publishes it's own application context in ServletContext as an attribute. That gives some extra possibilites.

     

    So, my question is, is it possible to inject into Arquillian extension a ServletContext?

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

    I've figure out that I'm abble to get the ServletContext directly through the Web Root ApplicationContext and use it to get the ApplicationContext published by specific DispatcherServlet.

     

    I'm thinking about doing a little change in the @SpringWebConfiguration and add additional servletName property that would specify which servlet application context should be accessed.

    When the property wouldn't be specified than the extension would still try to use the root application context.

     

    @SpringWebConfiguration(servletName = "emplyeeApp")
    public class EmployeeControlerTestCase {
    
    }
    

     

     

    Configuring an app for testing would only require to include the ContextLoaderListener in web.xml:

     

    <listener> 
      <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> 
    </listener>
    

     

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

    Jakub,

     

    I want to start by saying that I'm really excited to see your proposal and I think you are on a great path already to a successful project, if you get accepted for it. We'd be glad to have your participation either way.

     

    To answer your question:

     

    I was thinking, how about introducing a Google Guice support in Arquillian?

     

    I'am gessing the reasons why would You like to have Spring support. Spring provides entire stack for developing applications while Guice is only IOC container, but still I

    find Guice as a very friendly framework in terms of usage. It's very lightweight and it gives You entire freedom for various usages from standalone applications to web and enterpise apps.

     

    The only reason we have omitted Guice so far is because we didn't want to get too optimistic. We've been waiting on the Spring extension to take shape for so long, we'd be happy just to say we got that done finally. It's also the bigger audience compared to Guice, so it's definitely the right place to focus first. If you finish up with the Spring extension and want to get "extra credit", by all means, please do explore the Guice extension as well. Trust me, we will give you lots of credit for your extra work (e.g., http://arquillian.org/community/contributors).

     

    Good luck!

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

    Thanks Dan,

     

    I have to say that I find this project as the one of the coolest things I had done so far, so You can count on me.

  • 35. Re: GSoC - Arquillian Spring Integration
    Marius Bogoevici Expert

    Hey Jakub,

     

    This looks like a very good start!

     

    Cheers,

    Marius

  • 36. Re: GSoC - Arquillian Spring Integration
    Paulo Silva Newbie

    Hi Jakub,

     

    Very promissing work!

    I was looking to use Arquillian with my project (maven, jboss 4.2.3, spring 2.5.6) and I was wondering if the current "prototype" already supports this environment and what libs do I have to add to my pom.xml to make it work.

     

    If you can provide me a bit more instructions I can test it in my environment, just apologize me because I know 0 about arquillian

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

    Hi,

     

    I'm affraid that currently the extension could be used for testing Spring 3.0 and above, due to existing references to AnnotationConfigApplicationContext. Let me see if there will be posibility to add support for previouse versions.

     

    Guys, let me ask You a question, what would be Yours approach for supporting legacy Spring versions? Seperate artefacts maybe?

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

    That's correct Jakub. The way we handle supporting different API versions of services and containers is to version the Maven artifacts. Typically this involves also creating a common module where generic code can go.

     

    A good example is to see the GlassFish container. It uses all the conventions that we've established.

     

    https://github.com/arquillian/arquillian-container-glassfish

     

    You can extropolate from there.

  • 39. Re: GSoC - Arquillian Spring Integration
    Marius Bogoevici Expert

    Jakub,

     

    You can have various artifacts for different capabilities - e.g. Spring JavaConfig can get its own artifact.

     

    Or the extension can detect if classes like AnnotationConfigApplicationContext are available at runtime - and if they're not, just fail the test stating that the Spring version used in the test does not support that use case. In fact, it seems to me that being able to target specific Spring versions in the tests makes them more accurate.

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

    I had restructured the code and added seperate modules:

     

    arquillian-spring-common (depends on Spring 2.5.x, javee 5)

    arquillian-spring-2.5 (depends on Spring 2.5.x)

    arquillian-spring-3 (depends on Spring 3.x)

     

    All the depedencies mentioned above are optional.

     

    After that change it would be also possible to write and run tests agains Spring Framework 2.5.x.

     

    I had also added support for configuring the extension with arquillian descriptor.

    It's posible to specify whether the extension should auto package the spring-context and spring-web and also set the concreate Spring artifact version to be used for test deployments.

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

    Thanks guys, I got the official info from melange.

     

    BTW the google page didn't stand a chance with 4 thousand students "DDOS-ing" their page.

     

    As for the project I'm going to ask for in-depth review of the test enricher within next week or two. After having that done we can decide what to do next and  what should I focus later on.

    I think that enricher itself is already quite functional so I'd rather focus on the unit and integration tests together with examples that would demonstrate the usage.

     

    I already have some ideas for the mvc testing support, but let's left that for later for now.

     

    Also, let me thank You for Your trust.

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

    Thank you Jakub, 'official' gsoc welcome !

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

    Congratulations Jakub! For you, this is going to be the Google Spring of Code hehehe

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

    Jakub Narloch wrote:

     

    I had restructured the code and added seperate modules:

     

    arquillian-spring-common (depends on Spring 2.5.x, javee 5)

    arquillian-spring-2.5 (depends on Spring 2.5.x)

    arquillian-spring-3 (depends on Spring 3.x)

     

    All the depedencies mentioned above are optional.

     

    After that change it would be also possible to write and run tests agains Spring Framework 2.5.x.

     

    I had also added support for configuring the extension with arquillian descriptor.

    It's posible to specify whether the extension should auto package the spring-context and spring-web and also set the concreate Spring artifact version to be used for test deployments.

     

    Nice work. This configuration for bundling artifacts is very similar to what the Seam extension does, so any innovation here is likely going to help this class of extension. We talked about it a bit in the thread about what's next for the Seam 2 extension.

     

    Perhaps start a design thread about the best way to handle auto packaging of a bundled service. A bundled service is any service that is not provided by the container (and thus must be bundled, or packaged, in the deployment). Spring and Seam 2 are obvious examples. Another example is Hibernate.

     

    Keep up the great work!

1 2 3 4 5 Previous Next