I have logging working to Sentry from android just using the EventBuilder from raven-java, but I need to attach extra info which apparently EventBuilder or java.util.logging can't do.
I tried to use log4j but it doesn't pick up log4j.properties, how can I configure it with the Sentry DSN and other information? I have no preference about what logging library to use, so logback or log4j2 will do but they seem to suffer from the same problems.
I tried to configure logging programmatically but can't add the appender SentryAppender.
I also tried using android-logging-log4j library but this has the same problem.
I realize that https://github.com/joshdholtz/Sentry-Android exists which might work but it doesn't do retries in case of network issues which is quite important.
The https://github.com/joshdholtz/Sentry-Android library now supports saving of offline captures and failed captures as of version v1.1.0 - https://github.com/joshdholtz/Sentry-Android/releases/tag/v1.1.0
Related
We understand that Jetty 11 has basically changed logging from version 10 (no internal Jetty classes, moreover Jetty 11 is commited to use SLF4 as a base logging).
The problem
We have a rudimentary knowledge of SLF4J (used it before and we've even read the Jetty 11 SLF4J sources ,too), but currently we don't see any way to "teach" Jetty 11 a new logging (aka there are no "setLogging()" methods in the Jetty 11 source code as there were before).
Global (Jetty) parameters, alas, can't be our solution just yet.
The state (aka our requirements)
We have already solved the "RequestLog" outputs of Jetty, no problems there, we need the "normal" Jetty-log outputs.
We need to control (many) modules/jars etc. via a unified logging.
Our logging is simple but requires that no output happens on the console (stdout / stderr etc). In best case the logging gets an instance of an Exception/Runtime, too.
Therefore, we need to route the Jetty output from the "Jetty server" through our internal logging. Using SLF4? If there is no other way (and we see no other way up to now), gladly.
Switching back to Jetty 10, sadly, is not an option.
Could this be solved in any way we are not aware of (yet)? Any idea would be very appreciated, thank you!
The switch from Jetty logging to Slf4j was actually done in Jetty 10.0.0.
slf4j was designed for unified logging, it can capture into a single logging location implementation all of the logging events generated from libraries that use ...
slf4j API
java.util.logging API
log4j1 API
log4j2 API
commons-logging API
logback API
org.apache.juli.logging API
and if you use slf4j version 2.x series, there's even rudimentary support for capturing java.lang.System.Logger API.
With slf4j, you have 2 categories of jar files to think about.
Bridge API JARs
These are slf4j based JARs that merely capture the above logging events and route them to slf4j. You can choose 0..n of these JARs to use.
There's dozens of options here.
Here's some common ones
jcl-overs-slf4j - captures Jakarta Commons Logging events and sends to slf4j
jul-to-slf4j - captures Java Util Logging events and sends them to slf4j
log4j-over-slf4j - captures Log4j 1.x events and sends them to slf4j
log4j2-overs-slf4j - captures Log4j 2.x events and sends them to slf4j
osgi-over-slf4j - captures osgi logging bundle events and sends them to slf4j
See http://www.slf4j.org/legacy.html
Implementation Binding JAR
These are the implementation of slf4j-api, and is the final binding of all logging events, it is the thing that decides what to do with the logging event (eg: write it to disk, ignore it, send it to a logging database, etc)
You have many choices here as well, here's some common jars to pick from (pick only 1!)
logback-classic - slf4j to Logback (Eclipse Jetty group's favorite logging implementation)
slf4j-jdk14 - slf4j to Java Util Logging
slf4j-log4j12 - slf4j to Log4j 1.2.x
log4j-slf4j-impl - slf4j to Log4j 2.x (see https://logging.apache.org/log4j/2.x/log4j-slf4j-impl/)
slfj-jcl - slf4j to Jakarta Commons Logging
jetty-slf4j-impl - Jetty 10+ implementation of the slf4j api
See: http://www.slf4j.org/manual.html#swapping
Since Jetty 10.0.x, the jetty-slf4j-impl exists, which provides an out of the box implementation that simply writes to System.err (aka STDERR) with some decent logging filtering by level in the usual jetty-logging.properties.
See https://search.maven.org/artifact/org.eclipse.jetty/jetty-slf4j-impl
Important advice
Don't use multiple binding implementations. Narrow it down to 1 binding implementation and purge all other logging implementation jars.
Don't accidentally create a loop with introducing a Bridge API Jar and a Binding Implementation JAR with the same logging technology. (eg: using binding log4j-over-slf4j and slf4j-log4j12 at the same time)
There is no "configuration" to wire up these binding or bridge jars, their mere existence in the classloader is enough to make them work. See the slf4j manual on how that works.
We have already solved the "RequestLog" outputs of Jetty, no problems there, we need the "normal" Jetty-log outputs.
Interesting, this is "solved" by actually using slf4j, as that's the only non-deprecated implementation of RequestLog.Writer in Jetty 10 and Jetty 11.
The way this works, is the Slf4jRequestLogWriter will emit events to a single named logger (the name of which you can configure in Slf4jRequestLogWriter.setLoggerName(String)) using the slf4j-api. Then it reaches the logging implementation and is routed wherever that logging configuration decides based on that logger name (file, with rolling, syslog, sent to a different system for aggregation, logstash, etc)
Did you really implement your own RequestLog.Writer instead of just using your preferred logging logging library? (libraries like logback, log4j2, log4j1, and even java.util.logging can easily create separate log files for RequestLog events).
⚠️ Note: do not use logback-access for RequestLog at this time (It does not fully support jakarta.servlets yet, and has many bugs that result in bad request log data. See open PR at https://github.com/qos-ch/logback/pull/532)
I'm used to using log4j and whenever there were setup/config problems I'd enable "-Dlog4j.debug" and all the config info would be dumped out at startup.
This was very useful on a number of occasions.
Now I'm working on a Spring boot application, which I've found uses:
Commons logging Logger statements in the client code
A bridge jar (jcl-over-slf4j-xxx.jar) which translates the commons logging calls into slf4j more info here
Finally slf4j uses "logback" as the underlying logging framework
I found it rather painful to figure all this out.
Is there an equivalent of -Dlog4j.debug which can show me how this is all hanging together at startup time?
This is the best/only option I've found so far, and it's logback specific.
Use this -D on the command line:
-Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener
Taken from here
This essentially is the logback equivalent of log4j's -Dlog4j.debug.
It dumps the logback startup sequence to the console at startup time, as the logging system is initialised.
This is not a true answer as I'd like some messages to show before this to show why logback is being used, but I haven't found anything like that yet.
Aside: This may also be useful for Spring Boot:
-Ddebug
Taken from here and here
If you are using logback, I assume you are using the logback.xml file? Then if you start that file with <configuration debug="true"> then it should dump the status information. More information in the documentation under status data section.
I wanted to implement logging for my web services.I have been playing around with Log4j. It's a really cool logging framework when it works.But when it doesn't , it's a pain to debug.
My problem is that i am trying to log to the database , but for some reason I don't see anything being logged to the table. I have no clue whats causing this.
In my log4j.xml i have the following line
<log4j:configuration debug="true"
xmlns:log4j='http://jakarta.apache.org/log4j/'>
But when i deploy and run my web service in the debug mode in Eclipse , I don't see logging related debug statements on the console.
I want to be able to see
log4j initializing and configuring the loggers. So if anything is wrong with my xml configuration i would know immediately.
log4j logging to the destination , in this case to the database. If there is a some kind of a sql/database exception I would know.
I am logging at the application level (the application is using its own log4j jar and configuration files as opposed to using the application servers logging mechanism)
My project uses log4j-1.2.17 , Eclipse Luna 4.4.0, JBoss EAP 6.4.0.
Can our log4j experts suggest ways to effectively debug log4j itself. Are there Eclipse plugins that can help alleviate the pain.
Is it possible to transfer the AEM (v5.6) logs to the Log4j server? Or there is some best practice for centralized AEM logging?
I haven't dealt much with AEM. It seems the Apache Sling Logging services configure only the FileAppender.
For CQ5.5 there is no log4j.xml. All the CRX logger needs to
configured using sling config.
We can use Apache Sling Logging Logger
Configuration
(https://docs.adobe.com/docs/en/aem/6-0/deploy/configuring/monitoring-and-maintaining.html#Create%20a%20Custom%20Log%20File)
or LogBack
(http://sling.apache.org/documentation/development/logging.html#logback-integration)
AEM provides the loggers out of the box as you have seen. Typically if you want centrallized log handling I would suggest mounting a super-high-speed shared volume and having all instances log there, just for performance/speed reasons.
You might want to check out this:
http://adobe-consulting-services.github.io/acs-aem-commons/features/syslog-appender.html
It is AEM6 only, but you could look at the code and do it that way.
This uses logback, not log4j, but it should solve your problem.
The other option, really, is to write your own logging service and use that and configure the appender in the code. I do not see the normal XML files anywhere. I'm curious if you come across them.
Let me know if I can help further.
I've a problem with OpenJPA logging and Websphere (8).
For a few days I try to redirect the OpenJPA logging information into a separate file (instead of the SystemOut log file). This is what I tried:
Changing the persistence.xml with logging information (e.g. ). Though I learned that websphere is ignoring this entry. Can I assume that this is correct?
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.express.doc/info/exp/ae/tejb_loggingwjpa.html tells me the same
Also the wsjpa.log property did not help.
Specifying a handler for openjpa (or openjpa.Runtime, ...) in JSR-47 configuration file does not work either (other configurations worked). What I realized here is that there is actually no openjpa logger in the java logging (java.util.logging.LogManager.getLogManager().getLoggerNames()). Does that mean that OpenJPA is not logging to a dedicated logger but just writes to SystemOut which is then processed by websphere?
I searched through all the different loggers and traces in the websphere console and tried a few, but none of them contained any openjpa logs. Can I assume that there is no other location where openjpa logs to in websphere?
To conclude: It's not working and I cannot use a handler for the openjpa logs because there are no logs generated. OpenJPA in websphere is just printing to the SystemOut which is internally used for the tracing. Does anyone have an idea what to do?
Alternatives would be:
- Use HPEL
- Script to filter the trace.log
But actually I would rather have a file handler for OpenJPA in Websphere.
Thanks for your help and I can supply you with some more information if you need that.
You can use application logging system for this purpose based on 3d party logging library for example logback.
logback is very powerful library.