I am new in the world of EJB 3.1 and trying to get some basics with the JBoss Application Server 7.1.
At the moment I am stuck at a - really basic - problem. When a bean on the server wants to use another bean I need to use the InitialContext.lookup() method. If I look in the literature I found calls like:
TheBean = (<Interface>) new InitialContext().lookup("<NameOfTheBean>/local");
But this call doesn’t work for me. Every time I get an error like this:
javax.ejb.EJBException: javax.naming.NameNotFoundException
After hours of looking for a solution I found code examples which use another call, something like this:
TheBean = (<Interface>) new InitialContext().lookup("ejb:/<Package>//<NameOfTheBean>!<Package>.<Interface>");
Well this solution works for me but the question is why? Does somebody know why the first call produces exceptions while the second one works fine?
Thanks a lot!
Why? Different versions of JBoss deploys beans with differently default names in JNDI namespace.
ctx.lookup("BeanName/local")
was right for the JBoss 4.x.x and higher but not for JBoss v7.
You can see in you server.log of JB7 how your beans mapped to JNDI names,
for example (see java:/jboss/exported/... and how it correspond to your second successive call):
13:57:05,550 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-4) JNDI bindings for session bean named ProductionHistoryBean in deployment unit deployment "navi-ejb3.jar" are as follows:
java:global/navi-ejb3/ProductionHistoryBean!navi.ejb3.production.history
.ProductionHistoryRemote
java:app/navi-ejb3/ProductionHistoryBean!navi.ejb3.production.history.Pr
oductionHistoryRemote
java:module/ProductionHistoryBean!navi.ejb3.production.history.Productio
nHistoryRemote
java:jboss/exported/navi-ejb3/ProductionHistoryBean!navi.ejb3.production
.history.ProductionHistoryRemote
java:global/navi-ejb3/ProductionHistoryBean
java:app/navi-ejb3/ProductionHistoryBean
java:module/ProductionHistoryBean
Related
Although there already are quite some StackOverflow questions, blog entries, etc. on the web, I still cannot figure out a solution to the problem stated below.
Similar to this question (Injecting EJB within JAX-RS resource on JBoss7) I'd like to inject a EJB instance into a JAX-RS class. I tried with JBoss 5, JBoss 7, and WildFly 8. I either get no injection at all (field is null), or the server does not deploy (as soon as I try to combine all sorts of annotations).
Adding #Stateless to the JAX-RS makes the application server know both classes as beans. However, no injection takes place.
Is there a way to inject EJBs into a REST application? What kind of information (in addition to that contained in the question linked to above) could I provide to help?
EDIT: I created a Github project showing code that works (with Glassfish 4.0) and does not work (with JBoss 5).
https://github.com/C-Otto/beantest
Commit 4bf2f3d23f49d106a435f068ed9b30701bbedc9d works using Glassfish
4.0.
Commit 50d137674e55e1ceb512fe0029b9555ff7c2ec21 uses Jersey 1.8, which does not work.
Commit 86004b7fb6263d66bda7dd302f2d2a714ff3b939
uses Jersey 2.6, which also does not work.
EDIT2:
Running the Code which I tried on JBoss 5 on Glassfish 4.0 gives:
Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Ref<ContainerRequest>] with qualifiers [#Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] #Inject org.glassfish.jersey.server.internal.routing.UriRoutingContext(Ref<ContainerRequest>, ProcessingProviders)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Ref<ContainerRequest>] with qualifiers [#Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] #Inject org.glassfish.jersey.server.internal.routing.UriRoutingContext(Ref<ContainerRequest>, ProcessingProviders)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
EDIT3: The crucial information might be that I'd like a solution that works on JBoss 5
If you don't want to make your JAX-RS resource an EJB too (#Stateless) and then use #EJB or #Resource to inject it, you can always go with JNDI lookup (I tend to write a "ServiceLocator" class that gets a service via its class.
A nice resource to read about the topic:
https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project
A sample code:
try {
// 1. Retreive the Home Interface using a JNDI Lookup
// Retrieve the initial context for JNDI. // No properties needed when local
Context context = new InitialContext();
// Retrieve the home interface using a JNDI lookup using
// the java:comp/env bean environment variable // specified in web.xml
helloHome = (HelloLocalHome) context.lookup("java:comp/env/ejb/HelloBean");
//2. Narrow the returned object to be an HelloHome object. // Since the client is local, cast it to the correct object type.
//3. Create the local Hello bean instance, return the reference
hello = (HelloLocal)helloHome.create();
} catch(NamingException e) {
} catch(CreateException e) {
}
This is not "injecting" per-se, but you don't use "new" as-well, and you let the application server give you an instance which is managed.
I hope this was useful and I'm not telling you something you already know!
EDIT:
This is an excellent example: https://docs.jboss.org/author/display/AS72/EJB+invocations+from+a+remote+client+using+JNDI
EDIT 2:
As you stated in your comment, you'd like to inject it via annotations.
If the JNDI lookup is currently working for you without problems, and
If you're using Java EE 6+ (which I'm guessing you are), you can do the following:
#EJB(lookup = "jndi-lookup-string-here")
private RemoteInterface bean;
I already have a integration-test phase, when I ran the selenium tests. I also want to run some unit tests in this phase, because the app is too much complex and have a lot of dependencies between his modules (a hell), so, after a week fighting against OpenEJB and Arquillian, I believe that this would be easier.
The thing is: how do I made it work?
I have the instance already running, if I instantiate an InitialContext and try to lookup some bean, I got an exception telling me that I have not set the java.naming.initial.factory, and I don't know what to put in there.
I'm also complaining about the annotated beans.
Suppose a Bean like this:
#Stateless
public class ABeanImpl implements ABean {
#EJB
private BBean;
}
Will the container automatically get right the BBean?
Thanks in advance
How to connect to JBoss 7.1 remote JNDI:
Here is the code snippet that I use for JBoss 7.1:
Properties props = new Properties();
String JBOSS_CONTEXT = "org.jboss.naming.remote.client.InitialContextFactory";
props.put("jboss.naming.client.ejb.context", true);
props.put(Context.INITIAL_CONTEXT_FACTORY, JBOSS_CONTEXT);
props.put(Context.PROVIDER_URL, "remote://localhost:4447");
props.put(Context.SECURITY_PRINCIPAL, "jboss");
props.put(Context.SECURITY_CREDENTIALS, "jboss123");
InitialContext ctx = new InitialContext(props);
Resolution of ambiguous ejb references:
According to JBoss EJB 3 reference, if at any level of your EJB environment (EJB/EAR/Server) are duplicates in used interfaces, exception will be thrown during resolution of injected beans.
Based on above, if you have got a reference to EJB bean which interface:
has two implementations in your EJB module (JAR/WAR) - exception will be thrown
has two implementations in your application (other EJB JAR's in same EAR) - exception will be thrown
has two implementations, one in module with bean ABeanImpl, second somewhere else - implemetation from current module is used.
I'm using camel 2.11-SNAPSHOT in an ear which is running on JBoss AS 7.1.
When deploying the app and while the routes are being constucted (in a #Singleton #Startup bean, using an #Injected CdiCamelContext) i get a lot of warnings (ca. 30) like this in my server log:
2013-03-20 16:40:55,153 WARNING [org.apache.deltaspike.core.api.provider.BeanManagerProvider] (MSC service thread 1-2) When using the BeanManager to retrieve Beans before the Container is started, non-portable behaviour results!
and after the the context has been started i get this WARNINGs:
2013-03-20 16:40:56,339 WARNING [org.apache.deltaspike.core.api.provider.BeanManagerProvider] (Camel (camel-2) thread #1 - file:///tmp/exchange/tmobile/in) When using the BeanManager to retrieve Beans before the Container is started, non-portable behaviour results!
What does it mean? I couldn't find anything useful on google. Is it a bug? Did i configure camel wrong?
It is simply a warning from Apache Deltaspike that the bean manager was accessed before the container was booted. It seems Camel's integration with CDI uses some non-portable features, but assuming that they know what they're doing, it could be nothing.
My application is deployed on JBoss 7.1 (standalone).
I am getting an exception on the following line:
MBeanServerConnection server = MBeanServerLocator.locateJBoss();
The exception is:
JBoss: java.lang.IllegalStateException: No 'jboss' MBeanServer found!
That code above worked fine when the app was deployed on JBoss 5.
From what I was reading online, the code is supposed to work only when it's called from the same JVM in which the MBeanServer was created. Otherwise it's a remote call and I have to use JNDI. But is it not a local call (same JVM - i.e. the JBoss JVM)? How did it work on JBoss 5 then?
How do I make it work on JBoss 7.1 standalone, without changing this specific code?
Here is the solution:
https://community.jboss.org/thread/221708
Quote:
Above problem is dueto locateJboss implementation that is compatible with older version of Jboss. The MBeanServer used by JBoss 7 (by default) is the platform MBeanServer. The class name iscom.sun.jmx.mbeanserver.JmxMBeanServer and the default domain is DefaultDomain. Accordingly, you can simply use:
java.lang.management.ManagementFactory.getPlatformMBeanServer()
Alternatively:
for(MBeanServer server: javax.management.MBeanServerFactory.findMBeanServer(null)) {
if("DefaultDomain".equals(server.getDefaultDomain())) return server;
}
throw new Exception("Failed to locate MBeanServer");
On another note, jboss.system:type=ServerInfo object name doesn't work in AS 7.1 I had to use JVM specific parameters to nail down to MBean attributes. 'java.lang:type=Memory' and attribute as 'HeapMemoryUsage'.
Deploying an application in WAS 8 gives me an error:
Cannot find a match for supplied option: "[ejb.jar, ejbName, ejb.jar,META-INF/ibm-ejb-jar-bnd.xml, ejb/ejbName]" for task "BindJndiForEJBNonMessageBinding"
my entry in ibm-ejb-jar-bnd.xml
<session name="ejbName">
<interface class="com.manager.EJBNameManager" binding-name="ejb/ejbName"/></session>
my entry in deploy.jacl
[-BindJndiForEJBNonMessageBinding ejb.jar ejbName ejb.jar,META-INF/ibm-ejb-jar-bnd.xml ejb/ejbName]
my ejb.jar structure has META-INF/ibm-ejb-jar-bnd.xml also.
Was my entry in ibm-ejb-jar-bnd.xml correct? Please enlighten me on this one. Thanks.
Instead of providing the path to your ejb jar bindings (ejb.jar,META-INF/ibm-ejb-jar-bnd.xml), you should be providing the path to your ejb deployment descriptor (e.g. ejb.jar,META-INF/ejb-jar.xml).
In addition, you shouldn't even need the ejb bindings file, because you are creating the binding using JACL. The ibm-ejb-jar-bnd.xml file will automatically be created for you as a result of your deployment.
(Also, as a side note, WAS deprecated its use of JACL in WAS 7, so you should consider using jython for your wsadmin scripts instead.)