Access an injected Stateful Session Bean over a looked up Stateful Session Bean












0















I was wondering if EJB specifications allow to access a stateful session bean over a looked up stateful session bean.



The reason why I'm asking is, that Jboss EAP 7.0 has no problems with it, but Websphere throws a NullPointerException when I try to access the bean.



For example:



@Stateful
public class SampleServiceRoot implements SampleServiceRootRemote {

@EJB
protected SampleServiceChildLocal servicechild;

@Override
public SampleServiceChildLocal getServiceChild(){
return servicechild;
}
}

@Stateful
public class SampleServiceChild implements SampleServiceChildLocal,SampleServiceChildRemote{

@Override
public void anyMethod(){
//DO Anything
}
}


When I do a remote lookup to the SampleServiceRootRemote and call "getServiceChild()" and try to call "anyMethod()" on it, it works on JBoss EAP 7.0 but on Websphere I get a NullPointerException.



So I was wondering if this is a Bug in Websphere or is it forbidden by EJB Specification and I was just lucky with JBoss EAP 7.0?










share|improve this question



























    0















    I was wondering if EJB specifications allow to access a stateful session bean over a looked up stateful session bean.



    The reason why I'm asking is, that Jboss EAP 7.0 has no problems with it, but Websphere throws a NullPointerException when I try to access the bean.



    For example:



    @Stateful
    public class SampleServiceRoot implements SampleServiceRootRemote {

    @EJB
    protected SampleServiceChildLocal servicechild;

    @Override
    public SampleServiceChildLocal getServiceChild(){
    return servicechild;
    }
    }

    @Stateful
    public class SampleServiceChild implements SampleServiceChildLocal,SampleServiceChildRemote{

    @Override
    public void anyMethod(){
    //DO Anything
    }
    }


    When I do a remote lookup to the SampleServiceRootRemote and call "getServiceChild()" and try to call "anyMethod()" on it, it works on JBoss EAP 7.0 but on Websphere I get a NullPointerException.



    So I was wondering if this is a Bug in Websphere or is it forbidden by EJB Specification and I was just lucky with JBoss EAP 7.0?










    share|improve this question

























      0












      0








      0








      I was wondering if EJB specifications allow to access a stateful session bean over a looked up stateful session bean.



      The reason why I'm asking is, that Jboss EAP 7.0 has no problems with it, but Websphere throws a NullPointerException when I try to access the bean.



      For example:



      @Stateful
      public class SampleServiceRoot implements SampleServiceRootRemote {

      @EJB
      protected SampleServiceChildLocal servicechild;

      @Override
      public SampleServiceChildLocal getServiceChild(){
      return servicechild;
      }
      }

      @Stateful
      public class SampleServiceChild implements SampleServiceChildLocal,SampleServiceChildRemote{

      @Override
      public void anyMethod(){
      //DO Anything
      }
      }


      When I do a remote lookup to the SampleServiceRootRemote and call "getServiceChild()" and try to call "anyMethod()" on it, it works on JBoss EAP 7.0 but on Websphere I get a NullPointerException.



      So I was wondering if this is a Bug in Websphere or is it forbidden by EJB Specification and I was just lucky with JBoss EAP 7.0?










      share|improve this question














      I was wondering if EJB specifications allow to access a stateful session bean over a looked up stateful session bean.



      The reason why I'm asking is, that Jboss EAP 7.0 has no problems with it, but Websphere throws a NullPointerException when I try to access the bean.



      For example:



      @Stateful
      public class SampleServiceRoot implements SampleServiceRootRemote {

      @EJB
      protected SampleServiceChildLocal servicechild;

      @Override
      public SampleServiceChildLocal getServiceChild(){
      return servicechild;
      }
      }

      @Stateful
      public class SampleServiceChild implements SampleServiceChildLocal,SampleServiceChildRemote{

      @Override
      public void anyMethod(){
      //DO Anything
      }
      }


      When I do a remote lookup to the SampleServiceRootRemote and call "getServiceChild()" and try to call "anyMethod()" on it, it works on JBoss EAP 7.0 but on Websphere I get a NullPointerException.



      So I was wondering if this is a Bug in Websphere or is it forbidden by EJB Specification and I was just lucky with JBoss EAP 7.0?







      java ejb websphere jboss-eap-7 stateful






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 20 '18 at 8:40









      Matthias HerbstMatthias Herbst

      81




      81
























          2 Answers
          2






          active

          oldest

          votes


















          0














          The EJB specification does require this scenario to work, depending on some configuration options; there are configuration options that may disable it.



          The fact that you are seeing a NullPointerException indicates that WebSphere is not aware of the @EJB annotation on the field in the SampleServiceRoot class. Per the EJB specification, an instance of SampleServiceRoot cannot be created if the @EJB annotation cannot be resolved. Since an instance of SampleServiceRoot has been created, then one of the following has likely occurred:



          1 - The application performed a new SampleServiceRoot rather than looking it up in JNDI. This doesn't sound like your problem, but good to double check.



          2 - The application contains an ejb-jar.xml with the setting metadata-complete="true". When this is set, WebSphere will not look for annotations, and so will not see or process the @EJB annotation. Either change the setting to "false" or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



          3 - The application does not have metadata-complete="true", however when the application is deployed to WebSphere the option to set metadata-complete was selected.
          This option will change the metadata-complete setting to "true". Stop using this option, or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



          4 - The EJB is contained in a WAR module at level 2.4 or older. In WebSphere, annotations for older modules are not processed.



          5 - The application includes a copy of the javax.ejb.EJB class. WebSphere provides the javax.ejb.EJB class, and it is loaded by the WebSphere runtime classloader. If the application also contains the javax.ejb.EJB class on the application classpath, then another instance will be loaded by the application classloader, and it will not match the instance used by the EJB Container. There should be a warning in the logs if this has occurred.



          So yes, your scenario is required to be supported; however the specification does allow configurations that disable it. You just need to identify which configuration / packaging option has caused WebSphere to not see the @EJB annotation.






          share|improve this answer































            0














            Thanks for the answer,



            we tried to move the declarations of the Local-Interface to the Remote Interface of the SampleServiceChild. Also we did not use @EJB annotation. We managed it with doing a lookup of the SampleServiceChild over the InitialContext.
            Now it works






            share|improve this answer























              Your Answer






              StackExchange.ifUsing("editor", function () {
              StackExchange.using("externalEditor", function () {
              StackExchange.using("snippets", function () {
              StackExchange.snippets.init();
              });
              });
              }, "code-snippets");

              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "1"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389111%2faccess-an-injected-stateful-session-bean-over-a-looked-up-stateful-session-bean%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              2 Answers
              2






              active

              oldest

              votes








              2 Answers
              2






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              0














              The EJB specification does require this scenario to work, depending on some configuration options; there are configuration options that may disable it.



              The fact that you are seeing a NullPointerException indicates that WebSphere is not aware of the @EJB annotation on the field in the SampleServiceRoot class. Per the EJB specification, an instance of SampleServiceRoot cannot be created if the @EJB annotation cannot be resolved. Since an instance of SampleServiceRoot has been created, then one of the following has likely occurred:



              1 - The application performed a new SampleServiceRoot rather than looking it up in JNDI. This doesn't sound like your problem, but good to double check.



              2 - The application contains an ejb-jar.xml with the setting metadata-complete="true". When this is set, WebSphere will not look for annotations, and so will not see or process the @EJB annotation. Either change the setting to "false" or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



              3 - The application does not have metadata-complete="true", however when the application is deployed to WebSphere the option to set metadata-complete was selected.
              This option will change the metadata-complete setting to "true". Stop using this option, or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



              4 - The EJB is contained in a WAR module at level 2.4 or older. In WebSphere, annotations for older modules are not processed.



              5 - The application includes a copy of the javax.ejb.EJB class. WebSphere provides the javax.ejb.EJB class, and it is loaded by the WebSphere runtime classloader. If the application also contains the javax.ejb.EJB class on the application classpath, then another instance will be loaded by the application classloader, and it will not match the instance used by the EJB Container. There should be a warning in the logs if this has occurred.



              So yes, your scenario is required to be supported; however the specification does allow configurations that disable it. You just need to identify which configuration / packaging option has caused WebSphere to not see the @EJB annotation.






              share|improve this answer




























                0














                The EJB specification does require this scenario to work, depending on some configuration options; there are configuration options that may disable it.



                The fact that you are seeing a NullPointerException indicates that WebSphere is not aware of the @EJB annotation on the field in the SampleServiceRoot class. Per the EJB specification, an instance of SampleServiceRoot cannot be created if the @EJB annotation cannot be resolved. Since an instance of SampleServiceRoot has been created, then one of the following has likely occurred:



                1 - The application performed a new SampleServiceRoot rather than looking it up in JNDI. This doesn't sound like your problem, but good to double check.



                2 - The application contains an ejb-jar.xml with the setting metadata-complete="true". When this is set, WebSphere will not look for annotations, and so will not see or process the @EJB annotation. Either change the setting to "false" or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



                3 - The application does not have metadata-complete="true", however when the application is deployed to WebSphere the option to set metadata-complete was selected.
                This option will change the metadata-complete setting to "true". Stop using this option, or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



                4 - The EJB is contained in a WAR module at level 2.4 or older. In WebSphere, annotations for older modules are not processed.



                5 - The application includes a copy of the javax.ejb.EJB class. WebSphere provides the javax.ejb.EJB class, and it is loaded by the WebSphere runtime classloader. If the application also contains the javax.ejb.EJB class on the application classpath, then another instance will be loaded by the application classloader, and it will not match the instance used by the EJB Container. There should be a warning in the logs if this has occurred.



                So yes, your scenario is required to be supported; however the specification does allow configurations that disable it. You just need to identify which configuration / packaging option has caused WebSphere to not see the @EJB annotation.






                share|improve this answer


























                  0












                  0








                  0







                  The EJB specification does require this scenario to work, depending on some configuration options; there are configuration options that may disable it.



                  The fact that you are seeing a NullPointerException indicates that WebSphere is not aware of the @EJB annotation on the field in the SampleServiceRoot class. Per the EJB specification, an instance of SampleServiceRoot cannot be created if the @EJB annotation cannot be resolved. Since an instance of SampleServiceRoot has been created, then one of the following has likely occurred:



                  1 - The application performed a new SampleServiceRoot rather than looking it up in JNDI. This doesn't sound like your problem, but good to double check.



                  2 - The application contains an ejb-jar.xml with the setting metadata-complete="true". When this is set, WebSphere will not look for annotations, and so will not see or process the @EJB annotation. Either change the setting to "false" or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



                  3 - The application does not have metadata-complete="true", however when the application is deployed to WebSphere the option to set metadata-complete was selected.
                  This option will change the metadata-complete setting to "true". Stop using this option, or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



                  4 - The EJB is contained in a WAR module at level 2.4 or older. In WebSphere, annotations for older modules are not processed.



                  5 - The application includes a copy of the javax.ejb.EJB class. WebSphere provides the javax.ejb.EJB class, and it is loaded by the WebSphere runtime classloader. If the application also contains the javax.ejb.EJB class on the application classpath, then another instance will be loaded by the application classloader, and it will not match the instance used by the EJB Container. There should be a warning in the logs if this has occurred.



                  So yes, your scenario is required to be supported; however the specification does allow configurations that disable it. You just need to identify which configuration / packaging option has caused WebSphere to not see the @EJB annotation.






                  share|improve this answer













                  The EJB specification does require this scenario to work, depending on some configuration options; there are configuration options that may disable it.



                  The fact that you are seeing a NullPointerException indicates that WebSphere is not aware of the @EJB annotation on the field in the SampleServiceRoot class. Per the EJB specification, an instance of SampleServiceRoot cannot be created if the @EJB annotation cannot be resolved. Since an instance of SampleServiceRoot has been created, then one of the following has likely occurred:



                  1 - The application performed a new SampleServiceRoot rather than looking it up in JNDI. This doesn't sound like your problem, but good to double check.



                  2 - The application contains an ejb-jar.xml with the setting metadata-complete="true". When this is set, WebSphere will not look for annotations, and so will not see or process the @EJB annotation. Either change the setting to "false" or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



                  3 - The application does not have metadata-complete="true", however when the application is deployed to WebSphere the option to set metadata-complete was selected.
                  This option will change the metadata-complete setting to "true". Stop using this option, or add the <ejb-ref> or <ejb-local-ref> to the ejb-jar.xml file.



                  4 - The EJB is contained in a WAR module at level 2.4 or older. In WebSphere, annotations for older modules are not processed.



                  5 - The application includes a copy of the javax.ejb.EJB class. WebSphere provides the javax.ejb.EJB class, and it is loaded by the WebSphere runtime classloader. If the application also contains the javax.ejb.EJB class on the application classpath, then another instance will be loaded by the application classloader, and it will not match the instance used by the EJB Container. There should be a warning in the logs if this has occurred.



                  So yes, your scenario is required to be supported; however the specification does allow configurations that disable it. You just need to identify which configuration / packaging option has caused WebSphere to not see the @EJB annotation.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Nov 20 '18 at 15:51









                  TracyTracy

                  49827




                  49827

























                      0














                      Thanks for the answer,



                      we tried to move the declarations of the Local-Interface to the Remote Interface of the SampleServiceChild. Also we did not use @EJB annotation. We managed it with doing a lookup of the SampleServiceChild over the InitialContext.
                      Now it works






                      share|improve this answer




























                        0














                        Thanks for the answer,



                        we tried to move the declarations of the Local-Interface to the Remote Interface of the SampleServiceChild. Also we did not use @EJB annotation. We managed it with doing a lookup of the SampleServiceChild over the InitialContext.
                        Now it works






                        share|improve this answer


























                          0












                          0








                          0







                          Thanks for the answer,



                          we tried to move the declarations of the Local-Interface to the Remote Interface of the SampleServiceChild. Also we did not use @EJB annotation. We managed it with doing a lookup of the SampleServiceChild over the InitialContext.
                          Now it works






                          share|improve this answer













                          Thanks for the answer,



                          we tried to move the declarations of the Local-Interface to the Remote Interface of the SampleServiceChild. Also we did not use @EJB annotation. We managed it with doing a lookup of the SampleServiceChild over the InitialContext.
                          Now it works







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Nov 21 '18 at 17:13









                          Matthias HerbstMatthias Herbst

                          81




                          81






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Stack Overflow!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389111%2faccess-an-injected-stateful-session-bean-over-a-looked-up-stateful-session-bean%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Guess what letter conforming each word

                              Port of Spain

                              Run scheduled task as local user group (not BUILTIN)