1 2 Previous Next 24 Replies Latest reply: May 21, 2012 8:44 PM by Dan Allen Go to original post RSS
  • 15. Re: Towards Spring Test Enricher Milesone One
    Dan Allen Master

    Jakub,

     

    I'm glad you asked about the "embedded service container" because I've been meaning to write up a definition.

     

    I'm introducing a new name to make a distinction between:

     

    1. a server
    2. a service

     

    I'm defining a server as something that provides multiple integrated services, such as a Java EE application server or a servlet container, and supports deployments natively.

     

    I'm defining a service as something that provides a single component model or programming model, such as Hibernate, JPA, CDI, EJB or Spring. These technologies don't "boot up" (the way a server does) and they don't accept deployments.

     

    Granted, it's not totally black and white, but for the purpose of our thinking, we'll consider them as distinct.

     

    Spring is a service. You add the service to the container in a different way (in the deployment) than with CDI (provided by the application server). Keep in mind, Weld Servlet provides CDI to a servlet container through the deployment in the same way Spring works. How the service gets into the server is not all that relevant to this terminology.

     

    Here are examples of embedded service containers:

     

    • Weld EE Embedded and Weld SE Embedded
    • OpenWebBeans Embedded
    • OpenEJB Embedded (special case in that it provides multiple services, but still not a container)
    • Hibernate (planned)
    • Spring Embedded

     

    Here are examples of embedded server containers:

     

    • Jetty
    • Tomcat
    • Resin
    • GlassFish
    • WebSphere Application Server

     

    You may wonder why the distinction is important. It matters when you switch to using a server container. In those cases, services are managed using a "service deployer extension" if the service is not provided by the container. Examples are Spring (in all cases), Seam 2 (unless running on JBoss AS <= 6) and CDI (if running on a servlet container).

     

    In other words, you mix a server with a service deployer extension. For example:

     

    • Spring + Tomcat
    • Weld Servlet + Tomcat

     

    Interesting to note, you can combine a service deployer extension with an embedded server container. However, the classpath leakage can be problematic, as you've experienced.

     

    Thus, there are two "modes" for testing Spring with Arquillian:

     

    • Embedded service container (bootstraps Spring and feeds classes and resources from the ShrinkWrap archive to Spring) <= most similar to Spring TestContext framework
      • arquillian-embedded-spring-3
      • arquillian-embedded-spring-2.5
    • Service deployer extension (packages the Spring libraries in the ShrinkWrap archive that is deployed to the server container)
      • arquillian-service-deployer-spring-3
      • arquillian-service-deployer-spring-2.5

     

    Thus far, you have implemented the service deployer extension. For more rapid development, it would be good to have an embedded service container, which works almost exactly like Weld SE Embedded. The embedded service container will not be useful for Spring MVC testing because there is no web component available (though the use of mocks can be explored, like Weld EE Embedded).

     

    Does that help clarify things. (Keep in mind, I'm still refining this myself, so I value your feedback either way).

  • 16. Re: Towards Spring Test Enricher Milesone One
    Dan Allen Master

    Jakub Narloch wrote:

     

     

    3. Should we use the term extension in the root package name: org.jboss.arquillian.extension.spring? Drone doesn't follow this convention, but it would be more consistent.

     

    For example the Seam2 is defined as:

     

      <groupId>org.jboss.arquillian.extension</groupId>

      <artifactId>arquillian-seam2</artifactId>

     

     

     

     

    The Seam2 extension should be updated to align with whatever we decide for the Spring extension, since they follow the same paradigm.

     

    Jakub Narloch wrote:

    As I mentioned earlier, the Spring extension is the first of it's kind. It will provide:

     

    1. a packager/enricher, which I refer to as either a "service" or a "deployer"
    2. an embedded runtime, which I refer to as an "embedded service container"

     

    This leads me to suggest the following artifactId for #1:

     

    • org.jboss.arquillian.extension:arquillian-deployer-spring-3 (currently org.jboss.arquillian.extension:arquillian-spring-3)
    • org.jboss.arquillian.extension:arquillian-deployer-spring-2.5 (currently org.jboss.arquillian.extension:arquillian-spring-3)

     

    I'm not sure "deployer" is the right word here. Another possibility is "service", because it's as though you are installing the Spring service into the container. I guess "subsystem" would work as well, or "service-extension" (though that's kind of long and redundant).

     

    In my opinion the most accurate term would be testenricher, but the "service" works for me.

     

    After sleeping on it, I like "service deployer", which can be written "servicedeployer" or "service-deployer". We've used "testrunner" in the past, so I'm open to using the condensed form.

  • 17. Re: Towards Spring Test Enricher Milesone One
    Dan Allen Master

    Great work Jakub.

     

    Btw, org.jboss.arquillian.spring.test.annotation.Spring*Configuration is fine with me. Reads very intuitive.

  • 18. Re: Towards Spring Test Enricher Milesone One
    Jakub Narloch Novice

    Ok, it's done.

     

    To sum up the changes:

    • I've resolved the issue with optional dependencies
    • Added support for registering custom context classes through arquillian.xml
    • Moved the Spring*Configuration annotations into org.jboss.arquillian.spring.test.annotation
    • Renamed the *Consts classes
    • And last but not least, renamed the artifact names into "arquillian-service-deployer-spring-*"

     

    Now, what next?

  • 19. Re: Towards Spring Test Enricher Milesone One
    Dan Allen Master

    Great work Jakub!

     

    I think that the next step is write up an announcement for Alpha1 (can be brief) that we'll include as part of the arquillian.org blog. It's just a matter of creating a textile file and using other blog entries as a reference and jot down some of your thoughts. I'd be happy to revise. We can shoot for Monday, the opening day of GSoC coding

     

    https://github.com/arquillian/arquillian.github.com/tree/develop/blog

     

    (I still haven't gotten around to writing a guide for how to contriubte to blog).

     

    Btw, I want you to feel welcome to writing a blog for arquillian.org at any time. It can be a status update or it can just be general thoughts about Spring testing. It's just a pull request away.

     

    (Eventually we will have per-author views like Ceylon has: http://ceylon-lang.org/blog/authors/emmanuel-bernard/)

     

    I'm hoping that Aslak will get a chance to review the code prior to the release...though I doubt it would hold up a release.

  • 20. Re: Towards Spring Test Enricher Milesone One
    Jakub Narloch Novice

    Cool.

     

    I would deffinietly would like to do that. But maybe we could wait for Marius and Aslak to do the review, maybe they will find something crucial in the implementation.

     

    BTW. Do You think I could ask Sarah to do a little mascot for the project, something like: Ike on a Spring (- http://en.wikipedia.org/wiki/Spring_(device))

  • 21. Re: Towards Spring Test Enricher Milesone One
    Dan Allen Master

    I would deffinietly would like to do that. But maybe we could wait for Marius and Aslak to do the review, maybe they will find something crucial in the implementation.

     

    Sounds good. They both said they could get to it in less than a week's time, so we can hold out.

     

     

    BTW. Do You think I could ask Sarah to do a little mascot for the project, something like: Ike on a Spring (- http://en.wikipedia.org/wiki/Spring_(device))

     

    Yep, just file an issue here: https://github.com/arquillian/arquillian-artwork/issues You can put in some suggestions about what you might want to logo to be. Naturally, we are following an alien, space and futuristic theme.

  • 22. Re: Towards Spring Test Enricher Milesone One
    Jakub Narloch Novice

    I had just updated the showcase (https://github.com/jmnarloch/arquillian-container-spring-showcase) with three additional examples:

     

    • JDBC
    • Hibernate
    • JPA

     

    All above demonstrate quite similar case of testing DAO layer implemented with different frameworks.

     

    For all of the above examples the data source is being lookup through the JNDI directly from the container, but I also added configuration for switching to different data sources:

     

    <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xmlns:context="http://www.springframework.org/schema/context"
           xmlns:jdbc="http://www.springframework.org/schema/jdbc" xmlns:jee="http://www.springframework.org/schema/jee"
           xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd http://www.springframework.org/schema/jdbc http://www.springframework.org/schema/jdbc/spring-jdbc.xsd http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-3.0.xsd">
    
    
        <!-- Embedded data source settings -->
        <!--<jdbc:embedded-database id="dataSource" type="H2">-->
            <!--<jdbc:script location="classpath:create.sql"/>-->
        <!--</jdbc:embedded-database>-->
    
    
        <!-- Lookups the data source form the JNDI -->
        <jee:jndi-lookup id="dataSource" expected-type="javax.sql.DataSource" jndi-name="jdbc/SpringJDBCTest"/>
    
    
        <!-- Settings for external data source, DriverManagerDataSource is used only for test purpose in real situation use pooling datasource like DBCP  -->
        <!--<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">-->
            <!--<property name="driverClassName" value="org.h2.Driver"/>-->
            <!--<property name="url" value="jdbc:h2:mem:arquillian;DB_CLOSE_DELAY=-1"/>-->
            <!--<property name="username" value=""/>-->
            <!--<property name="password" value=""/>-->
        <!--</bean>-->
    
    
        <!-- Registers Hibernate Session Factory -->
        <bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
            <property name="dataSource" ref="dataSource"/>
            <property name="annotatedClasses">
                <list>
                    <value>com.acme.spring.hibernate.domain.Stock</value>
                </list>
            </property>
            <property name="hibernateProperties">
                <value>
                    hibernate.current_session_context_class=thread
                    hibernate.dialect=org.hibernate.dialect.H2Dialect
                    hibernate.hbm2ddl.auto=create-drop
                </value>
            </property>
        </bean>
    
    
        <!-- Scans for the beans definitions -->
        <context:component-scan base-package="com.acme.spring.hibernate.repository.impl"/>
    
    
    </beans>
    

     

  • 23. Re: Towards Spring Test Enricher Milesone One
    Jakub Narloch Novice

    Hi Dan,

     

    Everything is almost in place There are open pull requests for the source code, showcases and release note.

     

    You may modify the release note as you like, I don't think I have experience in such things

  • 24. Re: Towards Spring Test Enricher Milesone One
    Dan Allen Master

    Once again, great work. Way to kick off the summer!

     

    I'll review the notes and merge them in tonight. We'll make noise tomorrow morning. Tuesday is always a good day for making noise

1 2 Previous Next