tapestry5 错误提示信息没有了

向右看齐 2022-07-12 10:14 207阅读 0赞

本来tapesty5有很精确的错误提示，但是我的怎么就没有了呢？  
后来在网上找到这样一句话：  
tapestry5有个production-mode，默认的为true，可以在作为产品发布时，提供精简的错误信息，在开发时，异常信息当然是越精确 越好，而且精确的异常信息也是tapestry的强项，可以很准确的告诉您错误出在哪里，所以在开发时这个选项要关掉，选中运行配置中的 arguments标签，在vm  
arguments中添加-Dtapestry.production-mode=false  
  
出处：http://tapestry.javaeye.com/blog/191803  
  
我于是在jvm arguments中添加了-Dtapestry.production-mode=false，果然可以了！！谢谢这位仁兄！  
  
  
  
//  
上述问题的另外解决方法：不在jvm中添加参数，而是在service包下增加下面这个文件：

我用的就是这个方法，同时要特别注意，在加载jar包时，没有用的jar包要删除掉。我的tapestry+spring,hibernate集成在application context里边，但是我还是加载了tapestry-hibernate and tapestry-hibernate-core jar package. it causes the tom cat 6 server to look for the hibernate.cfg.xml file although we defined all ORMs in our applicationContext file with Spring.

THUS, KEEP IN MIND THAT DO NOT ADD NON-NECCESARY JAR PACKAGES.

NO NEED TO RESTART TOMCAT SERVER IF TML FILES ARE MODIFIED, THERE ARE SOME DEBAT ABOUT WHETHER RESTART THE SERVER IF PAGE CLASS ARE MODIFIED.

import java.io.IOException;

import org.apache.tapestry5.\*;  
import org.apache.tapestry5.ioc.MappedConfiguration;  
import org.apache.tapestry5.ioc.OrderedConfiguration;  
import org.apache.tapestry5.ioc.ServiceBinder;  
import org.apache.tapestry5.ioc.annotations.Local;  
import org.apache.tapestry5.services.Request;  
import org.apache.tapestry5.services.RequestFilter;  
import org.apache.tapestry5.services.RequestHandler;  
import org.apache.tapestry5.services.Response;  
import org.slf4j.Logger;

/\*\*  
 \* This module is automatically included as part of the Tapestry IoC Registry, it's a good place to  
 \* configure and extend Tapestry, or to place your own service definitions.  
 \*/  
public class AppModule  
\{  
    public static void bind(ServiceBinder binder)  
    \{  
        // binder.bind(MyServiceInterface.class, MyServiceImpl.class);  
         
        // Make bind() calls on the binder object to define most IoC services.  
        // Use service builder methods (example below) when the implementation  
        // is provided inline, or requires more initialization than simply  
        // invoking the constructor.  
    \}  
     
     
    public static void contributeApplicationDefaults(  
            MappedConfiguration<String, String> configuration)  
    \{  
        // Contributions to ApplicationDefaults will override any contributions to  
        // FactoryDefaults (with the same key). Here we're restricting the supported  
        // locales to just "en" (English). As you add localised message catalogs and other assets,  
        // you can extend this list of locales (it's a comma separated series of locale names;  
        // the first locale name is the default when there's no reasonable match).  
         
        configuration.add(SymbolConstants.SUPPORTED\_LOCALES, "en,zh\_cn");

// The factory default is true but during the early stages of an application  
        // overriding to false is a good idea. In addition, this is often overridden  
        // on the command line as -Dtapestry.production-mode=false  
        configuration.add(SymbolConstants.PRODUCTION\_MODE, "false");//有了这句就不用加jvm arguments了  
          
        configuration.add(SymbolConstants.COMPRESS\_WHITESPACE, "false");  
        configuration.add(SymbolConstants.CHARSET, "UTF-8");  
         
    \}

/\*\*  
     \* This is a service definition, the service will be named "TimingFilter". The interface,  
     \* RequestFilter, is used within the RequestHandler service pipeline, which is built from the  
     \* RequestHandler service configuration. Tapestry IoC is responsible for passing in an  
     \* appropriate Logger instance. Requests for static resources are handled at a higher level, so  
     \* this filter will only be invoked for Tapestry related requests.  
     \*  
     \* <p>  
     \* Service builder methods are useful when the implementation is inline as an inner class  
     \* (as here) or require some other kind of special initialization. In most cases,  
     \* use the static bind() method instead.  
     \*  
     \* <p>  
     \* If this method was named "build", then the service id would be taken from the  
     \* service interface and would be "RequestFilter".  Since Tapestry already defines  
     \* a service named "RequestFilter" we use an explicit service id that we can reference  
     \* inside the contribution method.  
     \*/     
    public RequestFilter buildTimingFilter(final Logger log)  
    \{  
        return new RequestFilter()  
        \{  
            public boolean service(Request request, Response response, RequestHandler handler)  
                    throws IOException  
            \{  
                long startTime = System.currentTimeMillis();

try  
                \{  
                    // The responsibility of a filter is to invoke the corresponding method  
                    // in the handler. When you chain multiple filters together, each filter  
                    // received a handler that is a bridge to the next filter.  
                     
                    return handler.service(request, response);  
                \}  
                finally  
                \{  
                    long elapsed = System.currentTimeMillis() - startTime;

log.info(String.format("Request time: %d ms", elapsed));  
                \}  
            \}  
        \};  
    \}

/\*\*  
     \* This is a contribution to the RequestHandler service configuration. This is how we extend  
     \* Tapestry using the timing filter. A common use for this kind of filter is transaction  
     \* management or security. The @Local annotation selects the desired service by type, but only  
     \* from the same module.  Without @Local, there would be an error due to the other service(s)  
     \* that implement RequestFilter (defined in other modules).  
     \*/  
    public void contributeRequestHandler(OrderedConfiguration<RequestFilter> configuration,  
            @Local  
            RequestFilter filter)  
    \{  
        // Each contribution to an ordered configuration has a name, When necessary, you may  
        // set constraints to precisely control the invocation order of the contributed filter  
        // within the pipeline.  
         
        configuration.add("Timing", filter);  
    \}  
\}