亚洲视频手机在线,亚洲精品国产日韩无码AV永久免费网 ,亚洲精品人成网线在线播放va

birt tomcat Cannot load JDBC Driver class

R.Zeus — Fri, 23 May 2008 08:24:00 GMT

Cannot load JDBC Driver class: com.mysql.jdbc.Driver

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!!

R.Zeus 2008-05-23 16:24 发表评论

R.Zeus — Thu, 22 Nov 2007 11:07:00 GMT

debug="0" privileged="true"/>

R.Zeus 2007-11-22 19:07 发表评论

装了n�ơtomcat后tomcat不能启动

R.Zeus — Tue, 09 Jan 2007 09:56:00 GMT

几乎每次建新��目都会用新的tomcat�Q�结果今天�v不来了，错误报告找不到�\径，察看了环境变量，发现有个class_path属性指向一个删除的目录中的jar�Q�把它删后tomcat ��正�怺�。在找不到问题的情况下，重装�pȝ��也是一个不多的选择�Q�ghost也快�?img src ="http://www.tkk7.com/RR00/aggbug/92681.html" width = "1" height = "1" />

R.Zeus 2007-01-09 17:56 发表评论

Resin search

R.Zeus — Mon, 06 Nov 2006 09:43:00 GMT

according to project's need,I download the resin and expore this open-source server the first time for me.below is some problem and may be with solved ways.
1.cache for IE.I don't konw intellij IDE make this trick or the resin.no matter I change the jsp or delete it,the page seem never change.after I change the struts-comfig.xml or the tiles.xml pointing to another jsp coping from the sick page,then I can do what I want and not restart the server.
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 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 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 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

...

....

it also can set for a appointed web-app.

version:
intellij IDE: 6.0.1
Resin:resin-pro-3.0.21
DB: sql-server

R.Zeus 2006-11-06 17:43 发表评论

more server run applicatin on the same database will be error!

R.Zeus — Fri, 20 Oct 2006 05:35:00 GMT

                      if there are more than two server run with the same system code
            and call the save method at the same time ,it will be result of hibernate
            error!because hibernate get the max id for ganerator and store it in
            cache for next time using.so one server will get the expired id if another
            server change the database following.
            befroe save object,hibernate will excute this sql after the server start up once:
             Hibernate: select max(ID) from TB_LOG
            TB_LOG is my log table.

R.Zeus 2006-10-20 13:35 发表评论

Set the Logging Level Over a Tomcat Cluster Dynamically

R.Zeus — Thu, 14 Sep 2006 09:03:00 GMT

Set the Logging Level Over a Tomcat Cluster Dynamically

Rather than modifying your Log4J configuration and then redeploying the correct code version with the modified logging level, you can dynamically set the Log4J logging level over each node in a Tomcat cluster with JMX.

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?

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—each with its own Log4J configuration that allows it to log to a separate log file—then 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 nameParameters = new Hashtable();
        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 nameParameters = new Hashtable();
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:

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

To send a message to the other nodes in a Tomcat cluster, you need to call the 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 nameParameters = new Hashtable();
            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  element: 


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.

R.Zeus 2006-09-14 17:03 发表评论

log4j in tomcat

R.Zeus — Thu, 14 Sep 2006 06:41:00 GMT

log4j.xml 可以攑֜�2个地方：
1〉��?strong>springframework在web.xml中配�|?br />//讄��webAppRootKey的别名，
//如果不设�|�，在log4j.xml中设�|��ؓ${webapp.root}/WEB-INF/log/frame.log " />
//否则�Q�可以设�|��ؓ${demo.root}/WEB-INF/log/frame.log " />
//如果不��?font color="#0000ff">${webapp.root}�Q�就会指�?{TOMCAT_HOM},也就是tomcat的安装目�?font color="#ff0000">�?/font>

webAppRootKey
demo.root

//讄��配置文�g

        log4jConfigLocation
        /WEB-INF/log4j.xml


//讄��监听�?br />
  org.springframework.web.util.Log4jConfigListener

�q�样log4j.xml ��可以WEB-INF里面的�Q何�\径�?br />
Source:

initLogging->
{
      WebUtils.setWebAppRootSystemProperty(servletContext);
      {
      String root = servletContext.getRealPath("/");
      String param = servletContext.getInitParameter(WEB_APP_ROOT_KEY_PARAM);
       String key = (param != null ? param : DEFAULT_WEB_APP_ROOT_KEY);
        System.setProperty(key, root);
      //use system property to deal with ${webapp.root} or its alias.
      //once I writed careless ${webapp.root} to {webapp.root} ,and look up the error for much time.
          }
      String location = servletContext.getInitParameter(CONFIG_LOCATION_PARAM);
      Log4jConfigurer.initLogging(location);
      {

         //distinguish the log4j.xml and log4j.properties
         if (resolvedLocation.toLowerCase().endsWith(XML_FILE_EXTENSION)) {
            DOMConfigurator.configure(url);
        }
     else {
         PropertyConfigurator.configure(url);
     }
      }
}
use DOMConfigurator.configure("log4j.xml"); to init config ,then LogFactory can work. the "log4j.xml "
may be any name .DOMConfigurator may use cache mechanism as in LogFactory class .cache machanism is
another way to implement "single" design pattern.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2〉WEB-INF/classes下面

采取�q�种方式�Q�它的文件appender的相对�\径��L��指向${TOMCAT_HOM},也就是tomcat的安装目�?font color="#ff0000">�?lt;param name="File" value="demo.log" /> 会把demo.log 保存�?/font>${TOMCAT_HOM}/demo.log �Q?br />采用�l�对路径则可以�Q意设�|��?br />
��Z��使用相对路径�Q�我们把project攑ֈ�${TOMCAT_HOMe}/webapps下deploy�?br />如project名�ؓdemo�Q�log要保存在demo/log/demo.log文�g里，则可以设为：

---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
注意“\" 要用转义字符"\\",如果没加,tomcat启动屏中的�\径会变�ؓ��q��.

tomcat中似乎采取了某种安全�{�略,不�v作用�?br />
服务器重起后��׃��新徏一个log文�g.

R.Zeus 2006-09-14 14:41 发表评论