6 Replies Latest reply on Oct 1, 2014 1:39 PM by mlybarger

    testing with @Resource definition

    mlybarger
    mlybarger Sep 17, 2014 1:14 PM

      I have a sy service that references a CDI Bean that i'd like to unit test.  the CDI Bean looks like:

       

      @Named

      public class TestCDI implements ITestCDI{

           @Resource(lookup="java:/foo")   

          String foo;

              public String lookup() {

          return foo;

          }

      }

       

      In my test, I setup the binding,

       

      bind(initialContext, "java:/foo", "here")


      but the injection of the resource never happens during execution with the SwitchyardRunner.


      Any insights would be most appreciated.


      Thanks,

      -mark-



      • 890 Views
      • Tags:
        • 1. Re: testing with @Resource definition
          rcernich
          rcernich Sep 17, 2014 2:50 PM (in response to mlybarger)

          Hey Mark,

           

          Have you tried adding the NamingMixIn to your test?  This should add a naming context for your test.

           

          Hope that helps,

          Rob

            • Actions
          • 2. Re: Re: testing with @Resource definition
            mlybarger
            mlybarger Sep 17, 2014 3:10 PM (in response to rcernich)

            Yes, I do have a naming context, but the @Resource injection points don't seem to be getting resolved.  The lookup2 method returns as expected.

             

            import javax.annotation.Resource;

            import javax.inject.Named;

            import javax.naming.InitialContext;

            import javax.naming.NamingException;

             

             

            @Named

            public class TestCDI implements ITestCDI{

             

                @Resource(name="java:/foo")

                private String foo;

              

                public String lookup() {

                return foo;

                }

             

                public String lookup2() {

                String ret = null;

                InitialContext ic;

              try {

              ic = new InitialContext();

              ret = (String) ic.lookup("java:/foo");

              } catch (NamingException e) {

              e.printStackTrace();

              }

              return ret;

                }

            }

              • Actions
            • 3. Re: Re: testing with @Resource definition
              jorgemoralespou_2
              jorgemoralespou_2 Sep 17, 2014 4:01 PM (in response to mlybarger)

              Hi,

              As I guess you're using SY 2.0, and I do not know what's been added, I'll give you a non SwitchYard suggestion. Use a CDI @Alternative to inject another bean, with lookup2 as a provider for the String you want to lookup. This way you can bypass the problem that you are experiencing. Of course, if you can create a reproducer, just send it to this guys, so they can validate if it an error, or create a JIRA and attach the reproducer to it.

               

              Hope it helps.

                • Actions
              • 4. Re: Re: testing with @Resource definition
                mlybarger
                mlybarger Sep 17, 2014 4:22 PM (in response to jorgemoralespou_2)

                actually, i'm using FSW 6.0.0 (SY 1.1.0 GA).

                 

                I'm starting to believe that the weld being for the SY testing (SE) used doesn't have a ResourceInjectionServices instance available.  I'd love to figure out how to add this service.

                  • Actions
                • 5. Re: Re: testing with @Resource definition
                  jorgemoralespou_2
                  jorgemoralespou_2 Sep 17, 2014 5:10 PM (in response to mlybarger)

                  Hi,

                  I guess that the SwitchyardRunner is the one that is hooking up things, and maybe you`re right and doesn't have that, or that it is a reduced service. I faced similar issues with @EntityManager but not sure if it was due to the fact that it doesn't run into an EE app server. As I said, In my case, I solved with with @Alternative and @Produces, having an alternative Bean that produced the EntityManager for me it worked.

                   

                  If you get into a conclusion, please share, and if it as problem, raise the appropriate JIRAs.

                    • Actions
                  • 6. Re: testing with @Resource definition
                    mlybarger
                    mlybarger Oct 1, 2014 1:39 PM (in response to jorgemoralespou_2)

                    the problem is that CDIMixIn creates its own Weld instance that doesn't contain an instance of ResourceInjectionServices, thus, no @Resource injection occurs.  I already had a modified CDIMixIn class that I was using to allow the testing of CDI beans directly in my unit tests per these notes:


                    Enhancement: CDI in SwitchYard Unit Tests

                    [SWITCHYARD-1645] CDI in SwitchYard Unit Tests - JBoss Issue Tracker


                    So, I grabbed org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices (copied into my project was easier), and then used that for weld to handle the @Resource injection.


                    My CDIMixInExt had the following:


                                    Deployment deployment = createDeployment(resourceLoader, bootstrap);

                                    // Set up the container

                                    deployment.getServices().add(ResourceInjectionServices.class, new WeldResourceInjectionServices());

                                    //JTAEnvironmentBean _jtaEnvironmentBean = new JTAEnvironmentBean();              

                                    //deployment.getServices().add(TransactionServices.class, new LocalArjunaTransactionServices(_jtaEnvironmentBean));

                                    bootstrap.startContainer(Environments.SE, deployment);

                      • Actions