I am using JBoss EAP 6 and would like to know how to configure the session-timeout property. Unlike jboss-4.0.5.GA, there is no web.xml in folder /deployers/jbossweb.deployer/
You can modify the default session timeout by changing the default-session-timeout attribute of the web subsystem.
Setting it 15 minutes for example:
/subsystem=web:write-attribute(name=default-session-timeout,value=15)
result in xml:
<subsystem xmlns="urn:jboss:domain:web:2.2" default-virtual-server="default-host" native="false" default-session-timeout="15">
</subsystem>
Related
for my Portlet(*) I'm getting "ViewExpiredException"s although my session-timeout in ROOT/WEB-INF/web.xml is set with 600 (minutes).
The (portletapp)/WEB-INF/web.xml has no session-timeout configured.
Also there is no configuration like
session.timeout=30
in a portal.properties like mentioned in https://www.liferay.com/de/community/wiki/-/wiki/Main/Session+Timeout
Regarding the exception I'm currently planning to set
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
But I'd like to understand the problem. Where can I find other session-timeout configurations, or is this a default I need to overwrite?
Regards,
Gunnar
(*) Liferay 6.2 EE SP10 on Tomcat 7.0.42, Mojarra 2.1.29, Portlet 2.0, Servlet 2.5, jstl 1.2.1, facelets 1.1.15, Primefaces 5.0
Update: Maybe I found the solution after more searching: Default session timeout for Apache Tomcat applications
(Tomcat's default session timeout in conf/web.xml)
Update: Problem not solved, own answer deleted.
I just got the "ViewExpiredException" again.
I added debug logging of
"maxInactiveInterval: " + PortalUtil.getHttpServletRequest(((PortletRequest)FacesUtil.getExternalContext().getRequest())).getSession().getMaxInactiveInterval()
and I see my 600 configured minutes as 36000 seconds.
Any hints why I keep getting "ViewExpiredException"s?
My next try will be the portal.properties-entry mentioned above.
When I try to invoke local EJB I get EJBAccessException running my migrated Glassfish web application on Wildfly 8.2. I found the JBoss documentation all other than strait forward and need help, i.e. no link to JBoss documentation please.
I have no #DeclareRoles notation on my EJB to make it simple for now. I tried with and without using the security realm other adding jboss-web and jboss-ejb3 to tie the bean to a realm. But I still get the same exception.
I've read these tutorials, but can't get it to work. I am using MongoDB and JDBC security realm setup don't help me much. But for now I bypass the user-role authentication.
Migrating a Java EE App from GlassFish to WildFly
Invoke EJB from WildFly safely
And others
How can I run local EJB on Wildfly in my web application?
#Stateless
public class MyBean {
public String sayHello() {
...
jboss-web.xml
<jboss-web>
<security-domain>other</security-domain>
</jboss-web>
jboss-ejb3.xml
<assembly-descriptor>
<s:security>
<!-- Even wildcard * is supported -->
<ejb-name>*</ejb-name>
<!-- Name of the security domain which is configured in the EJB3 subsystem -->
<s:security-domain>other</s:security-domain>
</s:security>
</assembly-descriptor>
In WildFly 8, such methods which have no explicit security configurations, in a secured bean, will be treated similar to a method with #DenyAll configuration.
This behaviour can be controlled via the jboss-ejb3.xml deployment descriptor at a per bean level or a per deployment level as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jboss:jboss
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:s="urn:security:1.1"
version="3.1" impl-version="2.0">
<assembly-descriptor>
<s:security>
<!-- Even wildcard * is supported where * is equivalent to all EJBs in the deployment -->
<ejb-name>FooBean</ejb-name>
<s:missing-method-permissions-deny-access>false</s:missing-method-permissions-deny-access>
</s:security>
</assembly-descriptor>
</jboss:jboss>
Setting missing-method-permissions-deny-access to false allows access to such methods for all users i.e. the behaviour will be switched to be similar to #PermitAll.
wanna enable httpOnly attribute to session cookie for our application. we are using servlet-api 2.5 version and web.xml as 2.5 .. now i have tried adding below code in web.xml
<cookie-config>
<http-only>true</http-only>
</cookie-config>
i got error parsing error in web.xml at <cookie-config>
can any please help on this.. do i need to update servlet version to 3 and web.xml to 3 as well ...
or any other ways to do it writing in java code itself.. we are using jboss 5 version..
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.