fuck !! because of deleting the temp dir in tomcat,it report this error! foolish birt! why can't it create a temp dir for the db driver to store!!
]]>
]]>
]]>
2.the resin will create a dir named 'work' in the 'web-inf'.and when compile,the java file in the
'work' dir may be reported error.so I delete it.
3.Hibernate error.for associate relation,Tomcat doesn't check but Resign check strictly.this may be becaust of the jsp-compile way.
4.For intellij-IDE's聽(tīng) resin plug,it didn't compile before run just as Tomcat plug.so you must compile yourself if any class changed.
5.the most different聽(tīng)between Tomcat and Resin is the JSTL compile.Resin will generate the fast-jstl code and Tomcat do nothing.Resin contains the jstl-11.jar.In my former聽(tīng) training demo,the company jar we used seems associate with the jstl-xx.jar,so I can't delete the jstl jar
from the demo lib.Then the demo run error when in Resin until close the fast-jstl.
resin.conf
聽(tīng)<web-app-default>
...
聽(tīng) <jsp fast-jstl='false'/>
....
聽(tīng)</web-app-default>
it also can set for a appointed web-app.
version:
intellij IDE: 6.0.1
Resin:resin-pro-3.0.21
DB: sql-server
]]>
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) and call the save method at the same time ,it will be result of hibernate
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) error!because hibernate get the max id for ganerator and store it in
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) cache for next time using.so one server will get the expired id if another
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) server change the database following.
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) befroe save object,hibernate will excute this sql after the server start up once:
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) Hibernate: select max(ID) from TB_LOG
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) TB_LOG is my log table.
]]>
| by Jon Dickinson |
henever you have to fix a problem in a production environment, one of the most common issues is retrieving some useful debug information to tell you what happened. Of course, to avoid needless notifications and enormous log files, most production systems are configured to log only errors. To avoid having to modify your Log4J configuration and then redeploy the correct version of the code with the modified logging level, why not just implement a mechanism for dynamically changing the logging level?聽(tīng)
Log4J registers a number of MBeans, one of which provides access to the root logger. You can dynamically modify the logging level of the root logger by implementing the following servlet to set the appropriate MBean property through JMX:
public class SetLog4jLevelServlet extends HttpServlet {
private static final Log log = LogFactory.getLog(SetLog4jLevelServlet.class);
protected void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
List list = MBeanServerFactory.findMBeanServer(null);
MBeanServer server = (MBeanServer)list.iterator().next();
try {
String loggingLevel = request.getParameter("level");
Attribute attribute = new Attribute("priority", loggingLevel);
ObjectName objectName = new ObjectName("log4j:logger=root");
server.setAttribute(objectName, attribute);
} catch (Exception e) {
log.error("log4j:logger=root", e);
}
}
}
The first two lines of the doGet method look up the MBeanServer. Log4J registers the root logger with the name log4j:logger=root. This MBean provides a property to set the logging level of the root logger. You set the priority of the root logger by passing the ObjectName of the MBean to operate on, along with an instance of javax.management.Attribute to the MBean Server. In this case, you want to set the "priority" attribute. The value will be the new logging level you have specified
A Log4J MBean for Each Log4J Configuration
Although this technique seems simple, if your Tomcat cluster hosts a number of Web applications鈥攅ach with its own Log4J configuration that allows it to log to a separate log file鈥攖hen you will run into your first problem. Given multiple Log4J configurations, only the first one loaded by the JVM will have a root logger MBean associated with it. The reason for this is Log4J hard-codes the JMX Domain that it uses when registering its MBeans as log4j, and the JMX server doesn't allow duplicate names.
The way round this is to leave a Tomcat server Log4J configuration (jars under server/lib and property files under server/classes) registered under the default Log4J name log4j:logger=root. Then register the root logger for each Web application in a startup servlet, using the Web application name to identify the domain:
public class RegisterLog4JMBeanServlet extends HttpServlet {
private static final Log log = LogFactory.getLog(RegisterLog4JMBeanServlet.class);
public void init(ServletConfig servletConfig)
throws ServletException {
ServletContext context = servletConfig.getServletContext();
String webappName = context.getServletContextName();
Hashtable<String, String> nameParameters = new Hashtable<String, String>();
nameParameters.put("logger", "root");
Logger rootLogger = LogManager.getRootLogger();
LoggerDynamicMBean mbean = new LoggerDynamicMBean(rootLogger);
List list = MBeanServerFactory.findMBeanServer(null);
MBeanServer server = (MBeanServer)list.iterator().next();
ObjectName objectName = null;
try {
objectName = new ObjectName(webappName, nameParameters);
server.registerMBean(mbean, objectName);
} catch (Exception e) {
log.error("Problems registering Log4J MBean", e);
}
}
}
You will end up with an MBean named <web-app-name>: logger=root for each Web application. The webappName is retrieved from the <display-name> element in your application's web.xml file, and the application's root logger is retrieved by calling LogManager.getRootLogger(). Then you can use the LoggerDynamicMBean class from Log4J to create your MBean from the root logger definition.
To create a distinct ObjectName for the new MBean, you should use the Web application name as the JMX domain (this is the text before the colon) and then register the Root Logger MBean with the new ObjectName. This will guard against conflicts with other Log4J MBeans.
Now that you have registered your Root Logger under a different domain, you must modify the servlet that sets the logging level. So in SetLog4JlevelServlet, change this:
ObjectName objectName = new ObjectName("log4j:logger=root");
To this:
ServletContext context = servletConfig.getServletContext();
String webappName = context.getServletContextName();
Hashtable<String, String> nameParameters = new Hashtable<String, String>();
nameParameters.put("logger", "root");
ObjectName objectName = new ObjectName(webappName, nameParameters);
When setting up your Log4J configuration, give your Log4J appenders unique names. Otherwise, they will not get registered to the JMX server and you will get lots of the following errors in your log files at startup:
ERROR main org.apache.log4j.jmx.LoggerDynamicMBean ? - Could not add appenderMBean for [<appender_name>].
javax.management.InstanceAlreadyExistsException: log4j:appender=<appender_name>
Again, the reason for this is because the JMX domain name his hard-coded to log4j, so if you have repeated appender names then only the first of these will be registered.
At this point, configuring the MX4J HTTP adaptor in your Tomcat server might be useful. This will give you a visual representation of the MBeans you are creating and manipulating, and show you what else is exposed via MBeans within Tomcat. To do this, you must put the mx4j-tools.jar file (download it at mx4j.sourceforge.net) in your common/lib directory. Then configure your server.xml file to set up the connector as follows:
<Connector port="8010"
handler.list="mx"
mx.enabled="true"
mx.httpHost="localhost"
mx.httpPort="8013"
protocol="AJP/1.3"/>
When you start your server, you will be able to access the MX4J HTTP connector through your browser at http://localhost:8013, assuming you have no other Tomcat connector running on port 8010.
Set the Logging Level for All the Nodes in Your Cluster
Once you have made the previously discussed changes, you will be able to set the Log4J logging level dynamically for any application running in Tomcat. The next challenge is to make sure you can set the logging level for every node in the cluster. You could either call this servlet manually on each node in the cluster or get the servlet to send a message to every other node in the cluster so the logging levels are always the same across the cluster
send(ClusterMessage) method on the org.apache.catalina.cluster.SimpleTcpCluster class. When implementing a ClusterMessage, you must populate the details of the cluster node that was responsible for sending the request. (Listing 1 provides an example that retrieves the information through the Tomcat MBeans.) The first step is to provide an implementation of the ClusterMessage interface to pass the new logging level and to determine for which application you want to set the logging level.
It may seem strange, but you must use JMX over RMI to send the message to the cluster because the interface implemented in Listing 1 is defined within the Tomcat server class loader (i.e., it exists in a jar file in the server directory). You will instantiate that class in a Web application, which uses a totally separate class loader (it exists in the WEB-INF directory of your Web application). This means that the cluster message you instantiate in your Web application and send to the SimpleTcpCluster class will be different from the cluster message definition that is placed in the Tomcat server class loader. If you try to send your message directly through JMX, your cluster message instance will not match the cluster message definition accessible to the SimpleTcpCluster class and the call will fail. (See the Tomcat documentation on class loaders for a definition of how the class loaders are configured for the Tomcat server.)
The workaround is to use JMX over RMI so the cluster message is serialized in the Web application class loader, instantiated in the Tomcat server class loader (and that is the important point), and then de-serialized. The following method opens a connection to the local JVM's JMX server over RMI, looks up the MBean that wraps the SimpleTcpCluster, and then invokes the send(ClusterMessage) operation on the MBean:
public static void sendLogMessageEvent(String applicationName, String logLevel) {
String port = System.getProperty("com.sun.management.jmxremote.port");
String urlForJMX = JMX_SERVICE_PREFIX + HOST + ":" + port + JMX_SERVICE_SUFFIX;
try {
JMXServiceURL url = new JMXServiceURL(urlForJMX);
JMXConnector connector = JMXConnectorFactory.connect(url, null);
MBeanServerConnection server = connector.getMBeanServerConnection();
ObjectName cluster = new ObjectName("Catalina:type=Cluster,host=localhost");
log.debug("Cluster cluster: " + cluster.toString());
LogLevelMessage message = new LogLevelMessage();
message.setLoggingLevel(logLevel);
message.setApplication(applicationName);
Object[] params = new Object[] {message};
String[] types = new String[] {"org.apache.catalina.cluster.ClusterMessage"};
server.invoke(cluster, "send", params, types);
} catch (Exception e) {
log.error(e.getMessage(), e);
}
}
You should call this method in your SetLog4JLevelServlet to ensure that a message is sent to the other members of the cluster when you set the logging level.
You will need to configure your Tomcat server to allow a JMX connection to be opened up over RMI. Simply add the following line to your catalina.bat file in the bin directory:
set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.port=8012
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
For a quick guide on applying security to this configuration, see the Tomcat documentation. For a more in-depth look at configuring JMX Remote, see the Sun documentation.
Receiving the Message in the Other Nodes
Once you are able to send these messages to the other nodes in the cluster, you will need to implement a Tomcat ClusterListener to receive the events. This implementation will set the logging level for the correct MBean determined by the application name that is passed as part of the message:
public class ClusterLoggingListener extends ClusterListener {
private static final Log log = LogFactory.getLog(ClusterLoggingListener.class);
public void messageReceived(ClusterMessage message) {
if(message instanceof LogLevelMessage) {
LogLevelMessage logMessage = (LogLevelMessage) message;
List list = MBeanServerFactory.findMBeanServer(null);
MBeanServer server = (MBeanServer)list.iterator().next();
Hashtable<String, String> nameParameters = new Hashtable<String, String>();
nameParameters.put("logger", "root");
try {
ObjectName logBean = new ObjectName(logMessage.getApplication(), nameParameters);
Attribute attribute = new Attribute("priority", logMessage.getLoggingLevel());
server.setAttribute(logBean, attribute);
} catch (Exception e) {
log.error("Problem setting the logging level for application " +
logMessage.getApplication() + " to level " +
logMessage.getLoggingLevel(),e);
}
}
}
public boolean accept(ClusterMessage message) {
return message instanceof LogLevelMessage;
}
}
You must deploy this class in the server directory and enter it in the Tomcat server.xml file as a ClusterListener within the <Cluster> element:
<ClusterListener className="dynamiclogging.tomcat.ClusterLoggingListener"/>
You should now be able to set the logging level for any application, over all nodes, in the cluster by calling SetLog4JLevelServlet on any node in the cluster.
Deploying the Example Code
To deploy the example code for setting the logging level in your cluster, take the following steps: - Load the Eclipse project and build it using the dist target. This will create set-log-levels.war and set-log-levels-server.jar in the dist directory.
- Put the set-log-levels-server.jar in the Tomcat server\lib directory and deploy the set-log-levels.war file across the cluster.
- Use the SetLog4jLevelServlet (e.g.,
/setLogLevel?level=debug) to set the logging level and use PerformLogTestServlet (/testLogLevel) to test the logging level changes.
]]>
1銆変嬌鐢?strong>springframework鍦╳eb.xml涓厤緗?br />//璁劇疆webAppRootKey鐨勫埆鍚嶏紝
//濡傛灉涓嶈緗紝鍦╨og4j.xml涓緗負(fù)<param name="File" value="${webapp.root}/WEB-INF/log/frame.log " />
//鍚﹀垯錛屽彲浠ヨ緗負(fù)<param name="File" value="${demo.root}/WEB-INF/log/frame.log " />
//濡傛灉涓嶄嬌鐢?font color="#0000ff">${webapp.root}錛屽氨浼?xì)鎸囧?{TOMCAT_HOM},涔熷氨鏄痶omcat鐨勫畨瑁呯洰褰?font color="#ff0000">銆?/font>
聽(tīng)<context-param>
聽(tīng)聽(tīng)<param-name>webAppRootKey</param-name>
聽(tīng)聽(tīng)<param-value>demo.root</param-value>
聽(tīng)</context-param>
//璁劇疆閰嶇疆鏂囦歡聽(tīng)聽(tīng)聽(tīng)
<context-param>
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) <param-name>log4jConfigLocation</param-name>
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng) <param-value>/WEB-INF/log4j.xml</param-value>
聽(tīng)聽(tīng)聽(tīng) </context-param>
//璁劇疆鐩戝惉鍣?br />聽(tīng) <listener>
聽(tīng)聽(tīng)<listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
聽(tīng)</listener>
榪欐牱log4j.xml 灝卞彲浠EB-INF閲岄潰鐨勪換浣曡礬寰勩?br />
Source:
initLogging->
{
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)WebUtils.setWebAppRootSystemProperty(servletContext);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng){
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)String root = servletContext.getRealPath("/");
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)String param = servletContext.getInitParameter(WEB_APP_ROOT_KEY_PARAM);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)String key = (param != null ? param : DEFAULT_WEB_APP_ROOT_KEY);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)System.setProperty(key, root);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)//use system property聽(tīng)to聽(tīng)deal with ${webapp.root} or聽(tīng)its聽(tīng)alias.
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)//once聽(tīng)I(yíng)聽(tīng)writed careless聽(tīng)${webapp.root}聽(tīng)to {webapp.root}聽(tīng),and聽(tīng)look up聽(tīng)the error for聽(tīng)much time.
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)}
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)String location = servletContext.getInitParameter(CONFIG_LOCATION_PARAM);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)Log4jConfigurer.initLogging(location);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng){
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)//distinguish the log4j.xml聽(tīng)and聽(tīng)log4j.properties
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)if (resolvedLocation.toLowerCase().endsWith(XML_FILE_EXTENSION)) {
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)DOMConfigurator.configure(url);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)}
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)else {
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)PropertyConfigurator.configure(url);
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)}
聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)聽(tīng)}
}
use DOMConfigurator.configure("log4j.xml"); to init config ,then LogFactory can work. the "log4j.xml "
may be any name .DOMConfigurator may use cache mechanism聽(tīng)as聽(tīng)in LogFactory class .cache machanism is
another way to implement "single" design pattern.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2銆塛EB-INF/classes涓嬮潰
閲囧彇榪欑鏂瑰紡錛屽畠鐨勬枃浠禷ppender鐨勭浉瀵硅礬寰勬繪槸鎸囧悜${TOMCAT_HOM},涔熷氨鏄痶omcat鐨勫畨瑁呯洰褰?font color="#ff0000">銆?lt;param name="File" value="demo.log" /> 浼?xì)鎶?/font>demo.log 淇濆瓨鍒?/font>${TOMCAT_HOM}/demo.log 錛?br />閲囩敤緇濆璺緞鍒欏彲浠ヤ換鎰忚緗?br />
涓轟簡(jiǎn)浣跨敤鐩稿璺緞錛屾垜浠妸project鏀懼埌${TOMCAT_HOMe}/webapps涓媎eploy銆?br />濡俻roject鍚嶄負(fù)demo錛宭og瑕佷繚瀛樺湪demo/log/demo.log鏂囦歡閲岋紝鍒欏彲浠ヨ涓猴細(xì)
<param name="File" value="webapps\\demo\\log\\framefile.log" />
---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
娉ㄦ剰鈥淺" 瑕佺敤杞箟瀛楃"\\",濡傛灉娌″姞,tomcat鍚姩灞忎腑鐨勮礬寰勪細(xì)鍙樹(shù)負(fù)涔辯爜.
tomcat涓技涔庨噰鍙栦簡(jiǎn)鏌愮瀹夊叏絳栫暐,<param name="Append" value="false" />涓嶈搗浣滅敤銆?br />
鏈嶅姟鍣ㄩ噸璧峰悗灝變細(xì)鏂板緩涓涓猯og鏂囦歡.
]]>