I am testing openshift based simple jsf app with Jbossas server.
But it seems that wrong encoding comes in logs by some reason...
For example, some code from jsf bean method:
System.out.println("перед dao.addTask");
System.out.println("name = " + name); // where name value is "экстраординарно"
In server logs we have:
□□□□□□□□□□ dao.addTask
name = □□□□□□□□□□□□□□□
What is the reason for wrong encoding in logs when java code uses utf-8 encoding ?
I think you have to update logger encoding in standalone.xml file. Every OpenShift application has .openshift directory that contains few configuration files and other OpenShift specific files. For JBoss application, there is standalone.xml inside .openshift/config directory. Update following in standalone.xml
<periodic-rotating-file-handler name="FILE">
to
<periodic-rotating-file-handler name="FILE" encoding="UTF-8">
Hope this will help you.
Related
Currently on our project we are seeing some DEBUG statements printed on our tomcat logs such as this:
12:09:00.824 [localhost-startStop-1] DEBUG n.j.w.r.h.b.AbstractResourceBundleHandler - Storing a generated bundle with an id of:/script/lib/itegration.dataTables.bootstrap.js 12:09:00.850 [localhost-startStop-1] DEBUG n.j.w.r.h.b.AbstractResourceBundleHandler - Storing a generated bundle with an id of:/script/lib/itegration.dataTables.bootstrap.js
We have determined that the debug statements that are being logged are caused because the condition LOGGER.isDebugEnabled() in the JAWR AbstractResourceBundleHandler.java class is always true. The snip of the code that logs is as follows:
if (LOGGER.isDebugEnabled()) {
String msg = "Storing a generated "
+ (gzipFile ? "and gzipped" : "")
+ " bundle with an id of:" + bundleName;
LOGGER.debug(msg);
}
As you can see there is a LOGGER.isDebugEnabled() which is always true. Is there a way to configure the logging level for this package/class/jar? We are currently using log4j as our logging framework and have tried configuring this package to log only INFO level but that has not worked. We also have the jawr.debug.on property set to false (jawr.debug.on=false)
I understand that JAWR is using slf4j for their logger and there is a way to use the slf4j bridge to log4j which we have configured, we just cannot get the logging level configuation for this package to work.
Does anyone know a way to set the LOGGER.isDebugEnabled() set to false so that these DEBUG log statements do not appear in our tomcat logs?
We are using log4j.xml not a properties file and would like to keep using the .xml configuration if possible.
Thank you
Adding this to our log4j.xml configuration file
<category name="net.jawr">
<priority value="INFO" />
</category>
works fine.
I have deployed Liferay 6.2 GA4 portal on WebLogic server 10.3.6.0. If the javascript.fast.load property is enabled, the packed javascript version is not got (downloaded) from /combo url. In web browser console the following errors are displayed:
GET https://www.mywebsite.cz/liferay-portal/combo/?browserId=other&minifierType=&languageId=en_US&b=6203&t=1448975784000&/liferay-portal/html/js/aui/color-base/color-base-min.js&/liferay-portal/html/js/aui/event-touch/event-touch-min.js&/liferay-portal/html/js/liferay/dockbar.js 404 (Not Found)
Uncaught TypeError: Cannot read property 'init' of undefined
Due to this for example dockbar doesn't work. From source code it looks like ComboServlet can't get servlet resources found in /combo url parameters. If javascript.fast.load is disabled, portal seems to work.
Weblogic.xml:
<weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd"
>
<jsp-descriptor>
<keepgenerated>true</keepgenerated>
<page-check-seconds>60</page-check-seconds>
</jsp-descriptor>
<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>
<container-descriptor>
<prefer-application-packages>
<package-name>antlr.*</package-name>
<package-name>com.ctc.wstx.*</package-name>
<package-name>org.antlr.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.mozilla.*</package-name>
<package-name>org.xmlpull.*</package-name>
</prefer-application-packages>
<optimistic-serialization>true</optimistic-serialization>
<show-archived-real-path-enabled>true</show-archived-real-path-enabled>
</container-descriptor>
<context-root>/liferay-portal</context-root>
<library-ref>
<library-name>ext-portal-dependencies</library-name>
<specification-version>1.0</specification-version>
<implementation-version>1.0</implementation-version>
<exact-match>false</exact-match>
</library-ref>
</weblogic-web-app>
Does anybody know what could be the problem? Some WebLogic or Liferay settings? Thanks for any idea or help.
I've had a comparable problem long ago on tomcat when there were problems with the temporary file path - e.g. it growing too long. This might happen in a deeply nested filesystem, or when the total path length is limited.
One of the path-length-limiting factors that I'm aware of is an encrypted home folder on Linux. Also, if the temporary filesystem runs full, the compressed file won't be written and consequently can't be served to the browser.
Check something along those lines, and please report back.
After several days of solving the problem I found the main cause of this problem was this:
Because the customer didn't want to have portal dependencies (portal-service.jar, portlet-api.jar, ...) as domain libraries, I deployed it as Java EE Shared Libraries. Obviously it works differently than I expected. So after persuasion of customer, I put liferay dependencies to domain lib folder and suddenly everything started to work.
I am trying to deploy JSF 1.2 application on WAS 8.5 server. But it is throwing below error on deployment.
Note: In the WAS admin, Under JSF implementation use console, I have selected the "Sun Reference Implementation 1.2 " option . But still problem persist.
[12/17/14 15:12:41:222 PST] 00000095 webapp E com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextDestroyed SRVE0285E: Exception caught while destroying context: {0}
java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>
<listener- class> org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:196)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getApplication(FacesContextImplBase.java:131)
at org.apache.myfaces.webapp.AbstractFacesInitializer._dispatchApplicationEvent(AbstractFacesInitializer.java:261)
at org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:293)
at org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:153)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextDestroyed(WebApp.java:1748)
You should restart the application server (not just the app). You should also make sure jsf-api.api and jsf-impl.jar are not in WEB-INF/lib of your app.
I am having trouble with configuring a webapp in Tomcat 7. In my WAR file, there is a properties file myApp/WEB-INF/classes/myProps.props, and it contains environment-specific properites. I am trying to override that configuration file on the server, so that the same WAR file will deploy to multiple environments.
I heard there was a way to do this using replacement config files in tomcat/conf/Catalina/myApp. This is the method I am having trouble figuring out.
Also, myApp.war is one of many running on the same Tomcat server, and it does not run as localhost. I want to be able to solve this problem for several of the webapps.
Server version: Apache Tomcat/7.0.23
Server built: Nov 20 2011 07:36:25
Server number: 7.0.23.0
OS Name: Linux
Your tomcat/conf/Catalina/<host> can contain context descriptors that let you configure lots of things including defining "environment entries", which are accessible from Java via JNDI. There are lots of ways to go about using it. Personally, I set an environment entry which is the file system path to my properties file. My app is built to check for this entry, and if it doesn't exist, look for the file on the classpath instead. That way, in dev, we have the dev properties right there on the classpath, but when we build and deploy, we point it to an external file.
There's good documentation for configuring a context on the Tomcat website. See the Defining a Context section on details of how to create the file and where to put it.
As an example, if your host is named myHost and your app is a war file named myApp.war in the webapps directory, then you could create tomcat/conf/Catalina/myHost/myApp.xml with this content:
<Context>
<Environment name="configurationPath" value="/home/tomcat/myApp.properties" type="java.lang.String"/>
</Context>
Then from your code, you'd do a JNDI lookup on java:comp/env/configurationPath (95% certainty here) to get that string value.
I like .properties files instead of
JNDI - why build complex object during program configuration instead of initialization time?
system properties - you can't separately configure several instances of same WAR in single Tomcat
context parameters - they accessible only in javax.servlet.Filter, javax.servlet.ServletContextListener which my be inconvenient
Tomcat 7 Context hold Loader element. According to docs deployment descriptor (what in <Context> tag) can be placed in:
$CATALINA_BASE/conf/server.xml - bad - require server restarts in order to reread config
$CATALINA_BASE/conf/context.xml - bad - shared across all applications
$CATALINA_BASE/work/$APP.war:/META-INF/context.xml - bad - require repackaging in order to change config
$CATALINA_BASE/work/[enginename]/[hostname]/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/webapps/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/conf/[enginename]/[hostname]/$APP.xml - best - completely out of application and automatically scanned for changes!!!
Context can hold custom Loader org.apache.catalina.loader.VirtualWebappLoader (available in modern Tomcat 7, you can add own separate classpath to your .properties), and Parameter (accessed via FilterConfig.getServletContext().getInitParameter(name)) and Environment (accessed via new InitialContext().lookup("java:comp/env").lookup("name")):
<Context docBase="${basedir}/src/main/webapp"
reloadable="true">
<!-- http://tomcat.apache.org/tomcat-7.0-doc/config/context.html -->
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/WEB-INF/classes=${basedir}/target/classes,/WEB-INF/lib=${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="${basedir}/target/classes;${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<JarScanner scanAllDirectories="true"/>
<Parameter name="min" value="dev"/>
<Environment name="app.devel.ldap" value="USER" type="java.lang.String" override="true"/>
<Environment name="app.devel.permitAll" value="true" type="java.lang.String" override="true"/>
</Context>
If you use Spring and it's XML config:
<context:property-placeholder location="classpath:app.properties"/>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="oracle.jdbc.OracleDriver"/>
<property name="url" value="jdbc:oracle:thin:#${db.host}:${db.port}:${db.user}"/>
<property name="username" value="${db.user}"/>
<property name="password" value="${db.pass}"/>
</bean>
With Spring injecting above properties into bean fields are easy:
#Value("${db.user}") String defaultSchema;
instead of JNDI:
#Inject ApplicationContext context;
Enviroment env = context.getEnvironment();
String defaultSchema = env.getProperty("db.user");
Note also that EL allow this (default values and deep recursive substitution):
#Value('${db.user:testdb}') private String dbUserName;
<property name='username' value='${db.user.${env}}'/>
See also:
Adding a directory to tomcat classpath
Can I create a custom classpath on a per application basis in Tomcat
How to read a properties file outside my webapp context in Tomcat
Configure Tomcat to use properties file to load DB connection information
Should you set up database connection properties in server.xml or context.xml
Externalize Tomcat configuration
NOTE With extending classpath to live directory you also allowed to externilize any other configs, like logging, auth, atc. I externilize logback.xmlin such way.
UPDATE Tomcat 8 change syntax for <Resources> and <Loader> elements, corresponding part now look like:
<Resources>
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/classes" base="${basedir}/target/classes" />
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/lib" base="${basedir}/target/${project.build.finalName}/WEB-INF/lib" />
</Resources>
You can try to place your configuration (properties file) in Apache Tomcat\lib in JAR file and remove it from the web application. When the Tomcat's class loader won't find your config in webapp it will try to find in "lib" directory. So you can externalize your configuration just moving the config to global lib dir (it's shared among other webapps).
I just added a setenv.bat or setenv.sh script in the bin folder of tomcat. Set the classpath variable like
set CLASSPATH=my-propery-folder
I'm having a project using JSF2 (2.1.2), Richfaces4 (4.0.0.Final) on tomcat6 (6.0.28). In order to manage portability between Tomcat and WebSphere7 for my EARs, I have the following jars inside my tomcat lib: el-api-2.2.jar, jsf-api-2.1.2.jar, jsf-impl-2.1.2.jar, validation-api-1.0.0.GA.jar.
My problem is that I never managed to change the log levels of JSF or Richfaces and except from the initialization ones, I don't see any inside my console. Even when I get exceptions in my server response !
I tried several ways:
1) Inside my applications, I'm using slf4j and log4j. So the natural way would be to use SLF4JBridgeHandler.install(). I made a small servlet to call this method during its init() method and added a 'load-on-startup' to be sure it's loaded before JSF Servlet (I'm not sure tomcat cares at all about this load-on-startup directive because I still get logs from JSF init before), e.g.:
INFO: JSF1027 : [null] Les objets ELResolvers de JSF n’ont pas été enregistrés avec le conteneur JSP.
09-09-2011 16:50:58:591 [Thread-2] 937 DEBUG com.jsf.test.SLF4JBridgeHandlerInstallerServlet - SLF4JBridgeHandler.install() OK!
I also added some configuration in my log4j.xml:
<logger name="javax.faces"><level value="debug"/></logger>
<logger name="com.sun.faces"><level value="debug"/></logger>
<logger name="javax.enterprise.resource.webcontainer.jsf"><level value="debug"/></logger>
But I don't see any logs in my console when displaying a JSF page...
I also tried using a filter to call SLF4JBridgeHandler.install() before the execution of the JSF Servlet, but I only get a lot of OK logs from my filter...
2) I tried to follow the tutorial here exactly (it creates new files in tomcat log folder for each logger of JSF2). I tried by changing the logging.properties inside the conf folder of tomcat and by adding a new logging.properties inside my src/resources/ folder in my application. But no luck...
3) I tried to add the JSF loggers to the the logging.properties inside my tomcat by adding this:
javax.enterprise.resource.webcontainer.jsf.managedbean.level=FINEST
javax.enterprise.resource.webcontainer.jsf.managedbean.handlers = java.util.logging.ConsoleHandler
javax.enterprise.resource.webcontainer.jsf.config.level=FINEST
javax.enterprise.resource.webcontainer.jsf.config.handlers = java.util.logging.ConsoleHandler
javax.enterprise.resource.webcontainer.jsf.facelets.level=FINEST
javax.enterprise.resource.webcontainer.jsf.facelets.handlers = java.util.logging.ConsoleHandler
javax.enterprise.resource.webcontainer.jsf.resource.level=FINEST
javax.enterprise.resource.webcontainer.jsf.resource.handlers = java.util.logging.ConsoleHandler
javax.enterprise.resource.webcontainer.jsf.lifecycle.level=FINEST
javax.enterprise.resource.webcontainer.jsf.lifecycle.handlers = java.util.logging.ConsoleHandler
No luck yet...
4) I tried to use log4j inside tomcat instead of juli by following this documentation. It seems to work well, but changing the resulting log4j.properties to put the JSF loggers in DEBUG didn't work...
Any idea ?
Regards,
Florian
Two facts:
JSF uses java.util.logging API which is to be configured by a logging.properties file in the root of the runtime classpath.
The logging.properties file of the currently(!) running runtime environment (JRE) will be used.
If you're running Tomcat from inside an IDE like Eclipse, then Tomcat's own logging.properties won't be used. The one in JDK/JRE/lib will be used where "JDK" is the JDK install folder such as jdk1.6.0_23. If you'd like to explicitly specify the location of the logging.properties file, then you would need to set a VM argument:
-Djava.util.logging.config.file=/path/to/tomcat/logging.properties
Regardless of the logging file used, in order to enable Mojarra logging, you need to open the logging.properties template file in question, scroll to the bottom and edit the following line near the bottom
java.util.logging.ConsoleHandler.level = INFO
into
java.util.logging.ConsoleHandler.level = ALL
so that the global console level is set to ALL instead of INFO. Otherwise lower levels than INFO just won't be logged at all.
Finally add the following two lines to the very bottom of the file
javax.faces.level = ALL
com.sun.faces.level = ALL
javax.enterprise.resource.webcontainer.jsf.level = ALL
The first turns on all JSF API logging, the second turns on all JSF impl (Mojarra) logging, and the third turns on all JSF Java EE logging.