Notes by nogeek
Displaying keyword search results 1 - 7
Created by nogeek on December 30, 2011 13:25:28
Last update: December 30, 2011 13:57:37
By default, tomcat uses an enhanced java.util.logging implementation called JULI, which can be configured at two different levels: Globally, with the ${catalina.base}/conf/logging.properties file. Per web application, with WEB-INF/classes/logging.properties . The configuration file is a normal Java properties file: Logging handlers are specified with the handlers property.
handlers = 1catalina.org.apache.juli.FileHandler, ... The root logger can define its set of handlers using the .handlers property. .handlers = 1catalina.org.apache.juli.FileHandler,... A prefix may be added to handler names. The prefix starts with a digit and ends with a dot ( . ), for example: # 1catalina. is a prefix 1catalina.org.apache.j... System property replacement is performed for property values which contain ${systemPropertyName} . Each handler can have its own specific properties: 3manager.org.apache.juli.FileHandler.level = FINE ... Loggers can define their own...
Created by nogeek on December 30, 2011 13:54:04
Last update: December 30, 2011 13:54:04
Tomcat 7.0 failed with a SEVERE error without printing a stack trace:
Dec 30, 2011 1:21:09 PM org.apache.catalina.core.S...
Now it's hard to figure out what's wrong without knowing where things went wrong. Why is Tomcat not logging anything?
Tomcat logging is configured by class loader. Logging behaves differently depending on which class loader loaded the logger. You'll need to look at both $CATALINA_BASE/conf/logging.properties and WEB-INF/classes/logging.properties to figure out why the stack trace is not logged.
In my case, the web app specific WEB-INF/classes/logging.properties overshadowed the system $CATALINA_BASE/conf/logging.properties and suppressed the stack trace.
Created by nogeek on December 29, 2011 13:31:44
Last update: December 29, 2011 14:29:13
Tomcat allows you to create multiple server instances for the same installation. The installation directory is identified as CATALINA_HOME , the instance directory is identified as CATALINA_BASE . Here are the steps: Create a base directory for the new instance, for example: /home/nogeek/tomcat1 . Create the subdirectories:
mkdir -p /home/nogeek/tomcat/{bin,conf,logs,temp,w... Copy web.xml from the installation directory: cp $CATALINA_HOME/conf/web.xml /home/nogeek/tomcat... Copy logging.properties from the installation directory: cp $CATALINA_HOME/conf/logging.properties /home/no... Create server.xml under tomcat1/conf : <?xml version='1.0' encoding='utf-8'?> <Server ... Create script setenv.sh under tomcat1/bin : # Edit this file to set custom options # Tomcat... Copy startup.sh and shutdown.sh from the installation directory. Add the following two lines to the beginning of each: CATALINA_BASE=/home/nogeek/tomcat1 export CATAL... Create a soft link for catalina.sh in tomcat1/bin : $ ln -s ~/apache-tomcat-7.0.22/bin/catalina.sh cat...
Created by nogeek on April 21, 2011 20:38:31
Last update: April 21, 2011 20:39:07
Bring up the "System Properties" dialog (Start -> My Computer -> Right Click -> select Properties )
Click on the Remote tab.
Check the box labeled "Allow users to connect remotely to this computer".
Created by nogeek on December 31, 2010 13:13:54
Last update: December 31, 2010 13:14:45
When a bean is deployed into the JBoss Microcontainer, it goes through these states: NOT_INSTALLED - the deployment descriptor containing the bean has been parsed along with any annotations on the bean itself. DESCRIBED - any dependencies created by AOP have been added to the bean and custom annotations have been processed. INSTANTIATED - an instance of the bean has been created. CONFIGURED - properties have been injected into the bean along with any references to other beans. CREATE - the create method, if defined on the bean, has been called. START - the start method, if defined on the bean, has been called. INSTALLED - any custom install actions that were defined in the deployment descriptor have been executed and the bean is ready...
Created by nogeek on September 29, 2010 19:22:15
Last update: September 29, 2010 19:22:15
Assuming you are using the default server.
Edit the file server/default/conf/login-config.xml
Copy & paste the section:
<application-policy name="web-console">
...
Change the copy to:
<application-policy name="myapp">
<auth...
Create users properties file
Copy server/default/conf/props/jmx-console-users.properties to server/default/conf/props/myapp-users.properties . Change contents to:
# users.properties file for use with the Users...
Create roles properties file
Copy server/default/conf/props/jmx-console-roles.properties to server/default/conf/props/myapp-roles.properties . Change contents to:
# roles.properties file for use with the Users...
Edit web.xml in the application myapp . Add security constraints:
<security-constraint>
<web-resource-col...
Add file WEB-INF/jboss-web.xml with the following contents:
<?xml version='1.0' encoding='UTF-8' ?>
...
where myapp corresponds to the name attribute for application-policy in step 1.
Created by nogeek on June 18, 2010 21:14:34
Last update: June 18, 2010 21:14:34
For the default profile, the admin password is stored in the file server/default/conf/props/jmx-console-users.properties . Simply change the password and save:
# A sample users.properties file for use with the ...
But most likely you are trying to secure the JBOSS server in a production environment, and changing the password only isn't enough. For example, the JMX console is still wide open after you made the above change. Securing the JMX Console and Web Console is quite a daunting task!