Jboss Startup error - jboss

On an existing application I am trying to startup the JBOSS server and I get following error.
Unfortunately I do not know clearly as yet, what all has been configured and is being used on this jboss. For now; I quickly want to get the error sorted out.
If looking at the stack trace, you can suggest what kind of configuration is missing or what I should be looking at to fix this problem; then I'll be really grateful.
any help is appreciated.
------------------After Skaffman's help below; I was able to reduce the stacktrace to this------------------
07:36:36,971 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- MBeans waiting for other MBeans ---
ObjectName: xyz.management:service=Queue,name=managementQueue
State: CONFIGURED
I Depend On:
jboss.messaging:service=ServerPeer
ObjectName: xyz.management:service=Queue,name=indexQueue
State: CONFIGURED
I Depend On:
jboss.messaging:service=ServerPeer
ObjectName: xyz.management:service=Queue,name=adaptiveLearningQueue
State: CONFIGURED
I Depend On:
jboss.messaging:service=ServerPeer
ObjectName: xyz.management:service=Queue,name=xyzErrorQueue
State: CONFIGURED
I Depend On:
jboss.messaging:service=ServerPeer
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.messaging:service=ServerPeer
State: NOTYETINSTALLED
Depends On Me:
xyz.management:service=Queue,name=managementQueue
xyz.management:service=Queue,name=indexQueue
xyz.management:service=Queue,name=adaptiveLearningQueue
xyz.management:service=Queue,name=xyzErrorQueue
javax.naming.NameNotFoundException: XAConnectionFactory not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:589)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.ejb.plugins.jms.DLQHandler.createService(DLQHandler.java:182)
at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:188)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker.innerStartDelivery(JMSContainerInvoker.java:665)
at org.jboss.ejb.plugins.jms.JMSContainerInvoker$ExceptionListenerImpl$ExceptionListenerRunnable.run(JMSContainerInvoker.java:1594)
at java.lang.Thread.run(Thread.java:619)

I think you have multiple issues here.
JBoss is trying to deploy the file velocity.log which it has found in its deploy directory. This is clearly not what you intended, but realise that any files that get dropped into the deploy directory , JBoss will try and deploy. You need to find out what's doing that, and stop it.
The second problem is that you have a bunch of JMS deployments (e.g. MDBs) somewhere in your application, but JMS is not present (or has not been configured correctly) on this server.

Related

JBoss automatic .war redeployment can't start application properly - Error on Keycloak redirection

A colleague of mine wants to automate their JBoss (JBoss EAP v7.4.0) deployments.
So far the process they followed manually was:
Shutdown Jboss entirely
Copy the new .war file under /jboss-eap-7.4.0/standalone/deployments directory
Restart the server by executing standalone.sh
This process, although a bit 'dump', manages to deploy the application with no issues.
I on the other hand, tried to make use of JBoss's auto-redeployment feature, so I simply pasted the new .war file under the /jboss-eap-7.4.0/standalone/deployments directory.
JBoss indeed picks up the new .war and automatically starts the redeployment process.
From the server.log file, it seems at first that the application deploys successfully.
However when I try to access it from my browser, it crashes and gives a code 500 response (See error logs at the end of the post). The expected behavior would be to redeploy me to keycloak in order to login.
The exact same error occurs if I try to manually undeploy and deploy the .war from the jboss.cli.
Any hints on the issue?
I can't figure out if the error is on the server or the application side.
It seems a bit odd that it should require a full JBoss server restart in order for the application to be properly deployed.
Thank you in advance.
Server logs:
2022-06-14 17:22:25,850 WARN [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) The input bytes to the digest operation are null. This may be due to a problem with the Reference URI or its Transforms.
2022-06-14 17:22:25,879 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /myapplication: java.lang.RuntimeException: Could not create authentication request.
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:64)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.ElytronHttpFacade.noAuthenticationInProgress(ElytronHttpFacade.java:123)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.KeycloakHttpServerAuthenticationMechanism.evaluateRequest(KeycloakHttpServerAuthenticationMechanism.java:125)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:119)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SocketAddressCallbackServerMechanismFactory$1.evaluateRequest(SocketAddressCallbackServerMechanismFactory.java:82)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:85)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:326)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$800(HttpAuthenticator.java:301)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:94)
at org.wildfly.security.elytron-web.undertow-server#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl.authenticate(ServletSecurityContextImpl.java:115)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.jboss.xnio#3.8.4.Final-redhat-00001//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.xml.serializer.utils.WrappedRuntimeException: class org.apache.xml.serializer.ToXMLSAXHandler cannot be cast to class org.apache.xml.serializer.SerializationHandler (org.apache.xml.serializer.ToXMLSAXHandler is in unnamed module of loader 'deployment.myapplication.war' #15a25903; org.apache.xml.serializer.SerializationHandler is in unnamed module of loader 'deployment.myapplication.war' #68ae4310)
at deployment.myapplication.war//org.apache.xml.serializer.SerializerFactory.getSerializer(SerializerFactory.java:179)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:261)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:330)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getNodeAsString(DocumentUtil.java:228)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getDocumentAsString(DocumentUtil.java:207)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.getSAMLResponse(BaseSAML2BindingBuilder.java:311)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.buildHtmlPostResponse(BaseSAML2BindingBuilder.java:307)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.getHtmlRequest(BaseSAML2BindingBuilder.java:172)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.SamlUtil.sendSaml(SamlUtil.java:45)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.profile.AbstractSamlAuthenticationHandler$3.sendAuthnRequest(AbstractSamlAuthenticationHandler.java:622)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:61)

How can i solve java.lang.IllegalStateException: Illegal access:?

I am using Eclipse to develope a webapp. Everything was working fine, but sometimes when I tried to publist->start my server, I received the following error:
Oct 03, 2019 6:52:55 PM org.apache.catalina.loader.WebappClassLoaderBase checkStateForResourceLoading
INFO: Illegal access: this web application instance has been stopped already. Could not load []. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.
java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load []. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.
at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1383)
at org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1036)
at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.checkThreadContextClassLoader(AbandonedConnectionCleanupThread.java:117)
at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:84)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
For the first few times, I just restarted the server, and it was working fine, but now even a restart doesent solve the problem. I read about it online, and some sources mentioned that it might be a thread management issue, but I couldn't get further than that. Can anybody please provide some info? Thanks.
The mysql driver is trying to clean-up on web application shutdown which is good. Unfortunately it is trying to load additional classes to perform this clean-up and - since the web application is shutting down - class loading is no longer available. Ideally, the driver would load all the classes it needed to clean-up when it firsts loads - that would avoid this issue.
If you can figure out which classes it is trying to load - a check of the driver source code should show you which - then you should be able to load them yourself on application start in, for example, a ServletContextListener.
If you created any Entity class and forgot to give ID to any specific column then also this problem occurs. So assign #ID to any column and run again. your issue will resolve.

Kubernetes java.io.IOException: Broken pipe error

I am trying deploy a pod to a kubernetes 11.2 cluster and seeing this error.
Weird part is that this workers fine on another cluster (different envs) and config is same exact. Only thing, I noticed is with this failing cluster, I felt like the nodes were little slow to login. But everything seems to be deploying correctly, except for this error.
There are no changes to the code or the config to deploy, what could be the reason for this to happen only on this particular cluster and not other envs. (It works on dev, test and pre-prod) doesn't work on prod, totally dazed I am and not sure if this is infrastructure issue possibly to the kubernetes config or the application needs to be able to handle this. another thing is that i don't see the nodes going down or any errors related to the memory or lack of resources, like disk pressure and such.
any advise would be highly appreciated.
2018-09-02 18:29:51.048 INFO 29 --- [-nio-443-exec-6] f.a.AutowiredAnnotationBeanPostProcessor : JSR-330 'javax.inject.Inject' annotation found and supported for autowiring
2018-09-02 18:29:56.493 ERROR 29 --- [-nio-443-exec-6] c.t.s.est.server.ServletDispatcher : An unexpected error occured while processing a request on the following uri /.well-known/est/App Service/senroll
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe
...
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[na:1.8.0_171]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) ~[na:1.8.0_171]
...
2018-09-02 18:29:56.499 ERROR 29 --- [-nio-443-exec-6] o.a.c.c.C.[.[.[/].[servletDispatcher] : Servlet.service() for servlet [servletDispatcher] in context with path [] threw exception
java.lang.IllegalStateException: Cannot call sendError() after the response has been committed
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:472) ~[tomcat-embed-core-8.5.16.jar!/:8.5.16]
at com.trilliantnetworks.security.est.server.ServletDispatcher.unexpectedError(ServletDispatcher.java:230) ~[est-servlet-1.0.1-SNAPSHOT.jar!/:na]
at com.trilliantnetworks.security.est.server.ServletDispatcher.doPost(ServletDispatcher.java:211) ~[est-servlet-1.0.1-SNAPSHOT.jar!/:na]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:661) ~[tomcat-embed-core-8.5.16.jar!/:8.5.16]
...
...
2018-09-02 18:29:56.527 ERROR 29 --- [-nio-443-exec-6] o.a.c.c.C.[Tomcat].[localhost] : Exception Processing ErrorPage[errorCode=0, location=/error]
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:321) ~[tomcat-embed-core-8.5.16.jar!/:8.5.16]
at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:284) ~[tomcat-embed-core-8.5.16.jar!/:8.5.16]
The nodes are fine. They are not going down or anything. I also looked at the events to see if any errors related to memory show up, but unfortunately nothing.
So, I am seeing this error in one of the pods, which installs some things to the database. This is the first step and should not fail
Mainly this is happening, the read timeout. So, I am wondering if there is some kind of timeout that  I can set in the cluster, to wait for the API response, little longer.
2018-09-02 18:33:35.818 INFO 29 --- [ main] c.t.s.c.i.r.impl.ExternalSignerService : Exception while generatePermanentKeyStore:java.net.SocketTimeoutException: Read timed out

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.

Glassfish 3.x start failed

i'm trying to run my java EE web application on Glassfish v3.x on Netbeans 7 but it wont work, and gives me the following error: Glassfish 3.x start failed.
i don't know what's the problem glassfish used to work fine before but then suddenly stoped working i unistalled netbeans and glassfish n install it again, but still the same problem.
here is the glassfish log:
Launching GlassFish on Felix platform
INFO: Registered org.glassfish.ha.store.adapter.cache.ShoalBackingStoreProxy for persistence-type = replicated in BackingStoreFactoryRegistry
INFO: Grizzly Framework 1.9.31 started in: 585ms - bound to [0.0.0.0:3700]
INFO: Grizzly Framework 1.9.31 started in: 580ms - bound to [0.0.0.0:8181]
INFO: Grizzly Framework 1.9.31 started in: 738ms - bound to [0.0.0.0:8080]
INFO: Grizzly Framework 1.9.31 started in: 584ms - bound to [0.0.0.0:7676]
INFO: Grizzly Framework 1.9.31 started in: 539ms - bound to [0.0.0.0:4848]
GRAVE: Exception while visiting com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class of size 84805
java.lang.ArrayIndexOutOfBoundsException: 48188
at org.objectweb.asm.ClassReader.readClass(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:362)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171)
at com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:346)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:305)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:294)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
INFO: SEC1002: Security Manager is OFF.
INFO: SEC1010: Entering Security Startup Service
INFO: SEC1143: Loading policy provider com.sun.enterprise.security.provider.PolicyWrapper.
INFO: SEC1115: Realm [admin-realm] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.
INFO: SEC1115: Realm [certificate] of classtype [com.sun.enterprise.security.auth.realm.certificate.CertificateRealm] successfully created.
INFO: SEC1011: Security Service(s) Started Successfully
INFO: WEB0169: Created HTTP listener [http-listener-1] on host/port [0.0.0.0:8080]
INFO: WEB0169: Created HTTP listener [http-listener-2] on host/port [0.0.0.0:8181]
INFO: WEB0169: Created HTTP listener [admin-listener] on host/port [0.0.0.0:4848]
INFO: WEB0171: Created virtual server [server]
INFO: WEB0171: Created virtual server [__asadmin]
INFO: WEB0172: Virtual server [server] loaded default web module []
INFO: Initialisation de Mojarra 2.1.0 (FCS 2.1.0-b11) pour le contexte '/mavenproject1'
INFO: Monitoring jndi:/server/mavenproject1/WEB-INF/faces-config.xml for modifications
INFO: PWC1412: WebModule[null] ServletContext.log():Initializing Spring root WebApplicationContext
Best Regards.
I know this was asked months ago but this question being one of the few sources i found in Google when encountering this problem, I think it'd good to share what bit i learnt:
I had the same exact problem and tried both things stated above. Still, my XML files didn't seem to be corrupted. In the end I found that the root of the problem was on the icu4j library which was, dont know why, among the dependencies in my project. Once I removed it, I was free of that error at last!
Should also be noted that Netbeans 7.0.1 (The IDE I'm using) also "uses" this library. I moved this library out of its original location just in case. NB continues to run without any problems so far.
Hope it helps someone else too!
I fixed mine in this way. It seemed that my XML file for the domain was corrupt ( I have no idea how) but what i did is as follows:
Remove your current server from the server node( right click and remove), then make a new server, except when it says to pick a domain, type in your own domain name (EX. myDomain) and then set up the server.
Wait for a few seconds, and bam, new XML file, not corrupt, and you should be able to run your server perfectly fine!
That's strange... How it does say "startup failed" if it loaded your app? Take a look at the last three lines of the log!
I had some problems like this, but all I needed is to right-click on the GF server node on "Services" tab and "refresh" it. Usually NB consider a slow GF startup as "failed".
Another answer which is possible now if using Java 8, but not at the time the OP asked, is that the server code contains lambdas. If you do have lambdas in your code, try to replace them with anonymous inner classes and your class(es) that were affected should now be good to go.