I'm using Eclipse 3.5, with my Tomcat runtime set as Tomcat 6.0.26. My Java VM is JDK 1.6.17 (Mac OS X).
When I try to run a web application from an Eclipse Java EE perspective I keep seeing this error in the console:
Caused by: java.lang.ClassCircularityError: java/util/logging/LogRecord
at com.adsafe.util.SimpleFormatter.format(SimpleFormatter.java:11)
at java.util.logging.StreamHandler.publish(StreamHandler.java:179)
at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
at java.util.logging.Logger.log(Logger.java:458)
at java.util.logging.Logger.doLog(Logger.java:480)
at java.util.logging.Logger.logp(Logger.java:596)
at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:165)
at org.apache.juli.logging.DirectJDKLog.info(DirectJDKLog.java:115)
at org.apache.catalina.core.ApplicationContext.log(ApplicationContext.java:644)
at org.apache.catalina.core.ApplicationContextFacade.log(ApplicationContextFacade.java:251)
at org.apache.catalina.core.StandardWrapper.unavailable(StandardWrapper.java:1327)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1130)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:519)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:581)
... 6 more
java/util/logging/LogRecord implements Serializable, so I am not sure where the circular reference could have creeped in.
Has anyone seen this before and know how to fix this?
I was able to circumvent this problem by moving the <contextListener ...> to the very end of the configuration file (previously, I had it at the beginning of the file). The error remains really weird, though.
The problem is solved if you insert this snippet into your logback configuration:
<!-- LEVEL CAN NOT BE DEBUG -->
<logger name="org.apache" level="INFO"></logger>
I'm not sure why this resolved the problem, but setting the default level to INFO made this go away for me
.level = INFO
In had the same error when using Logback.
In my case, the problem was I used JUL LevelChangePropagator in my Logback configuration file.
So I just had to remove the following listener
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<resetJUL>true</resetJUL>
</contextListener>
First of all, a bit of context: I personally see this message when adding a listener in my web.xml to install the SLF4JBridgeHandler to bridge java.util.logging (JUL) calls to SLF4J. I started to see this as soon as I increased the JUL root logger level from the default (INFO) to FINE, in order to forward all (well, almost all) messages to SLF4J.
user2543253 comment above was indeed useful, it's a problem that happens at classloading time. I personally solved it by adding a fake direct JUL log call (using a LogRecord) before installing the SLF4JBridgeHandler, in order to trigger classloading of JUL classes early. So my listener now does:
java.util.logging.Logger rootLogger = LogManager.getLogManager().getLogger("");
rootLogger.log(new LogRecord(Level.ALL, "bridging of java.uil.logging to SLF4J requested"));
SLF4JBridgeHandler.removeHandlersForRootLogger();
rootLogger.setLevel(Level.FINE);
SLF4JBridgeHandler.install();
By the way: it's not strictly a Logback problem, I experience this while not using Logback at all (I'm using the Log4j 1.2 binding).
Related
I understand that the question can sound a little funny, but how do I disable logging in neo4j-ogm? I have added an logback.xml file to my conf directory which is in my classpath. The logback.xml looks as follows:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!--
~ Set the required log level for the OGM components here.
~ To just see Cypher statements set the level to "info"
~ For finer-grained diagnostics, set the level to "debug".
-->
<logger name="org.neo4j.ogm" level="OFF" />
<root level="off">
<appender-ref ref="console" />
</root>
</configuration>
which is taken from here . The loglevel=off is taken from here
I want to deploy my program for production and I need logs from console. But with neo4j logging the logfile increases 1GB per day with the following type logs:
14:20:13.281 [Thread-14] DEBUG o.n.o.d.http.request.HttpRequest - Response is OK
14:20:13.289 [Thread-14] DEBUG org.neo4j.ogm.MetaData - looking for concrete class to resolve label: Leaf
14:20:13.289 [Thread-14] DEBUG org.neo4j.ogm.MetaData - concrete class found: com.mycompany.Leaf. comparing with what's already been found previously...
14:20:13.289 [Thread-14] DEBUG org.neo4j.ogm.MetaData - Page resolving class: com.mycompany.Leaf
14:20:13.290 [Thread-14] DEBUG org.neo4j.ogm.MetaData - looking for concrete class to resolve label: Root
etc...
Details:
The program is a jsvc daemon which logs console to log/log.txt.
neo4j-version: 2.0.0 - M01
java -version : oracle java 7
The question was raised years ago, but for all using Stack Overflow as knowledge database, I want to record an additional solution for current environments. Most of the Neo4j log entries concern query statements and the already mentioned "unwind" messages. So, you are using a Spring Boot environment (2.0.3.RELEASE) in conjunction with the spring-boot-starter-data-neo4j artifact? Just add the following line to your /src/main/resources/application.properties file to disable the messages:
Using the Bold driver
logging.level.org.neo4j.ogm.drivers.bolt.request.BoltRequest = WARN
Using the embedded driver
logging.level.org.neo4j.ogm.drivers.embedded.request.EmbeddedRequest = WARN
I don't know if this would help your case but I had exploding "UNWIND" logs issue and found this hacky way to fix it. It just disables an internal logger I found in the source code. You could do something similar if your found the logger class in source code:
java.util.logging.Logger.getLogger("org.neo4j.ogm.drivers.bolt.request.BoltRequest").setLevel(Level.WARNING);
After hours working on it, I finally find the problem!
I was using the wrong dependencies of "slf4j".
Wrong dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.6.4</version>
</dependency>
Correct dependency:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.25</version>
</dependency>
And I just use the file "log4j2.xml" to make the correct level of logs.
I hope this can help anyone!
Has anybody sometime tried to use JRebel with Mule instead of a typical application server? If so, could you describe your experience?
As far as I know, currently, Mule is not officially supported by the JRebel team. However, I was wondering if there might be some workaround to this limitation.
Although Mule ESB is not officially supported by JRebel, we have found a workaround. First of all, let me start by stating that:
As of today, it is not possible to hot-deploy Mule XML flows by using JRebel. Mule, however, offers its own mechanisms for achieving this same thing. As such, the lack of JRebel support for this is no deal breaker.
So, the only thing we can hot-deploy are the Java classes, which is still very welcome. How do we do that?
Start by configuring the JRebel agent in $MULE_HOME/conf/wrapper.conf. The required lines, in our case, were:
wrapper.java.additional.13=-javaagent:{path to jrebel.jar}
wrapper.java.additional.14=-Xbootclasspath:{path to rebelboot.jar}
wrapper.java.additional.16=-Drebel.remoting_plugin=true
wrapper.java.additional.19=-Drebel.remoting_port={whatever}
These are the JVM paremeters required to launch JRebel along with Mule. The numbering of the parameters is arbitrary.
We want to use JRebel in remote mode. You can read about this mode in the docs. That's the reason for the wrapper.java.additional.16=-Drebel.remoting_plugin=true and wrapper.java.additional.19=-Drebel.remoting_port={whatever} paremeters.
Now go ahead and launch Mule by either executing mule.bat or mule.sh, depending on your environment (Windows or *nix). JRebel should start along with it.
Place your Mule applications inside $MULE_HOME/apps. They will be automatically deployed and, from now on, their .class files will be monitored by JRebel.
Inside your IDE, install the JRebel plugin and apply your license. Afterwards, add the JRebel nature to your project and configure its remote server URL using the port we previously defined inside wrapper.conf.
Do whatever changes you need to do to your code and sync. They should be successfully hot-deployed into the running Mule instance.
when I was testing, I noticed that you need to add in the file wrapper.conf the next attributes:
wrapper.java.additional.18=-Drebel.log=true
wrapper.java.additional.19=-Drebel.log.file=/MyPath/LogName.log
With these the JRebel runs correctly. In conclusion, when we´re using a specific port, is necessary to enable JRebel’s logging.
More information, check in Step 6:
https://zeroturnaround.com/software/jrebel/learn/remoting/setting-up-jrebel-remoting-with-intellij-idea-and-tomcat/
When I configured with the points indicated, I have the next exception in Mule´s console:
Launching a JVM...
2015-10-27 11:00:27 JRebel: WARN You are running JRebel using the -javaagent option on a system where -agentpath is supported.<br/>
2015-10-27 11:00:29 JRebel: Monitoring Log4j configuration in 'file:/C:/Dev/Mule%20-%2002-esb-mule-ee%20-%203.4/conf/log4j.properties'.<br/>
Exception in thread "main" java.lang.NoSuchMethodError: javax.xml.parsers.SecuritySupport$1: method <init>()V not found<br/>
at javax.xml.parsers.SecuritySupport.getContextClassLoader(Unknown Source)<br/>
at javax.xml.parsers.FactoryFinder.find(Unknown Source)<br/>
at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source)<br/>
at com.opensymphony.module.propertyset.config.PropertySetConfig.<init>(PropertySetConfig.java:53)<br/>
at com.opensymphony.module.propertyset.config.PropertySetConfig.getConfig(PropertySetConfig.java:113)<br/>
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:32)<br/>
at com.opensymphony.module.propertyset.PropertySetManager.getInstance(PropertySetManager.java:22)<br/>
at com.mulesource.licm.pref.MulePropertySetPreferences.loadPropertySet(MulePropertySetPreferences.java:208)<br/>
at com.mulesource.licm.pref.MulePropertySetPreferences.<clinit>(MulePropertySetPreferences.java:50)<br/>
at com.mulesource.licm.pref.MulePreferencesFactory.<clinit>(MulePreferencesFactory.java:19)<br/>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)<br/>
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)<br/>
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)<br/>
at java.lang.reflect.Constructor.newInstance(Unknown Source)<br/>
at java.lang.Class.newInstance(Unknown Source)<br/>
at java.util.prefs.Preferences.factoryOrig(Unknown Source)<br/>
at java.util.prefs.Preferences.userRoot(Unknown Source)<br/>
at com.mulesource.licm.impl.TrueLicenseHelper.createLicenseManagerParameters (TrueLicenseHelper.java:338)<br/>
at com.mulesource.licm.impl.TrueLicenseHelper.createLicenseManagerParameters(TrueLicenseHelper.java:330)<br/>
at com.mulesource.licm.impl.TrueLicenseHelper.<init>(TrueLicenseHelper.java:120)<br/>
at com.mulesource.licm.impl.MuleLicenseManager.<init>(MuleLicenseManager.java:25)<br/>
at com.mulesource.licm.LicenseManagementFactory.createLicenseManager(LicenseManagementFactory.java:48)<br/>
at org.mule.module.boot.LicenseKeyHandler.<init>(LicenseKeyHandler.java:43)<br/>
at org.mule.module.reboot.MuleContainerBootstrap.handleLicenseKey(MuleContainerBootstrap.java:192)<br/>
at org.mule.module.reboot.MuleContainerBootstrap.main(MuleContainerBootstrap.java:62)<br/>
Configuration JRebel in Mule is very similar to configuration in tc Server.
You need to add JRebel Agent as a wrapper.java.additional.* property in $MULE_HOME/conf/wrapper.conf:
wrapper.java.additional.10=-agentpath:[c:\path\to]lib\jrebel64.dll
If you use Java version 7 and newer you use agent:
Windows 64-bit JDK jrebel64.dll
Windows 32-bit JDK jrebel32.dll
Mac OS X 64-bit JDK libjrebel64.dylib
Mac OS X 32-bit JDK libjrebel32.dylib
Linux 64-bit JDK libjrebel64.so
Linux 32-bit JDK libjrebel32.so
If you use Java version 6 and below, you need to use legacy agent jrebel.jar file.
We've installed the NewRelic java agent on our WebSphere Application / WebSphere Commerce system and in the NewRelic logs we are seeing this:
Sep 3, 2013 22:47:53 -0400 NewRelic 14 INFO: The data collector is temporarily unavailable. This can happen periodically. In the event that availability of our servers is not restored after a period of time, then please report this to New Relic. java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.DefaultSSLSocketFactory.a(SSLSocketFactory.java:11)
at javax.net.ssl.DefaultSSLSocketFactory.createSocket(SSLSocketFactory.java:6)
at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.java:161)
at com.ibm.net.ssl.www2.protocol.https.d.connect(d.java:36)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1184)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:390)
at com.ibm.net.ssl.www2.protocol.https.b.getResponseCode(b.java:75)
at com.newrelic.agent.transport.DataSenderImpl.connectAndSend(DataSenderImpl.java:550)
at com.newrelic.agent.transport.DataSenderImpl.send(DataSenderImpl.java:600)
at com.newrelic.agent.transport.DataSenderImpl.invoke(DataSenderImpl.java:480)
at com.newrelic.agent.transport.DataSenderImpl.invokeNoRunId(DataSenderImpl.java:475)
at com.newrelic.agent.transport.DataSenderImpl.getRedirectHost(DataSenderImpl.java:203)
at com.newrelic.agent.transport.DataSenderImpl.connect(DataSenderImpl.java:193)
at com.newrelic.agent.RPMService.launch(RPMService.java:194)
at com.newrelic.agent.rpm.RPMConnectionServiceImpl$RPMConnectionTask.attemptConnection(RPMConnectionServiceImpl.java:301)
at com.newrelic.agent.rpm.RPMConnectionServiceImpl$RPMConnectionTask.access$1100(RPMConnectionServiceImpl.java:101)
at com.newrelic.agent.rpm.RPMConnectionServiceImpl$RPMConnectionTask$3.run(RPMConnectionServiceImpl.java:235)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:452)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:328)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:161)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:109)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:191)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:215)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
at java.lang.Thread.run(Thread.java:738)
Caused by: java.lang.ClassNotFoundException: Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
at javax.net.ssl.SSLJsseUtil.b(SSLJsseUtil.java:125)
at javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:3)
at javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:41)
at javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:46)
at com.ibm.net.ssl.www2.protocol.https.b.<init>(b.java:26)
at com.ibm.net.ssl.www2.protocol.https.Handler.openConnection(Handler.java:1)
at com.ibm.net.ssl.www2.protocol.https.Handler.openConnection(Handler.java:5)
at java.net.URL.openConnection(URL.java:957)
at com.newrelic.agent.transport.DataSenderImpl.createConnection(DataSenderImpl.java:676)
at com.newrelic.agent.transport.DataSenderImpl.connectAndSend(DataSenderImpl.java:540)
... 18 more
There seems to be some documentation about how to update an Eclipse based IDE environment to overcome this error in other situations, but nothing specific to NewRelic. Has anyone seen this before that can offer suggestions on how to fix the issue?
The next release of New Relics Java agent should make it possible to run without any configuration changes. With version 2.21.X and earlier please submit a request for support at support.newrelic.com
Read and see if this publication gives you a hint:
http://www-01.ibm.com/support/docview.wss?uid=swg21584437
I went through the same thing. As you might have gathered from the article liked by Robban WebSphere has some restriction in the SSLConnectionFactory, so a quit fix would be to just edit the newrelic.yml and configure:
# The agent communicates with New Relic via https by
# default. If you want to communicate with newrelic via http,
# then turn off SSL by setting this value to false.
# This work is done asynchronously to the threads that process your
# application code, so response times will not be directly affected
# by this change.
# Default is true.
ssl: false
Good luck.
Version 3.0.0 or later of New Relic's Java Agent should completely resolve this issue without any custom configuration, certainly without turning off SSL! Release notes.
I've found a similar issue described in detail in the scala mailing list (also here). It seems to be related to this change in classpath management when creating scala interpretation environments.
In my case both scala-library and scala-compiler are included in the war being deployed to WebLogic 10.3 (camel version: 2.8.0, jvm: oracle 1.6).
The exception is shown below:
com.sun.jersey.api.container.ContainerException: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeToUsingServletTemplateEngine(ScalateTemplateProcessor.scala:190)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:136)
at org.fusesource.scalate.jersey.ScalateTemplateProcessor.writeTo(ScalateTemplateProcessor.scala:44)
at com.sun.jersey.spi.template.ResolvedViewable.writeTo(ResolvedViewable.java:103)
at com.sun.jersey.server.impl.template.ViewableMessageBodyWriter.writeTo(ViewableMessageBodyWriter.java:83)
Truncated. see log file for complete stacktrace
Caused By: org.fusesource.scalate.TemplateException: object scala not found.
at org.fusesource.scalate.TemplateEngine.compileAndLoad(TemplateEngine.scala:784)
at org.fusesource.scalate.TemplateEngine.compileAndLoadEntry(TemplateEngine.scala:643)
at org.fusesource.scalate.TemplateEngine.liftedTree1$1(TemplateEngine.scala:374)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:368)
at org.fusesource.scalate.TemplateEngine.load(TemplateEngine.scala:426)
Truncated. see log file for complete stacktrace
Caused By: scala.tools.nsc.MissingRequirementError: object scala not found.
at scala.tools.nsc.symtab.Definitions$definitions$.getModuleOrClass(Definitions.scala:653)
at scala.tools.nsc.symtab.Definitions$definitions$.getModule(Definitions.scala:603)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackage(Definitions.scala:145)
at scala.tools.nsc.symtab.Definitions$definitions$.ScalaPackageClass(Definitions.scala:146)
at scala.tools.nsc.symtab.Definitions$definitions$.AnyClass(Definitions.scala:176)
The question: is it possible to make camel web-console work in this environment?
No its a problem with WebLogic. Scalaete needs to add special support for WebLogic, as WebLogic does classloading a bit differently, than the usual practice.
I try to send logs from a java application with the Logstash tcp socket appender to logstash. The java app. already works with logback 1.1.9 (slf4j) and other appenders.
Now I added the following lines to the logback-test.xml:
<configuration>
<appender name="logstash" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
<destination>[IP]:5010</destination>
<encoder class="net.logstash.logback.encoder.LogstashEncoder">
<fieldNames>
<message>log_msg</message>
</fieldNames>
</encoder>
<keepAliveDuration>5 minutes</keepAliveDuration>
</appender>
<root>
<level value="info"/>
<appender-ref ref="logstash" />
</root>
</configuration>
But when I add the appender and start my java application, I get an error from the JVM Launcher "A Java Exception has occured" and I get the following console text:
Exception in thread "main" java.lang.IllegalAccessError: failed to access class ch.qos.logback.core.status.OnPrintStreamStatusListenerBase from class net.logstash.logback.status.LevelFilteringStatusListener (ch.qos.logback.core.status.OnPrintStreamStatusListenerBase and net.logstash.logback.status.LevelFilteringStatusListener are in unnamed module of loader 'app')
at net.logstash.logback.status.LevelFilteringStatusListener.setDelegate(LevelFilteringStatusListener.java:67)
at net.logstash.logback.appender.AsyncDisruptorAppender.start(AsyncDisruptorAppender.java:370)
at net.logstash.logback.appender.AbstractLogstashTcpSocketAppender.start(AbstractLogstashTcpSocketAppender.java:1009)
at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90)
at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179)
at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:158)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:145)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:103)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53)
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
I included the logstash 6.3 jar-file and because of this error, I also tried it with an older version, 4.9. Does anybody know if that is compatible to logback 1.1.9?
I'm not using Spring-Boot.
---------Edit 17.02.2020-----------
My input of the logstash.conf file (because I don't get any log from my java application):
input {
tcp {
mode => "server"
port => 5010
codec => json
}
}
You can avoid the exception you encountered by applying any of the following solutions:
A) Use logback version >= 1.1.10
OR
B) Add <addDefaultStatusListener>false</addDefaultStatusListener> to your appender definition (see details here)
OR
C) Add a status listener to your logback configuration (which prevents logstash-logback-encoder from adding a default status listener).
The exception occurs because logstash-logback-encoder versions >= 6.0 reference logback's ch.qos.logback.core.status.OnPrintStreamStatusListenerBase class when adding a default status listener. OnPrintStreamStatusListenerBase was made public in logback 1.1.10, and was package-private before then.
Applying any of the above solutions will avoid the exception you encountered. However, keep in mind that logstash-logback-encoder versions >= 4.8 are compiled and tested against logback 1.2.x. Therefore, you might encounter other errors when using logback 1.1.x. The logstash-logback-encoder readme contains the following statement on this topic:
Older versions than the ones specified in the pom file might work, but the versions in the pom file are what testing has been performed against.
Solution:
I updated logback from 1.1.9 to 1.2.3. As I replaced the jar files and addeded them to the class-path, I got over 600 times the following error-message: Logger cannot be resolved to a type. I fixed this by opening the properties in Eclipse from the logback project, going on "Order and Export" and setting a marker in every checkbox --> Apply and close. Now I don't get the IllegalAccessError any more and my java application is running fine. And I also now can see the logs in Logstash and Kibana :)
I downloaded the following files:
jcl-over-slf4j 1.7.25
jul-to-slf4j 1.7.25
log4j-over-slf4j 1.7.25
slf4j-api 1.7.25
logback-classic 1.2.3
logback-core 1.2.3
I downloaded them from here:
https://mvnrepository.com/artifact/ch.qos.logback/logback-classic/1.2.3