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
Related
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)
0
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:....)
Thus, I have added -Dcom.sun.xml.bind.backupWithParentNamespace=true system property in my JBOSS server VM argument to resolve above issue. Now, I am getting good responses but the below two lines are missing in my new JBOSS(JBOSS EAP 7.4.3) webservice response.
First Line - <xml version="1.0" encoding="UTF8"?> and
Second Line - <SOAP-ENV:Header xmlns:SOAP-ENV=...>
But this two lines were present in older JBOSS EAP 6.4 response. Should I need to add any other system property for this. Please help me on this.
Reagrds, Ritesh
I have deployed my application on JBoss EAP 7 in SSL mode.
My application gets deployed and runs successfully but during start up,
I get following error on console every time when server starts up and WAR is simultaneously deployed, no exception is thrown.
11:28:11,402 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 92) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("subsystem" => "undertow"),
("server" => "default-server"),
("https-listener" => "defaultssl")
]) - failure description: "WFLYCTL0216: Management resource '[(\"subsystem\" => \"undertow\")]' not found"
I have been searching Red Hat JBoss Knowledgebase, but have not found any solution to this issue.
This issue is not reproduced, if I deploy my WAR after the application server completely starts up and is initialised.
This issue does not affect my application though.
This issue is not reproduced on JBoss EAP 6.x, JBoss AS 7.1.x and Wildfly.
What can be the reason of such issue?
I observed the behavior of the JBoss EAP 7 application server. The undertow subsystem is not loaded during the server initialization. This issue occurs when application tries to access the details of the undertow subsystem during startup. When the application is deployed after server has started this issue does not occur.
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.
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'.