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
      • 60. Re: GSoC - Arquillian Spring Integration
        Jakub Narloch Novice

        Hi again,


        I had been struggling with making the integration test working with Spring 2.5.6 for last two days. Finally I have manage to make them work and successfully run on JBoss AS 6 and 7 (previous versions like 4.x and 5 will be tested soon - but it quite likely that the will work without any changes in the code). As already mentioned in previous posts the Spring 3.x extension works well with JBoss 6 and 7.


        As for the Spring 2.5.6 I found quite weird behavior. I wasn't able to make context: component-scan working it seems that this is more related to the spring version, because the Spring 3 works perfectly well here, but I found here interesting information in the Spring reference:



        Note that the scanning of classpath packages requires the presence of corresponding directory entries in the classpath. When building jars with Ant, make sure to not activate the files-only switch of the jar task!




        I was wondering how does the ShrinkWrap archives behave here and is there a way to include in them full directories paths?

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

          After discusion with Marius today, he point me that I should use SnowDrop for class path scanning, so I'm going to give it a try and modify the code a bit.

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

            Couple of thoughts from todays discusion with Marius,


            From functional aspects the fallowing should be added into the extension:

            • Snowdrop for Spring 2.5.6
            • Registering custom context classes.
            • Additional tests and especially working examples that would demonstrate the usage.


            The plan is to make that happen within next 2-3 weeks and then publish the version as the first milestone.


            In long therm additional transaction support should be added.

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

              For registering custom context classes I would introduce seperate annotaction, let's say:




              The usage will be limited to @SpringConfiguration and @SpringAnnotatedConfiguration and will allow to instantiate the custom context classes.

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

                How about adding an attribute to current annotations? I think it would make the configuration easier to read.

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

                  Consider it done.

                  Marius Bogoevici wrote:


                  How about adding an attribute to current annotations? I think it would make the configuration easier to read.

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

                    I had implemented the mentioned attribute for @SpringConfiguration, this will be especially usefull for running the test with Spring 2.5.6 in JBoss due to it's incompatibility.


                    For example, instead of using Spring ClassPathXmlApplicationContext test could use Snowdrop's  VFSClassPathXmlApplicationContext.

                    @SpringConfiguration(value = {"service.xml", "repository.xml"}, contextClass = VFSClassPathXmlApplicationContext.class)
                    public class XmlConfigurationTestCase {



                    I had also modfieid the configuration for arquillian-spring-2.5 extension which now allows to automaticly include snowdrop with deployments:

                    <?xml version="1.0" encoding="UTF-8"?>
                    <arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                                xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
                        <defaultProtocol type="Servlet 3.0" />
                        <extension qualifier="spring">
                            <!-- The version of Spring artifact, will be used for auto package the spring-context and spring-web,
                             default is 2.5.6 -->
                            <property name="springVersion">2.5.6</property>
                            <!-- Whether to auto package the dependencies, default is true -->
                            <property name="autoPackage">true</property>
                            <!-- Whether to include the snowdrop in test deployment, default is false -->
                            <property name="includeSnowdrop">true</property>
                            <!-- The version of the Snowdrop artifact, default is 2.0.3.Final -->
                            <property name="snowdropVersion">2.0.3.Final</property>


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

                      I'm excited to read about your progress, Jakub. And thanks Marius for providing some key guidance. It's great to this effort be able to tap into Snowdrop, something that can really bring this extension full circle to offering something *more* for Spring developers.




                      I'm going to plant a little gossip that might pique your motivation to keep going strong. I picked up that the Spring camp is working on a DBUnit extension for Spring tests, duplicating in part the work of the Ace on the Arquillian persistence extension. As your extension starts to take shape, we can pair it up with the Arquillian persistence extension and, voila, Spring developers now have the same kick-ass persistence extension as non-Spring developers (the beauty of Arquillian). Winning.


                      ...and, of course, if you need to clear your head and want to mess around w/ the Arquillian persistence extension, you know where it is

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

                        I see that we are thinking the same, the support for Arquillian persistence extension is my long term goal and quite likely I'll get back to this idea.

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

                          Excellent. We'll be with you all the way.

                          • 70. Re: GSoC - Arquillian Spring Integration
                            Bartosz Majsak Master



                            first of all I must say you are doing astonishing work for Spring integration. This topic is recurring in almost every talk I'm giving about Arquillian so having Spring support as first class citizen would be definitely a huge advantage for us. And will save me from answering "springy" questions with "we will have it, it's already work in progress"


                            Since I was called by Dan I just want to add that you can count on me with regards to APE + Spring any time. Just ping me and I'll be summoned.


                            Speaking about spring-dbunit project, I saw that one already few days back and it's offering all what we (and Unitils) offers. Maybe DataSetLoader (or any kind of data provider in our case) is something we should consider. To give the end user more flexibility in this area. I already have some initial sketches for entity provider similar to the concept of data provider from TestNG. Another thing to look at is configuration stuff - maybe I'm missing something in APE. But to be honest I'm really wondering why they* came up with it if they have Unitils for ages which is designed with Spring in mind.


                            * I think it's more side project of VMWare / SS employee rather than Spring module or sth like.




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

                              Hi Bartosz,


                              I woudl appreciate You help with the project.


                              Currently I got two ideas that I think would be worth realizing:


                              1. First would be transaction support, similar to those that Spring Test provides. I think that this would be easy to achive, although the APE API would need to provide some extension points in order to implement e.g. seperate transaction manager, then I could simply prepare a TransactionWrapper that would delegate to Spring Platform AbstractPlatformTransactionManager.


                              Configuration could look like similar:


                              <bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
                                <property name="sessionFactory" ref="sessionFactory" />



                              The test then could use that transaction manager:


                              public void SomeTestCase {
                                   // test code



                              2. For second thing, I do know that there is no similar functionality but I would like introduce support for using data sources configured within Spring. In my opinion that would reduce greatly the needed steps to set up the tests.


                              For example:


                              <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
                                <property name="driverClassName" value="${jdbc.driverClassName}" />
                                <property name="url" value="${jdbc.url}" />
                                <property name="username" value="${jdbc.username}" />
                                <property name="password" value="${jdbc.password}" />



                              That could be simply configured within the tests


                              public void SomeTestCase {
                                   // test code





                              What do You think about it?

                              • 72. Re: GSoC - Arquillian Spring Integration
                                Bartosz Majsak Master

                                That's definitely something worth to implement on the SPI level. I'm anyway starting to work on SPI modules (also for different "data providers" such as Liquibase), so I will aim to expose transaction and datasource handling as well. I will keep you updated. From the timeline perspective however, I don't expect to have it before July. I hope you will still be busy with other things around the core Spring extension

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

                                  Hi again,


                                  I had moved the integration tests into the main repository (https://community.jboss.org/thread/199135?tstart=0).


                                  I think it is high time to ask for a code review of my work. At least for I can not think anything worth implementing that wouldn't be already there. (except of course of the APE integration).


                                  All comments will be welcome

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

                                    One more thing.


                                    I tried to run the tests with embedded Glassfish but I'm getting the fallowing error:


                                    java.lang.NoSuchMethodError: org.jboss.arquillian.container.spi.client.protocol.metadata.ProtocolMetaData.getContexts(Ljava/lang/Class;)Ljava/util/Collection;
                                              at org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(BaseServletProtocol.java:61)
                                              at org.jboss.arquillian.protocol.servlet.BaseServletProtocol.getExecutor(BaseServletProtocol.java:35)
                                              at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.getContainerMethodExecutor(RemoteTestExecuter.java:136)
                                              at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:119)
                                              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                                              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
                                              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                                              at java.lang.reflect.Method.invoke(Method.java:601)



                                    Don't have idea how to fix it.

                                    1 3 4 5 6 7 Previous Next