Log4j documentation says that it supports internationalization, but no where it provides any details of how to achieve that. Has anyone work on this or can suggest something regarding this please?
I never used it but the feature seems to be provided by the Category.l7dlog methods (added in Release 0.8.4 - 2000-05-01).
As I never used it you have to search for more information on your own or switch to an up to date logging framework like e.g. slf4j with better documentation.
Are you familiar with SLF4J? It can work in conjunction with log4j. SLF4J supports localisation built on top the cal10n project.
Related
If log4j doesn't support this then is there some drop-in replacement for log4j that does? I've gone through the docs and lots of google searches, unfortunately all search results come up with "exploit" or "vulnerability" articles.
Splunk provides a splunk-library-javalogging that has appenders for both Log4j2 Core (the reference Log4j2 API implementation) and Logback (the reference SLF4J API implementation).
The appenders use OkHttp 3.x under the hood, so they will behave as all OkHttp-based components. Since splunk-library-javalogging does not set either a proxy nor a proxySelector explicitly (cf. source code), OkHttp falls back to the system wide ProxySelector.
Without any code modification on your part you can use the JVM-wide proxy settings as in this question.
Remark: if by log4j you are referring to Log4j 1.x, you need to replace the log4j:log4j artifact with either log4j-over-slf4j (which forwards to the SLF4J API) or log4j-1.2-api (which forwards to the Log4j2 API).
I've been struggling for weeks to upgrade Log4j from 1.x to 2.x. By far the biggest difficulty is converting the configuration, which the Log4j authors changed completely between versions without fully documenting how to migrate.
For example, my application currently uses Log4j 1.x with a log4j.properties file that starts with the following line:
log4j.rootCategory=WARN, CONSOLE
In order to convert this to Log4j 2.x configuration syntax, I have to first understand its meaning within the context of Log4j 1.x configuration syntax. This does not appear to be possible.
The Log4j 2.x Configuration Guide does not contain a reference to log4j.rootCategory or any other information that helps me understand its meaning.
The Log4j Migration Guide from 1.x to 2.x does not contain a reference to log4j.rootCategory or any other information that helps me understand its meaning.
I've searched for Log4j 1.x configuration documentation for two days now, and I've found nothing useful. I performed web searches for "log4j convert syntax", "log4j 1.x config documentation", "log4j.rootCategory documentation", "log4j rootCategory configuration" and more. None of these returned anything other than the above links or other pages that do not contain a reference to log4j.rootCategory or any other information that helps me understand its meaning.
This Stack Overflow question question states that "The actual Documentation for the LOG4J version 1.x is offline." This appears to be largely true, although #Tobias Otto provides a link to the Log4j 1.x manual at logging.apache.org/log4j/1.2/manual.html. This page does have a perfunctory "Configuration" section, but it does not contain a reference to log4j.rootCategory or any other information that helps me understand its meaning.
I'm out of ideas. What does setting log4j.rootCategory accomplish in the context of Log4j 1.x configuration syntax? How is this goal accomplished in the context of Log4j 2.x configuration syntax? Is there any meaningful documenation available for Log4j 1.x configuration directives?
How do I attach logback to smartfox server?
smartfox uses log4j by default. How can I shift logging of my extensions/all of smartfox to logback?
I've tried this but this is failing with this error cause it has already boud to log4j I guess.
SmartFoxServer 2x uses Simple Logging Facade for Java (SLF4J) for logging. The very purpose of SLF4J is to provide a facade over the logging framework so the user can replace one logging framework with another. In your case log4J with Logback. I'll first explain how SLF4J works and how you can change one logging framework with another and briefly discuss some caveats. Then I'll cover some SmartFoxServer specifics.
Simple Logging Facade for Java Architecture
SLF4J provides API which serves as facade (abstraction layer) over the actual logging framework. This allows the user to easily switch between frameworks on deployment time without the need to change the code. But it also means that SLF4J on its own is not enough - the default implementation is no-op. In order to actually log anything you need actual logging framework (such as log4j or logback) and so called "binder" which servers as a bridge or adapter between SLF4J and the logging framework.
Swapping Logging Frameworks
The SLF4J User Manual provides detailed explanation on how you can swap one framework with another during deployment time. In short you just need to delete the old binder and logging framework and add the new binder and the new logging framework. To swap log4 with logback you need to delete slf4j-log4j12 and log4j jars and add logback-classic and logback-core.
Caveats
You should make sure that there is only one binder implementation in the classpath. Having more than one causes waring, not error. SLF4J would just pick one of the implementations. But I would not rule out the possibility for this to cause issues with more complex application (such as SmartFoxServer) that uses multiple class loaders. But more importantly you should make sure the SLF4J API, the binder and the logging framework versions are compatible. For example if you use old version of SLF4J with newer version of logback that may cause ClassNotFoundException. I suspect that this could be reason why you get the error you see.
Swapping lof4j with Logback as logging framework for SmartFoxServer 2x
SmartFoxServer 2x version 2.17.3 uses SLF4J API version 1.7.5. To swap log4j you need to first delete lib/slf4j-log4j12-1.7.5.jar and then add compatible version of logback-classic and logback-core jars. For example logback-classic 1.1.0 and logback-core 1.1.0.
You can delete lib/log4j-1.2.15.jar but I would rather keep it. The binder(lib/slf4j-log4j12-1.7.5.jar) is not meant to be used directly so it should be safe to be deleted. On other hand there are libraries that use log4j directly. I don't know if SmartFoxServer 2x uses any such library but it is safer to keep it just in case. Swapping the binder is enough for SLF4J to use Logback and ignore log4j.
Logger Output
SmartFoxServer 2x parses the logger output to provide some functionality such as the Admin Log Viewer. If you change the log output this may cause this functionality to stop working and maybe even cause other issues (on theory it should not, but you never know). There is configuration file (config/logParser.properties) that would allow you to configure the log parser, but I didn't found any documentation about it. You may try to ask on the SmartFoxServer forum. The developers are actually pretty active there so they may help.
Swapping loggers only for your extension
The instruction I gave swaps the logger for all extensions and SmartFoxServer. If you want you may try to swap them only for your extensions. But I'm not quite sure if and how that would work. Each class extension uses its own class loader but this provides isolation between extensions and SmartFoxServer and extensions, but not between extension and SmartFoxServer. What does this mean is that if you add lib.jar to Extension A classpath it would not be visible to Extension B or to SmartFoxServer code. But if you add lib.jar to the SmartFoxServer classpath it would be visible to both Extension A and Extension B. As SmartFoxServer already contains SLF4J API on its classpath you should not add it to your extension classpath. You can try to add logback-classic and logback-core to you extension classpath. But in this case you'll have two binder implementations in you extension classpath (logback and log4j from the SmartFoxServer classpath). As already discussed, I'm not quite sure how and if this would work.
Conclusion
SLF4J provides an easy way to swap logging frameworks, but there some caveats. And SmartFoxServer adds some caveats on its own. Unless SmartFoxServer team supports swapping of the underlaying logging framework (which judging by some anwers in their forum, they don't), I would be quite careful and do such swap only if there are some benefits and it is not just a matter of personal preference.
I am looking for the utility to convert log4j.xml to log4j2.xml syntax is there any utility available
At first I was going to respond that this cannot be done but it might be somewhat possible.
Log4j 2.13.0 added experimental support for using Log4j 1.x configuration files. If your configuration is compatible, in theory you could start up an application using a Log4j 1.x configuration and then call getRootNode() on the AbstractConfiguration. The root node is very similar to a DOM tree so walking it and converting it to XML wouldn't be too hard. However, Log4j doesn't have a tool provided to do this. Contributions are welcome!
Has anybody seen a framework which is either written to work with Guice or a library that integrates an existing security system (ie: Acegi) with Guice?
I have found the following thus far...
http://code.google.com/p/warp-security/ (I think this abandonware)
http://code.google.com/p/warp-security/ (no documentation)
Apache Shiro 1.2 and later has native support for Guice applications:
http://shiro.apache.org/guice.html
HTH!
For whatever it's worth (being quite a late answer), I've had success integrating Apache Shiro with Guice. Last time I checked, Acegi was too deeply dependent on Spring to be usable in a pure Guice solution. Shiro's documentation is a little lacking, but the API is pretty straight-forward and easy to use, if don't mind a little digging.
In case it's of any interest, I've posted a Gist of the simplest example I could find. Two caveats:
It's written against a pre-release version of Shiro 1.0
The Active Directory realm we're using is a somewhat modified version from the main Shiro source, using some ideas from the Active Directory plugin for Jenkins (then Hudson).
Hopefully, it's enough to get you started...