Could anybody clear the confusion here.
If we are using slf4j and printing a log then do we need to use log4j.
or in which situation we have to use slf4j and log4j.
Slf4j is an API Log4j is an implementation. Slf4j is an abstraction layer for logging purposes which helps in preventing projects being dependent on specific implementation. If you write in slf4j you can migrate to any other implementation easily (e.g java logging API). But there is always a need for implementation which means slf4j does not stand alone, rather it cooperates with log4j.
Related
I have implemented log4j in my project for logging but as we all know it is slower than slf4j. Thats why I want to upgrade to slf4j. How I can replace log4j with slf4j.
I have created my own framework where I implemented log4j in my whole project. But I want to replace that with slf4j but not able to find a proper method.
This answer is bit longer to post it as a comment, so posting it as an
answer.
Extending #sazzad answer, SLF4j is logging facade and it requires an underlying logging api such as log4j,log4j2, logback, commons-logging etc.
So which logging api you are planning to use?
If you are planning to use log4j itself as an underlying logging api, then you need to use slf4j-log4j12 jar in your application. (Make sure not to use both slf4j-log4j12 and log4j-over-slf4j at the same time as it causes an infinite loop) and that's it.
If you are planning to use other logging api such as logback, then you need to use log4j-over-slf4j jar and respective logging api bridge jar. See Slf4j Bridging legacy APIs
I am writing some codes which are supposed to run (as jar) on both flink and spark platforms. However, these two platforms use different log APIs. (flink uses log4j as logging framework, but slf4j as API) In this case, what is the best practice to log in the common codes ?
I tried with Log4j2 API in these common codes, but it cannot log anything in flink.
My idea now would be trying to get the logging context with log4j API from the slf4j context (which is already launched by flink), is that correct?
Thanks
Definitely a safe way to go would be to use SLF4J from a shared common library.
Since SLF4J is a logging facade, you don't have to force your users to use the same logging framework you're using in your library. See the user manual to this point:
Authors of widely-distributed components and libraries may code
against the SLF4J interface in order to avoid imposing an logging
framework on their end-user. Thus, the end-user may choose the desired
logging framework at deployment time by inserting the corresponding
slf4j binding on the classpath, which may be changed later by
replacing an existing binding with another on the class path and
restarting the application. This approach has proven to be simple and
very robust.
Hy,
I have read that commons-logging and slf4j are "interfaces or specifications" for logging and you have to plugin an implementation. But I have read that you can use log4j for example with commons-logging and with slf4j too, so: log4j "implements" the specifications of commons-logging and slf4j at the same time? I dont understand it
Thanks
SLF4j is a logging facade and can be introduced into both Log4j and commons-logging projects. So you use SLF4j classes to perform the logging it just acts like a facade. Underneath, you can have either Log4j or any other logging system that is supported by SLF4j. The advantage by doing so is that SLF4j relives you from getting tied to a specific logging system.
Sl4j and commons-logging are both facades for underlying logging implementations such as log4j or JDK logging. They work by having their own logging interface, whith multiple implementations, each implementation wrapping the logger interface of the concrete logging framework. So, in the log4j example, Slf4j's org.slf4j.Logger interface has an implementation which wraps a Log4j org.apache.log4j.Logger, not the other way around. The same mechanism applies with commons-logging. This enables using Log4j standalone, with Slf4j or with commons-logging, as you wish.
What are good framework choices for web security in a Scala web application. We would like to try out Scala web development, but couldn't yet find good Scala web app security frameworks.
From the Java side I know at least Spring Security and Apache Shiro.
Do you have experience with Scala web app security frameworks or with Spring Security / Apache Shiro in a Scala context?
Lift has security baked in as described here by David Pollak, the author of Lift.
I used Spring Security in small Scala web application. I created it as I started to learn Scala and I tried to use complete Java stack: Spring MVC + Spring + Spring Security + Hibernate + BlazeDS (I also used Flex in this project for the frontend). Now I can tell that it was really nice and positive experience. Generally the question is how good scala integrates with Spring and Hibernate. I had to use #BeanProperty or #BeanInfo and java collections in entities.
But I have not faced any real issues from the spring security side. It was working as expected. I can remember only one minor issue with Spring AOP: service classes were publishing their methods through BlazeDS to the flex application. I also secured them with Spring Security's object ACLs (with <security:intercept-methods /> and <security:protect />). All this stuff, of course, is possible because of AOP magic. So I noticed this wired Spring AOP's behavior - if your class implements some interfaces, then it will use JDK's proxies to implement them and delegate all calls to target, but if class does not implementing any interfaces, then it will use cglib to extend your class and delegate each method call. The problem is that my public service classes does not implement any interfaces, but AOP was not working properly. The reason is ScalaObject interface that is implemented by all scala classes. So I created new traits for all public services in order to solve this problem (I have not found any way to configure Spring AOP - seems that this behavior is hardcoded).
So as you can see it's not a problem to use Spring Security with Scala. I believe that it should be even easier to use Apache Shiro because it claims to be completely container or environment independent (I heard that it's possible to use Spring Security outside Spring, but I also heard that it's pretty painful). Generally in Scala you can archive everything you can in Java. The question is how pretty/idiomatic/pure/side-effect-free resulting code would be.
By the way, there is a new project that integrates Lift with Apache Shiro: lift-shiro. Here you can also find small blog post about it.
Hope this helps.
I'm looking for more current recommendations on the JCL. I need to choose between using the JCL or just using straight Log4j. I can see the benefits of JCL, but articles such as http://www.qos.ch/logging/thinkAgain.jsp leave me a little unsettled. However, these articles are a bit old and a search of JCL bug fixes seems to indicate some of these issues may have been resolved. I am hoping for a more recent take on the issue. Any thoughts?
Well, this is not a direct answer to you, but I strongly recommend using Simple Logging Facade for Java (SLF4J) with Logback implementation. Logback project is meant to be a successor of Log4j project, and is built by the founder of Log4j and the author of the mentioned article.
SLF4j provides a clean interface to the various logging tools, with adaptors for legacy logging tools. This helpful when you rely on packages that rely on log4j and/or JDK logger.
A previous question discussed some of the reasons to use SLF4J project.
Check out Simple Logging Facade for Java (SLF4J). The article you referenced talks about the "classloader problem" and SLF4J is supposed to answer that.
Unless you need to support something older than java 1.4, consider just using java.util.logging. Standard is better than better, and this way you won't have any classloader problems at all.