JBoss 7.1: java.lang.IllegalStateException: No 'jboss' MBeanServer found - jboss

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'.

Related

How to resolve unmarshalling error after JBOSS EAP server migration from 6.4 to 7.4.3?

I am trying to migrate my application server (JBOSS EAP) from 6.4 to 7.4.3. But, after migration I am getting the below error while hitting my webservices.
Unwinding now: org.apache.cxf.interceptor.Fault: Unmarshalling error:
unexpected element (uri: ....) Caused by :
com.sun.istack.SAXParseException2; line number: 0; columnNumber: 0;
unexpected element (uri:....)
The same request was working absolutely fine in JBOSS EAP 6.4. But it is not working now after migration. I want to solve this without touching the codebase (means from server side - server config or server VM arguments etc.).
Can you try the following system property?
-Dcom.sun.xml.bind.backupWithParentNamespace=true

Trouble with Authenticating with remote EJB calls to Wildfly 10

I'm trying to do Remote EJB calls to my Wildfly 10/JBoss 7 EAP server, but keep getting Invalid User error messages on my Wildfly server (my EJB is called LoginManager):
23:04:02,872 ERROR [org.jboss.as.ejb3.invocation] (default task-6) WFLYEJB0034: EJB Invocation failed on component LoginManager for method public abstract java.lang.String ejbs.LoginManagerRemote.echo(java.lang.String): javax.ejb.EJBAccessException: WFLYSEC0027: Invalid User
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:69)
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:49)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:97)
I've added my user to the application-users.properties file using the add-user.sh/bat scripts.
I've tried putting in breakpoints in the Wildfly server itself in the SecurityContextInterceptor class on line 54 and see that the principal is null:
if (holder.skipAuthentication == false) {
holder.securityManager.authenticate(holder.runAs, holder.runAsPrincipal, holder.extraRoles);
I'm not entirely sure if this runAs or runAsPrincipal is the principal/credentials passed by the remote EJB invocation, but I suspect it might be responsible for my problem.
I'm calling the remote ejb as:
Properties p = new Properties();
p.setProperty(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
final Context context = new InitialContext(p);
LoginManagerRemote ejb = (LoginManagerRemote) context.lookup("ejb:ear-1.0/ejbs-1.0//LoginManager!ejbs.LoginManagerRemote");
return ejb.echo("test");
with my jboss-ejb-client.properties as:
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=8080
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.conncetion.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
remote.connection.default.username=test
remote.connection.default.password=test
Am I doing something wrong? Am I missing something obvious somewhere? What do I need to do to successfully call a remote EJB?
There's a typo in your jboss-ejb-client.properties
remote.conncetion.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
Should be remote.connection.default.connect.options etc etc

Error invoking a remote EJB method from a JSF managed bean in a portlet

I am trying to deploy a JSF portlet into a Liferay portal 6.2 running on top of a JBoss EAP 6.4, with OpenJDK 8. The portlet is deployed as a WAR file, but invokes some methods of an EJB through a remote interface. The EJB is deployed as an EAR file directly on JBoss.
On my developing machine it is working fine. But in a test machine it is not. There are exactly the same WAR and EAR files, the standalone.xml setup is almost the same for both machines, and also the JBoss modules are the same.
The stacktrace printed in the log is the following:
JBWEB000236: Servlet.service() for servlet Adminis Servlet threw exception: javax.portlet.faces.BridgeException: javax.faces.FacesException
at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:91) [liferay-faces-bridge-impl-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
at com.liferay.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:112) [liferay-faces-bridge-impl-3.2.4-ga5.jar:3.2.4-ga5 (Ephesus / Feb 15, 2014 AD)]
...
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_121]
Caused by: javax.faces.FacesException
at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:139) [jsf-impl-2.1.28.redhat-8.jar:2.1.28.redhat-8]
at org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:113) [icefaces-3.3.0.jar:]
... 194 more
Caused by: java.util.NoSuchElementException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1439) [rt.jar:1.8.0_121]
at java.util.HashMap$KeyIterator.next(HashMap.java:1461) [rt.jar:1.8.0_121]
at org.jboss.ejb.client.EJBClientContext.getEJBReceiver(EJBClientContext.java:725) [jboss-ejb-client-1.0.30.Final-redhat-1.jar:1.0.30.Final-redhat-1]
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146) [jboss-ejb-client-1.0.30.Final-redhat-1.jar:1.0.30.Final-redhat-1]
...
at com.sun.proxy.$Proxy459.obtenerUsuarioPorCodigo(Unknown Source)
at com.sofis.adminis.delegates.PermisosDelegate.obtenerUsuarioPorCodigo(PermisosDelegate.java:450) [adminis-delegate-1.0.jar:]
at com.sofis.security.web.UsuariosSessionBeanWeb.autenticar(UsuariosSessionBeanWeb.java:1927) [classes:]
at com.sofis.security.web.listeners.SofisAutologinLiferayPhaseListener.afterPhase(SofisAutologinLiferayPhaseListener.java:54) [classes:]
at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189) [jsf-impl-2.1.28.redhat-8.jar:2.1.28.redhat-8]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107) [jsf-impl-2.1.28.redhat-8.jar:2.1.28.redhat-8]
... 198 more
I rised the log level to "org.jboss.ejb.client" and now I see two interesting messages just before the stactrace:
22:13:16,684 DEBUG [org.jboss.ejb.client.EJBClientContext] (ajp-/0.0.0.0:8009-5) org.jboss.as.ejb3.remote.LocalEJBReceiverPreferringDeploymentNodeSelector#4bc9113e deployment node selector selected node for appname=SS-ADMINIS-ear-1.0,modulename=SS-ADMINIS-MAVEN-EJB-1.0,distinctname=
22:13:16,687 DEBUG [org.jboss.ejb.client.EJBClientContext] (ajp-/0.0.0.0:8009-5) Selected node doesn't belong to eligible receivers. Continuing with a random eligible receiver
Note that there is no node name in both messages (two blanks before "node").
In my developing machine, where it works, the first message does include a node name, and the second message does not appear:
18:56:37,902 DEBUG [org.jboss.ejb.client.EJBClientContext] (http-/0.0.0.0:8080-2) org.jboss.as.ejb3.remote.LocalEJBReceiverPreferringDeploymentNodeSelector#6db73304 deployment node selector selected spio node for appname=SS-ADMINIS-ear-1.0,modulename=SS-ADMINIS-MAVEN-EJB-1.0,distinctname=
The only diference is that in my machine I am going directly with the browser to the server ([Browser] -- HTTP --> [JBoss]) while in the testing machine I go through a load balancer ([Browser] -- HTTP --> [Apache] -- AJP --> [JBoss]). That is reflected in the messages (ajp-/0.0.0.0 vs http-/0.0.0.0).
The exception is thrown when I try to invoke a method from the EJB through the remote interface. The reference to the local stub is gotten by means of a lookup, and the result is not null. There are no errors at deploy and the lookup does not throw an error neither.
What can be happening or what am I missing?
A friend of mine found the solution.
Something a did't say is that the testing machine was in fact a docker container. And it seems that there is a bug in JBoss with docker making the former to not read the hostname to pick a node name, so de node name when it starts is empty. So the message above a empty name node being selected is shown, and then the error.
The workaround is to specify a node name with the -Djboss.node.name parameter to JBoss. I put that setting in the standalone.conf, restarted the JBoss and it worked fine. Now, the first message shows the name I specified, and the second message does not appear, nor the exception.

Wildfly10 (EAP 7) call jboss 5.0.1 EJB without legacy jars

Dears,
I'm trying to call ejb3 in jboss 5.0.1 from Wildfly 10 or EAP 7.
My code:
final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
env.put("java.naming.factory.url.pkgs", "org.jboss.ejb.client.naming");
env.put(Context.PROVIDER_URL, "remoting://localhost:1099");
env.put("org.jboss.ejb.client.scoped.context", "true");
InitialContext initialContext = new InitialContext(env);
TestBeanRemote remote = (TestBeanRemote) initialContext.lookup(
"ejb:TestEar/TestBean/TestBean!com.test.TestBeanRemote");
but it says:
Exception in thread "main" java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:BilllingFacadeCallbackEAR, moduleName:BilllingFacadeCallback, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext#3b088d51
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:798)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:128)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy2.getActions(Unknown Source)
at TestStandalone.main(TestStandalone.java:28)
Is there any solution to call legacy jboss without old jars?
There is a legacy subsystem for this but I don't know its current status.
https://github.com/jboss-set/jboss-as-legacy
The CORBA standard defines an "across the wire" standard for making remote method calls called IIOP or "Internet Inter-ORB Protocol".
You need to set up to use CORBA IIOP in order to make platform independent remote EJB calls.
Therefore, you need to:
configure JBoss 5 so that it can handle incoming IIOP calls;
configure WildFly 10/EAP 7 to make outgoing EJB invocations using IIOP.
There is some information on this in the WildFly 10 EJB3 Reference Guide although I'm not sure how up to date that is.
The issue is normally caused by a transaction reaching it's timeout value.
So it may be that the application logic is correctly handling the scenario in this case and is not attempting to retry activity
It can have several issues :
connection: Connection broken
security : user/pass invalid
EJB missing: connected, but ejb is not there
SSL
Ports
IP Address
JBoss maintains a persistent connection to the other server, so when the client sees this message it means there is no connection to a server that has the ejb you are trying to call, so a message will be logged when the connection fails to the other server.
Caused by: java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling
Can you clarify the below:
1# is your EJBs deployed on jboss 5.0.1?
2# You are invoking the EJBS from Wildfly 10 or EAP 7, means your client is deployed in Wildfly 10 or EAP 7?

InitialContext.lookup() parameter in JBoss 7.1

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