Access an injected Stateful Session Bean over a looked up Stateful Session Bean
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
add a comment |
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
add a comment |
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
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
java ejb websphere jboss-eap-7 stateful
asked Nov 20 '18 at 8:40
Matthias HerbstMatthias Herbst
81
81
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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.
add a comment |
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 20 '18 at 15:51
TracyTracy
49827
49827
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Nov 21 '18 at 17:13
Matthias HerbstMatthias Herbst
81
81
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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