11 Replies Latest reply on Apr 6, 2010 7:34 AM by John Ament

    Deploying datasources

    John Ament Master

      So based on what I've seen, I'm inclined to say that Arquillian doesn't support @DataSourceDefinition

       

      I assume this because I put the following in a bean, but the DS never gets deployed (even though this is getting deployed to a GFV3 env)

       

       

      @DataSourceDefinition(name = "java:global/env/ServerDS",


            minPoolSize = 0,


            initialPoolSize = 0,


            className = "org.apache.derby.jdbc.ClientXADataSource",


            user = "APP",


            password = "APP",


            databaseName = "TDB01",


            properties = {"connectionAttributes=;create=true"}


         )

       

      So what I"m wondering is if there's a best way to deploy a datasource to do some JPA testing.

        • 1. Re: Deploying datasources
          Iskandar Salim Newbie

          For glassfish, you can specifiy the datasources in the domain.xml of your installation. So how would it work with arquillian and glassfish embedded?

          Here's a short write-up (have to hack a little though). Basically, you need to tell Arqullian to run the embedded glassfish container instance from a permanent location where you can specify the domain.xml with all the datasources you want. It's not the best way but it works for me

          • 2. Re: Deploying datasources
            John Ament Master

            hmm that's actually a pretty nifty trick.  i'm not sure i like the idea of having the directory structure of glassfish in source control but other than that it looks cool.

             

            i should be able to, in theory, point it to a real domain on the file system though?

             

            i feel like instanceRoot should be a parameter that arquillian takes in when starting the container.  i'm currently also thinking about an issue if there's multiple unit tests running, what happens to glassfish binding on port 8080?

            • 3. Re: Deploying datasources
              Aslak Knutsen Master

              i should be able to, in theory, point it to a real domain on the file system though?

              I havn't tested this my self, but i believe so.

               

              i feel like instanceRoot should be a parameter that arquillian takes in when starting the container.  i'm currently also thinking about an issue if there's multiple unit tests running, what happens to glassfish binding on port 8080?

              Working on this,  https://jira.jboss.org/jira/browse/ARQ-95https://jira.jboss.org/jira/browse/ARQ-33

              Should be part of Alpha-2.

               

               

              I'm not sure why the @DataSourceDefnition doesn't work, it shouldn't need any integration with Arquillian. I'll post back when i figure it out.

              • 4. Re: Deploying datasources
                John Ament Master

                not sure if it helps, but the datasource definition is in test.jar, the generated archive in the test case

                 

                hmm i'm seeing a weird issue, probably not related. new thread time.

                • 5. Re: Deploying datasources
                  John Ament Master

                  well the good thing is that the only real issue I'm seeing is that the generated test.ear doesn't always get cleared out.  as a result, i sometimes have to delete it myself.

                   

                  a nifty work around is to just lookup the EJB by itself, since arquillian doesn't inject singletons/no interface beans.  file system approach is working well though, if a bit slow.

                  • 6. Re: Deploying datasources
                    John Ament Master

                    alright, another interesting side effect of this.

                     

                    CDI injection points are being processed correctly for beans defined in src/main.  They are not being processed correctly for src/test.

                     

                    E.g. I have a bean (in my real code) that has something like

                     

                    @Inject AnotherBean anotherBean;

                     

                    and it gets injected properly (I can see log messages stating so)

                     

                    But if I do the same thing in my test, it's null.

                     

                    it's something w/ glassfish, as I have another project that was running against weld, running the UT against Weld SE works.  Running them against glassfish fails.

                    • 7. Re: Deploying datasources
                      Iskandar Salim Newbie

                      John Ament wrote:

                       

                      But if I do the same thing in my test, it's null.

                       

                      it's something w/ glassfish, as I have another project that was running against weld, running the UT against Weld SE works.  Running them against glassfish fails.

                      Thought I read somewhere in the Arquillian spaces that CDI is not  working yet for glassfish embedded.

                       

                      It's somehow related to this glassfish issue . Watching it

                      • 8. Re: Deploying datasources
                        Aslak Knutsen Master

                        The Arquillian Glassfish CDI issue is related to this issue:  https://glassfish.dev.java.net/issues/show_bug.cgi?id=11497

                         

                        The issue is fixed in the latest 3.0.1/3.1 nightly builds of Glassfish, but I've had problems verifying the fix due to some completely unrelated startup issue with Glassfish.

                        • 9. Re: Deploying datasources
                          Aslak Knutsen Master

                          What kind of 'bean' are you adding the DataSourceDefinition annotation to? EJB, CDI, JSF?

                           

                          As far as I could read from the EE spec it's suppose to be a EE managed component in a EE module.

                           

                          That means on a EJB, Servlet, ServletListener or Application Client in a EJB Jar, War or Client jar.

                           

                          A CDI Bean Archive (any jar with beans.xml in it) is not defined as a EE Module.

                          • 10. Re: Deploying datasources
                            John Ament Master

                            this is being attached to an EJB.  the archive should be getting acknowledged as an ejb archive as it has an ejb-jar.xml in it, with 3.1 listed as the version.  this is test.jar though.

                            • 11. Re: Deploying datasources
                              John Ament Master

                              Aslak Knutsen wrote:

                               

                              The Arquillian Glassfish CDI issue is related to this issue:  https://glassfish.dev.java.net/issues/show_bug.cgi?id=11497

                               

                              The issue is fixed in the latest 3.0.1/3.1 nightly builds of Glassfish, but I've had problems verifying the fix due to some completely unrelated startup issue with Glassfish.

                              as far as this goes, i just tried against 3.1 snapshot (from april 2) and it's still failing.  EJB tests passed.

                               

                              or do i need to get the nightly from somewhere else?