I have the following setup
Version: Openfire 4.0.2
Server Directory: /opt/openfire
Running on a Centos (6) machine.
I have a plugin and I run a lot of debug code when developing. I will get an instance of a Logger using:
private static final Logger Log = LoggerFactory.getLogger(Submitter.class)
but the problem is that when I look at the logs (DEBUG level), I get EVERYTHING that has DEBUG (for example the httpd Apache libraries). I know that in JBOSS (and other systems) I can make a config that allows me to put Log Ouput of just my plugin to a specific location (e.g. a separate file).
Does anyone have any idea how to do this or if this is possible in Openfire?
Many thanks
In Openfire installation, under lib directory, there's a config file named
log4j.xml
just modify this and override default one.
If you need a log4j tutorial, check out at: https://www.mkyong.com/logging/log4j-xml-example
In you case you can:
redirect your own classes in another custom file
redirect all debug in another file and keep your custom class in
default debug log so it will be viable by Openfire webinterface
Related
Since JDK 9 we have a new Java Logging API:
https://docs.oracle.com/javase/9/docs/api/java/lang/System.Logger.html
https://www.baeldung.com/java-9-logging-api
https://blog.frankel.ch/system-logger/
It's more like a facade, without real logging implementation, but relying on existent logging framework.
We can use this API on Wildfly (with JDK 11), but it binds on JUL (Java Util Logging, default bind on JDK 11), giving log outputs levels from JUL as SEVERE or FINE instead of ERROR or INFO, respectively.
So, I would like to change this, making Java System Logger binds to JBoss Logging Framework (the default on Wildfly).
Following tutorials, I created a custom LoggerFinder and a System.Logger implementation that points to JBoss Logger.
Then I have tried to create a META-INF/services/java.lang.System$LoggerFinder file pointing to my LoggerFinder implementation, as stated on 3rd link above, but with no luck. Tried to put this file on lib jar, app war, app ejb jar and app ear.
Resuming:
Actual: System.Logger -> JUL
Needed: System.Logger -> JBoss Logger
Update 1
I see that WF has a LogManager lib that should handle this (jboss-logmanager-1.1.18.Final.jar):
https://github.com/jboss-logging/jboss-logmanager/blob/2.1.18.Final/src/main/java9/org/jboss/logmanager/JBossLoggerFinder.java
https://github.com/jboss-logging/jboss-logmanager/blob/2.1.18.Final/src/main/resources/META-INF/services/java.lang.System%24LoggerFinder
But it appears that this LogManager is not loaded.
Update 2
Documentation on LoggerFinder says that:
A logger finder is a concrete implementation of this class that has a zero-argument constructor and implements the abstract methods defined by this class. The loggers returned from a logger finder are capable of routing log messages to the logging backend this provider supports. A given invocation of the Java Runtime maintains a single system-wide LoggerFinder instance that is loaded as follows:
First it finds any custom LoggerFinder provider using the ServiceLoader facility with the system class loader.
So, I think that org.jboss.logmanager is not loaded on system class loader. How can I add org.jboss.logmanager to system class loader, and, it's safe to do this?
Update 3
So, I tried to follow some posts on Internet to enable org.jboss.logmanager, changing -Djboss.modules.system.pkgs (I don't know what it does), adding -Djava.util.logging.manager and adding -Xbootclasspath/a:.... Tried multiple combinations of those startup parameters, but it always failed with error or not changing log level names. JBoss LogManager is a multi release jar, so maybe there is something related to it.
Then I build my own custom LoggerFinder implementation, much the same like JBoss LogManager, and tested it in Eclipse with success. In Eclipse I added my jar into classpath user entries of the WF run configuration (don't know what this reflects on WF startup). Now I need to know how to add this jar to WF system class path, I have tried -Xbootclasspath/a:... parameter, but this works partially, my LoggerFinder is loaded, but log messages do not hit log handlers (messages are lost).
Followed this link to configure java util logging with slf4j. All steps mentioned there were executed without error, but data logged with java util logger from webapp were not there in main log file, also there was no separate file created for the same.
I am using jetty-distribution-9.4.11.v20180605 server on my ubuntu 16.04.
Can anyone please help me to configure java util logging
I am using Tomcat 7 / 8 in cloud, in panel log viewer got below log files:
Log files
Catalina.out
instance.log
access log
And i found official document from tomcat, but still confused.
https://tomcat.apache.org/tomcat-7.0-doc/logging.html
I cannot access such folder like /apache/apache-tomcat-8.0.15/logs
Can explain the usage for each log file with sample words?
In simple words:
Catalina.out - Some app logs and system specific logs
instance.log - Application specific logs
access log - Contains the app paths that were accessed (the users' Web requests)
More details / bg:
Catalina.out : "When running Tomcat on unixes, the console output is usually redirected to the file named catalina.out", so your System.out.println, logger.info, or exception should be found in it.
instance.log : the log related to application running status / life cycle.
There are two main approaches to configure Tomcat logs:
a. The java.util.logging (JUL) API
found at ${catalina.base}/conf/logging.properties
b. Apache log4j
found at $CATALINA_BASE/lib/log4j.properties. Don't confuse this with application's logs.
log4j.jar and log4j.properties go into WEB-INF/lib and WEB-INF/classes, respectively, in your web application.
I'm having some trouble configuring proper logging in Eclipse Scout framework. My claims aren't that high as I only want to be able to set different log levels for different parts of my program in a configuration/properties/XML file.
The logging configuration in the config.ini of my Scout server plugin currently looks like this:
eclipse.consoleLog=true
org.eclipse.scout.log=eclipse
org.eclipse.scout.log.level=INFO
So as you can see this is the default logging configuration using Eclipse logging. It works fine for logging at a global level. The only thing I would like to do is to write something like this to set the different log levels:
packagename.ClassName=LOGLEVEL
As this is a very basic logging use case I think there must be some easy way to do this in Scout. Otherwise I would appreciate some help how to configure log4j, JUL or others for the use with Scout. The Eclipse Scout Wiki hasn't helped me so far. I created the example logger fragment to the host plugin 'org.eclipse.scout.commons' and removed the logging configuration lines from my config.ini but nothing happens. I'm also not sure where to put the log4j.poperties or how this is done otherwise.
I'm a bit ashamed for being unable to figure out such a basic problem, but would be very happy about some quick help.
I can tell you how to configure the logging if you choose the java logger (config.ini: org.eclipse.scout.log=java).
For the eclipse logger, I barely found any information at all.
Now, to configure the java (JUL) logging: You can do this in a file called logging.properties.
You can configure the logging by specifying the configuration file in your product:
Create your configuration file - say logging.properties inside the folder where your product file (for server or client respectively) is located. Typically this is in a folder named 'products'.
Open your product file and go to the "Launching" tab and specify your logging configuration file in the "VM Arguments" tab. Use the "java.util.logging.config.file" system property to do so:
-Djava.util.logging.config.file="${resource_loc:/com.yourapp.server/products/logging.properties}"
Now, you should be able to specify the log levels in your new logging.properties file:
### Root level of your application, all below are ignored
.level=INFO
### Handlers
handlers=java.util.logging.ConsoleHandler
### Handler properties
java.util.logging.ConsoleHandler.level=FINEST
### Override the logging level for certain classes
com.yourapp.server.SomeService.level=FINE
Alternatively, you can also use a class to initialize the logging with the java.util.logging.config.class option. See this wiki page for a detailed example.
Also, when building a WAR file, you might be interested in this answer.
I created a Netbeans Platform Application using Netbeans 7.0.1 and the JDK 1.7.
I implemented my own Web Application on a normal module using Embedded Jetty 7.4.5 (consisting of a Web Service and a couple of servlets), and I created a Library Wrapper Module including all the Jetty jar files and the "jetty-j2sehttpspi-7.4.5.v20110725.jar" that I needed to be able to publish the Web Service's Endpoint. The Web module has a dependency on the Jetty module.
The code I'm using is this:
System.setProperty("com.sun.net.httpserver.HttpServerProvider",
"org.mortbay.jetty.j2sehttpspi.JettyHttpServerProvider");
server = new Server();
JettyHttpServerProvider.setServer(server);
//We read the config file
String[] configFiles = {"etc/jetty.xml"};
for(String configFile : configFiles) {
XmlConfiguration configuration =
new XmlConfiguration(new File(configFile).toURI().toURL());
configuration.configure(server);
}
// Web Services
QueryWeb qWS = new QueryWeb();
Endpoint.publish("http://0.0.0.0:" +
(server.getConnectors()[0].getPort()) + "/ws", qWS);
// Servlets
HandlerCollection hc = (HandlerCollection)server.getHandler();
ServletContextHandler sch =
new ServletContextHandler(ServletContextHandler.SESSIONS);
sch.setContextPath("/web");
sch.addServlet(stream.class, "/stream");
// We add the servlet handler to the server's context handler collection
// because it's the one used by the Web Service Endpoint
ContextHandlerCollection chc = (ContextHandlerCollection)hc.getHandlers()[0];
chc.addHandler(sch);
server.start();
When I try and run the application, I get the following error after the "Endpoint.publish" call:
Exiting C:\Program Files (x86)\NetBeans 7.0\harness\run.xml.
Exiting C:\Program Files (x86)\NetBeans 7.0\harness\run.xml.
C:\Program Files (x86)\NetBeans 7.0\harness\suite.xml:500:
The following error occurred while executing this line:
C:\Program Files (x86)\NetBeans 7.0\harness\run.xml:225:
The following error occurred while executing this line:
C:\Program Files (x86)\NetBeans 7.0\harness\run.xml:193:
The application is already running within the test user directory.
You must shut it down before trying to run it again.
As far as I understand, this is happening because the system can't find the "org.mortbay.jetty.j2sehttpspi.JettyHttpServerProvider" class. Therefore it defaults back to the web server included in the JDK, which causes a conflict since we get both web Servers (Jetty and the JDK's) trying to run on the same port (in this case it's 8081).
The only way I managed to fix this problem was by copying all the Jetty jar files into the JRE's "lib/ext" folder (copying only the "jetty-j2sehttpspi-7.4.5.v20110725.jar" results in no errors, but the server won't start). In this way the system can find the class it needs and all it's dependencies.
I suppose that what's going on is that even if NetBeans uses it's own classpath loader, the System.setProperty method is ignoring this and trying to access the standard classpath, and since a NetBeans Platform Application doesn't actually let you change the classpath directly (that would beat the whole purpose of having modules administered by the NetBeans platform), I don't really know how to make it use the library included in the wrapper module.
I can keep developing the application with the temporary solution I found, but honestly, copying stuff into the JRE folders is not an acceptable solution and will eventually result in distribution and installation problems in client machines (already tried it in a Mac OS machine and I didn't even know where the JRE kept it's libraries to try and do the same dirty trick).
Therefore I want to ask you guys if there is any solution to this particular problem or if anyone has a better explanation of what's going on and how I might fix it without having to recreate the whole architecture of my project (which actually works OK except for this little inconvenient).
Thanks in advance!
Write your question to the mailing list, dev#platform.netbeans.org, and you're more likely to get an answer.