Topic
7 replies Latest Post - ‏2013-12-06T00:21:32Z by JarvisWeiCheng
JarvisWeiCheng
JarvisWeiCheng
5 Posts
ACCEPTED ANSWER

Pinned topic primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

‏2013-12-04T20:42:01Z |

Today I attended "Inside IBM WAS V8.5.5.Next Alpha - A Live Q&A with Ian Robinson,  Chief Architect"

It is great session. Definitely I would recommend it to my coworkers in the field. A WebSphere Java EE Architect at IBM encouraged us to send the post about our question. I checked with my developers. They only did search on the forum. Here is the words from them: "I checked WASDev forums, there is no solution" Hence I am willing to open up a question on behalf of them because I am really impressed the response from that Java EE Architect at IBM. "if you can give me the topic title, date, or poster, then I can follow up"

when I inject an EJB using @EJB jsf backing bean

public class PhuBean implements Serializable {
 
@javax.faces.bean.ManagedBean(name = "phuBean")
@SessionScoped
 
public class PhuBean implements Serializable {
 
        @EJB
        private SchoolUploadService service;
 
}
SchoolUploadService is an stateless session bean
@Stateless
@LocalBean
 
public class SchoolUploadService {
 

The error message that Frank got and provided is as follows:

here is an error message: (I put *** to protect the confidentiality of the work)
 com.ibm.wsspi.injectionengine.InjectionException: The injection engine encountered an error injecting ***ui.bean.PhuBean/service into private ***.service.SchoolUploadService ***.ui.bean.PhuBean.service: java.lang.IllegalArgumentException:  Can not set ***.service.SchoolUploadService field 
***.ui.bean.PhuBean.service to ***.service.EJSLocalNSLSchoolUploadService_e6bf6567 at com.ibm.wsspi.injectionengine.InjectionTarget.inject(InjectionTarget.java:154)

I also went on to search on the net based on the information he provided. It seemed to me that inject ejb from jsf backing bean is not a good idea.

Weblogic
 
WebSphere
 
JBOSS

 

  • bergmark
    bergmark
    42 Posts
    ACCEPTED ANSWER

    Re: primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

    ‏2013-12-04T21:18:16Z  in response to JarvisWeiCheng

    There should be no problem with using @EJB to inject an EJB into a JSF Managed bean.  That is fully supported in Liberty profile.

    It appears that there might be some kind of classloading issue where we don't believe the EJB is of the right type to set into that field.  Could you tell us a little bit more about the structure of the application and where the EJB class (SchoolUploadService) lives?

    • JarvisWeiCheng
      JarvisWeiCheng
      5 Posts
      ACCEPTED ANSWER

      Re: primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

      ‏2013-12-04T23:00:09Z  in response to bergmark

      Thank you so much "bergmark" (Joe) for your prompt reply. I left the office and I did not have the cell of the developer to contact him. He sent me the code  this afternoon. I have to tell him to use the forum to post questions. I really like such healthy collaborative forum! It is a pity that I am not developer, else I will contribute my two cents here. I could send you the code fragment if you like or have him answer your question tomorrow. Many Thanks Joe!!!

    • JarvisWeiCheng
      JarvisWeiCheng
      5 Posts
      ACCEPTED ANSWER

      Re: primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

      ‏2013-12-04T23:26:26Z  in response to bergmark

      Hi Joe (bergmark), I tried to answer your question with my limited knowledge. I will confirm it with Frank tomorrow. "where the EJB class (SchoolUploadService) lives?"

      public class PhuBean implements Serializable {

      ...

       @EJB
       private SchoolUploadService service;

      ....
      }

       

      The above code fragment is lived in Phubean.java. There is another Java class source file SchoolUploadService.java. He expressed that he had issue with the above code in his email. 

      • bergmark
        bergmark
        42 Posts
        ACCEPTED ANSWER

        Re: primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

        ‏2013-12-05T14:47:06Z  in response to JarvisWeiCheng

        Sorry, I should have been more clear about what I was asking.

        We are hoping to understand the structure of the application (ear, wars, jars, etc) and where the EJB class is located within that structure.  

        • JarvisWeiCheng
          JarvisWeiCheng
          5 Posts
          ACCEPTED ANSWER

          Re: primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

          ‏2013-12-05T15:04:03Z  in response to bergmark

          SchoolUploadService EJB is in a jar file different from PhuBean, but it's under the same ear file. Here is the error in red (copied directly from the IDE) Please note the Bold face for the EJSLocalNSLSchoolUploadService_e6bf6567

          Caused by: com.ibm.wsspi.injectionengine.InjectionException: The injection engine encountered an error injecting xxx.ui.bean.PhuBean/service into private xxx.service.SchoolUploadService xxx.ui.bean.PhuBean.service: java.lang.IllegalArgumentException: Can not set xxx.service.SchoolUploadService field xxx.ui.bean.PhuBean.service to xxx.service.EJSLocalNSLSchoolUploadService_e6bf6567 at com.ibm.wsspi.injectionengine.InjectionTarget.inject(InjectionTarget.java:154)

          Thanks!

          • bergmark
            bergmark
            42 Posts
            ACCEPTED ANSWER

            Re: primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

            ‏2013-12-05T18:22:51Z  in response to JarvisWeiCheng

            Is there any chance you could package up a simple application that recreates the problem so we could debug on our end?  Our best guess is still some kind of classloading problem, but its still not clear what could be causing that.

            • JarvisWeiCheng
              JarvisWeiCheng
              5 Posts
              ACCEPTED ANSWER

              Re: primeface 3.5 inject EJB 3.1 from JSF 2.1 backing bean

              ‏2013-12-06T00:21:32Z  in response to bergmark

              Yes. I agreed we could package some simple codes to recreate the problem at your end. Hopefully we could get the bottom of the issue and share back to forum audience when we have something concrete! Stay tuned for the update.