Thread.currentThread().getName() is not returning client IP address JBOSS EAP7.0 - jboss-eap-7

We are migrating server from jboss-portal to jboss EAP7.0. When I execute the code Thread.currentThread().getName() in portal result is returning client ip address. Where as if I use the same statement in jboss-eap 7.0 result (default task-20).
i wanted to print the client ip address in log file right now (%t) is works well in jboss-portal. Where as jboss-eap 7.0 results empty.
How do I achieve this? Thanks.

You can use the pattern %h to print the host in the log file. For example (given the default logging configuration):
/subsystem=logging/pattern-formatter=COLOR-PATTERN:write-attribute(name=pattern, value="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %h %s%e%n")
Would print a log line like the following on the console:
08:21:01,540 INFO [org.jboss.as.server] (Controller Boot Thread) localhost WFLYSRV0212: Resuming server
08:21:01,548 INFO [org.jboss.as] (Controller Boot Thread) localhost WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
08:21:01,549 INFO [org.jboss.as] (Controller Boot Thread) localhost WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
08:21:01,549 INFO [org.jboss.as] (Controller Boot Thread) localhost WFLYSRV0025: WildFly Core 3.0.0.Beta22-SNAPSHOT "Kenny" started in 93ms - Started 87 of 90 services (23 services are lazy, passive or on-demand)

Related

Wildfly throws UnsupportedOperationException (Naming context is read-only) on start

We're setting up a new staging server (running Ubuntu), and are encountering errors when starting WildFly. The main one seens to be
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
which then causes many errors about missing dependencies.
We have set up our (liquibase) database on another server, which we can ssh into internally. We've scoured StackOverflow as well, and attempted to add
set "JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=**true**"
to our standalone.conf, standalone.bat, and standalone.conf.bat (for the sake of having tried everything!). We also saw that this should've been fixed in WildFly 7.1.1, we're running 9 ourselves (to emulate the live server).
We tried manually installing the dependencies but there are so many - and honestly we think that's just not the main issue.
We're also running nginx and Redis, we saw in the server.log (see below) that the error happens after "Started Hibernate Redis cache" but the error itself seems to be specific to WildFly.
A chunk of server.log is below:
2019-04-03 10:52:38,252 INFO [com.company.ejb.util.config.ConfigRetriever] (ServerService Thread Pool -- 56) Successfully found and read the config file at /opt/wildfly/config.yml
2019-04-03 10:52:38,300 INFO [com.company.ejb.entity.cache.RedisRegionFactory] (ServerService Thread Pool -- 56) Started Hibernate Redis cache
2019-04-03 10:52:46,896 INFO [org.jboss.weld.Event] (MSC service thread 1-2) WELD-000411: Observer method [BackedAnnotatedMethod] com.sun.jersey.server.impl.cdi.CDIExtension.processAnnotatedType(#Observes ProcessAnnotatedType<Object>) receives events for all annotated types. Consider restricting events using #WithAnnotations or a generic type with bounds.
2019-04-03 10:52:47,041 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."DoThePublish.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."DoThePublish.ear".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:161)
at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:151)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:417)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.createSubcontext(InitialContext.java:298)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:425)
[...]
2019-04-03 10:52:47,078 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "DoThePublish.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"DoThePublish. ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DoThePublish.ear\".WeldStartService: Failed to
start service
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:161)
at org.jboss.as.naming.WritableServiceBasedNamingStore.createSubcontext(WritableServiceBasedNamingStore.java:151)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:417)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.createSubcontext(InitialContext.java:298)
at org.jboss.as.naming.NamingContext.createSubcontext(NamingContext.java:425)
[...]
"}}
2019-04-03 10:52:47,178 INFO [org.jboss.as.server] (ServerService Thread Pool -- 32) WFLYSRV0010: Deployed "DoThePublish.ear" (runtime-name : "DoThePublish.ear")
2019-04-03 10:52:47,186 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."DoThePublish.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."DoThePublish.ear".WeldStartService: Failed to start service
2019-04-03 10:52:47,581 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
2019-04-03 10:52:47,582 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
2019-04-03 10:52:47,582 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 9.0.1.Final (WildFly Core 1.0.1.Final) started (with errors) in 42472ms - Started 4599 of 5108 services (362 services failed or missing dependencies, 209 services are lazy, passive or on-demand)
Then following that there's a bunch of missing dependencies (there's looaaaads of these):
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.CREATE (missing) dependents: [service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.START]
service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.START (missing) dependents: [service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".moduleDeploymentRuntimeInformationStart, service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".deploymentCompleteService]
service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.VIEW."com.company.ejb.session.AbstractEntityMainSBL".LOCAL (missing) dependents: [service jboss.deployment.subunit."DoThePublish.ear"."CoreEjb.jar".component.AbstractEntityMainSB.START]
We've tried comparing the setup to the existing production (live) server, but there has been a big turnaround in the dev team so no-one knows exactly how they're set up. There are no setup instructions so we're trying things as we go along - perhaps the previous server encountered these same issues but we've no idea.
We are wanting to fix this exception to hopefully be able to start wildfly (and thus our website) without issues (or at least move on to the next error...) Any help is greatly appreciated!
So after a bunch of trying, we figured it out. The line we tried to implement needed to be changed a bit:
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true"
So we removed the 'set' and removed the asterisks and stuff. In our case it was the .conf file that needed the line, I believe for different types of implementations it might be the .bat or .conf.bat - sorry I can't help further with that.
Hope this helps someone else!
I recently got this same error on startup of JBOSS EAP 7.2 and Wildfly 12. In my case, it's an old Hibernate Java application. The mapping of entities in the hibernate.cfg.xml. My problem was that someone put the name attribute in the <session-factory name="">, and that particular application goes up two contexts! On the startup of the second context, I get the error:
java.lang.UnsupportedOperationException: WFLYNAM0043: Naming context is read-only
Removing the name from the session-factory solved the problem.

Tiles + Spring + wildfly 11 + java 8: java.lang.UnsupportedOperationException: This parser does not support specification "null" version "null"

I deploy a ear with spring4, tiles 3.0.7, java 8 and in wildfly 11 but i get the following error:
:45:18,865 INFO [org.jboss.as] (Controller Boot Thread)
WFLYSRV0060: Http management interface listening on
http://127.0.0.1:9990/management
00:45:18,865 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
00:45:18,865 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
started in 15761ms - Started 915 of 1144 services (356 services are
lazy, passive or on-demand)
00:45:19,773 ERROR Digester:789 - Digester.getParser:
java.lang.UnsupportedOperationException: This parser does not support specification "null" version "null"
at javax.xml.parsers.SAXParserFactory.setSchema(SAXParserFactory.java:394)
at __redirected.__SAXParserFactory.setSchema(__SAXParserFactory.java:158)
at org.apache.commons.digester.Digester.getFactory(Digester.java:536)
at org.apache.commons.digester.Digester.getParser(Digester.java:786)
at org.apache.commons.digester.Digester.getXMLReader(Digester.java:1058)
at org.apache.commons.digester.Digester.parse(Digester.java:1887)
at org.apache.tiles.definition.digester.DigesterDefinitionsReader.read(DigesterDefinitionsReader.java:325)
at org.apache.tiles.definition.dao.BaseLocaleUrlDefinitionDAO.loadDefinitionsFromResource(BaseLocaleUrlDefinitionDAO.java:150)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadRawDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:234)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadRawDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:225)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadRawDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:225)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadDefinitionsFromResources(CachingLocaleUrlDefinitionDAO.java:203)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.loadDefinitions(CachingLocaleUrlDefinitionDAO.java:192)
at org.apache.tiles.definition.dao.ResolvingLocaleUrlDefinitionDAO.loadDefinitions(ResolvingLocaleUrlDefinitionDAO.java:68)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.checkAndloadDefinitions(CachingLocaleUrlDefinitionDAO.java:174)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.getDefinitions(CachingLocaleUrlDefinitionDAO.java:131)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.getDefinition(CachingLocaleUrlDefinitionDAO.java:105)
at org.apache.tiles.definition.dao.CachingLocaleUrlDefinitionDAO.getDefinition(CachingLocaleUrlDefinitionDAO.java:49)
at org.apache.tiles.definition.UnresolvingLocaleDefinitionsFactory.getDefinition(UnresolvingLocaleDefinitionsFactory.java:89)
at org.apache.tiles.impl.BasicTilesContainer.getDefinition(BasicTilesContainer.java:286)
at org.apache.tiles.impl.BasicTilesContainer.isValidDefinition(BasicTilesContainer.java:273)
at org.apache.tiles.renderer.DefinitionRenderer.isRenderable(DefinitionRenderer.java:64)
at org.springframework.web.servlet.view.tiles3.TilesView.checkResource(TilesView.java:116)
at org.springframework.web.servlet.view.UrlBasedViewResolver.loadView(UrlBasedViewResolver.java:483)
at org.springframework.web.servlet.view.AbstractCachingViewResolver.createView(AbstractCachingViewResolver.java:244)
at
I tried a lot of solutions but they dont works.
I use tiles version 3.0.7
Any idea?
I just had the same issue as you while trying to upgrade from tiles 1 to 3.
Anyway my fix was to upgrade the xercesimpl version to 2.11.0
<dependency>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
<version>2.11.0</version>
</dependency>

Wildfly 10 for jms messaging

I tried a simple spring jms example and deployed in tomee worked fine (din't start activemq server). Then I migrated to wildfly 10. But here i need to start activemq server. Is it needed wildfly is already integrated with activemq right? On starting the server (standalone.bat) should start the activemq isn't?
EDIT: Actually some configuration has been changed (I was not aware of the change). I unzipped wildfly 10 again and tried to deploy using "standalone.bat -c standalone-full.xml". Server started successfully but got the below given error.
10:29:26,172 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final) started in 13367ms - Started 401 of 691 services (397 services are lazy, passive or on-demand)
10:29:29,101 INFO [org.springframework.jms.listener.DefaultMessageListenerContainer] (org.springframework.jms.listener.DefaultMessageListenerContainer#0-1) JMS message listener invoker needs to establish shared Connection
10:29:30,111 ERROR [org.springframework.jms.listener.DefaultMessageListenerContainer] (org.springframework.jms.listener.DefaultMessageListenerContainer#0-1) Could not refresh JMS Connection for destination 'myMessageQueue' - retrying in 5000 ms. Cause: Could not connect to broker URL: tcp://localhost:61616. Reason: java.net.ConnectException: Connection refused: connect
I managed to fix this problem by adding an embedded broker to my springcontext.xml
<amq:broker id="broker" useJmx="false" persistent="false">
<amq:transportConnectors>
<amq:transportConnector uri="tcp://localhost:61617" />
</amq:transportConnectors>
</amq:broker>
Refered : http://activemq.apache.org/how-do-i-embed-a-broker-inside-a-connection.html

Spring-Camel (camel logs by default goes console appender)

I am facing one strange problem , I am working on one batch application using below tech STACK
Spring (IOC container) , spring batch , Hibernate , camel and Log4J for logging
I have configured log4J for file appender only and my all application logs goes to my log file , but strange thing is that all Camel logs goes to console appender (I have no console apender configured on my log4J properties file)
Spring – Camel Integration is XMl element :
<camelContext xmlns="http://camel.apache.org/schema/spring">
<routeBuilder ref="smtBatchRouter" />
</camelContext>
My Log4J configuration:
log4j.rootLogger=TRACE, file
log4j.logger.org.apache=TRACE
log4j.logger.org.directwebremoting=OFF
log4j.logger.org.hibernate=OFF
log4j.logger.org.springframework=WARN
log4j.appender.file=org.apache.log4j.DailyRollingFileAppender
log4j.appender.file.file=myapp.log
log4j.appender.file.ImmediateFlush=true
log4j.appender.file.bufferedIO=false
log4j.appender.file.DatePattern='.' dd-MM-yyyy
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d [%-15.15t] %-5p %-30.30c{1} - %m%n
log4j.appender.file.threshold=TRACE
Sample Camel Log that I am getting in console :
[main] INFO org.apache.camel.spring.SpringCamelContext - Apache Camel 2.11.0 (CamelContext: camel-1) started in 4.009 seconds
[Camel (camel-1) thread #0 - sftp://xyz.com/smtDataFolder] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connecting to localhost port 22
[Camel (camel-1) thread #0 - sftp://xyz.com/smtDataFolder] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH -> Connection established
[Camel (camel-1) thread #0 - sftp://xyz.com/smtDataFolder] INFO org.apache.camel.component.file.remote.SftpOperations - JSCH -> Remote version string: SSH-1.99-OpenSSH_4.6
I had the same issue and solved it.
Run your application with the flag:
-Dlog4j.debug
It will add diagnostic information to your console. In my case it was
SLF4J: Class path contains multiple SLF4J bindings.
So I just deleted redundant slf4j-jdk14-1.7.9.jar and left only slf4j-log4j12-1.7.19.jar.

Can not access admin console of jboss eap 6 at standalone mode

I've installed Jboss eap 6.1 in a micro instance of amazon ec2 server. I've run the standalone.sh and that seems to be running fine:
[ec2-user#ip-******** bin]$ ./standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/ec2-user/jboss-eap-6.1
JAVA: /usr/lib/jvm/java/bin/java
JAVA_OPTS: -server -XX:+UseCompressedOops -Xms64m -Xmx86m -XX:MaxPermSize=64m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
20:58:47,062 INFO [org.jboss.modules] (main) JBoss Modules version 1.2.0.Final-redhat-1
20:58:47,506 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
20:58:47,745 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8) starting
20:58:50,396 INFO [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.7.GA-redhat-1
20:58:50,426 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
.......
20:58:52,215 INFO [org.jboss.ws.common.management] (MSC service thread 1-2) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.1.3.Final-redhat-3
20:58:53,245 INFO [org.apache.coyote.http11] (MSC service thread 1-1) JBWEB003001: Coyote HTTP/1.1 initializing on : 127.0.0.1:8080
20:58:53,272 INFO [org.apache.coyote.http11] (MSC service thread 1-1) JBWEB003000: Coyote HTTP/1.1 starting on: 127.0.0.1:8080
20:58:54,125 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:9999
20:58:54,174 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) JBAS015012: Started FileSystemDeploymentService for directory /home/ec2-user/jboss-eap-6.1/standalone/deployments
20:58:54,174 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
20:58:54,180 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 127.0.0.1:4447
20:58:54,510 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on 127.0.0.1:9990/management
20:58:54,512 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on 127.0.0.1:9990
20:58:54,512 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8) started in 8410ms - Started 123 of 177 services (53 services are passive or on-demand)
However, when I tried to access the admin console at: myhostname:8080 it gives a "could not connect" error.
I am sure the port 8080 and 9990 are both open as I've installed jboss-as 7.1 and was able to access the admin console of that through myhostname:8080... Then I stop the service of jboss-as 7.1 and started jboss-eap-6.1 and tried to access it...
Any help will be greatly appreciated!
It looks like the management console is only listening on 127.0.0.1.
20:58:54,512 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on 127.0.0.1:9990
You can change it by editing the standalone.xml or using the -bmanagement 0.0.0.0 parameter. You can replace 0.0.0.0 with the public IP.
Just thought I'd mention that a far safer way to connect is via an SSH Tunnel.
linux/mac:
1) ssh -N i [PEM FILE PATH] -L 9992:127.0.0.1:9990 [EC2 username]#[EC2address]
2) then connect via browser to http://localhost:9992/console/
Windows (Putty):
Follow the steps in the link below (exactly as you did to setup SSH to your EC2 which you should already have). But this time, you need to add the tunnel as per these instructions:
Connection -> SSH -> Tunnels - Enter:
Source port: 9992
Destination: localhost:9990
Then conncect via the SSH connection
then connect via browser to http://localhost:9992/console/
Here are further details on setting up a standard SSH connection to EC2
Connect via SSH to EC2 using Linux/MAC guide here:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html
Connect via SSH to EC2 using Windows (Putty) guide here:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

Resources