Package org.apache.wicket.mock

Class MockApplication

    • Method Detail

      • getHomePage

        public Class<? extends Page> getHomePage()
        Description copied from class: Application
        Application subclasses must specify a home page class by implementing this abstract method.
        Specified by:
        getHomePage in class Application
        Returns:
        Home page class for this application

      • getConfigurationType

        public RuntimeConfigurationType getConfigurationType()
        Description copied from class: WebApplication
        Gets the configuration mode to use for configuring the app, either RuntimeConfigurationType.DEVELOPMENT or RuntimeConfigurationType.DEPLOYMENT.

        The configuration type. Must currently be either DEVELOPMENT or DEPLOYMENT. Currently, if the configuration type is DEVELOPMENT, resources are polled for changes, component usage is checked, wicket tags are not stripped from output and a detailed exception page is used. If the type is DEPLOYMENT, component usage is not checked, wicket tags are stripped from output and a non-detailed exception page is used to display errors.

        Note that you should not run Wicket in DEVELOPMENT mode on production servers - the various debugging checks and resource polling is inefficient and may leak resources, particularly on webapp redeploy.

        To change the deployment mode, add the following to your web.xml, inside your mapping (or mapping if you're using 1.3.x): 

         <init-param>
             <param-name>configuration</param-name>
             <param-value>deployment</param-value>
 </init-param>

        You can alternatively set this as a <context-param> on the whole context.

        Another option is to set the "wicket.configuration" system property to either "deployment" or "development". The value is not case-sensitive.

        The system property is checked first, allowing you to add a web.xml param for deployment, and a command-line override when you want to run in development mode during development.

        You may also override Application.getConfigurationType() to provide your own custom switch, in which case none of the above logic is used.

        IMPORTANT NOTE

        THIS METHOD IS CALLED OFTEN FROM MANY DIFFERENT POINTS IN CODE, INCLUDING DURING THE RENDER PROCESS, THEREFORE THE IMPLEMENTATION SHOULD BE FAST - PREFERRABLY USING A FAST-TO-RETRIEVE CACHED VALUE
        Overrides:
        getConfigurationType in class WebApplication
        Returns:
        configuration

      • internalInit

        protected void internalInit()
        Description copied from class: WebApplication
        THIS METHOD IS NOT PART OF THE WICKET PUBLIC API. DO NOT CALL IT. Internal initialization. First determine the deployment mode. First check the system property -Dwicket.configuration. If it does not exist check the servlet init parameter ( <init-param><param-name>configuration</param-name>). If not found check the servlet context init parameter <context-param><param-name6gt;configuration</param-name>). If the parameter is "development" (which is default), settings appropriate for development are set. If it's "deployment" , deployment settings are used. If development is specified and a "sourceFolder" init parameter is also set, then resources in that folder will be polled for changes.
        Overrides:
        internalInit in class WebApplication