Commented Sample Configuration

This is a commented version of the sample configuration file. The comments will help you to understand the use and function of all the configuration tags and settings.

As in all XML files, the configuration file begins with a header.

<?xml version="1.0" encoding="ISO-8859-1"?>

The configuration of a jwarp application is enclosed by jwarp-tags. The contents are divided into at least two sections.

First, the application section defines the references and main settings of the jwarp applications. Secondly, the context sections can then define the several contexts that are to be loaded.

<jwarp> ...
</jwarp>

 

Application Section




<application  name="JWarp Servlet" debugging="true" type="servlet">



The
serverDat-Section defines the basic servlet settings that are used by
the servlet.



      <serverData>
        <name>localhost</name>
        <port>80</port>
        <contextPath>/</contextPath>
        <scheme>/servlet/JWarpTestServlet</scheme>
        <webService>service.web</webService>
      </serverData>




This
section determines if the automatic web cache should be enabled and,
if so, which cache instance should be used as web cache.



      <cache enabled="true">
        <cacheName>webCache</cacheName>
        <ref path="services.cache"/>
        <property name="includeSession" value="false"/>
        <property name="checkAttribute" value="cache"/>
      </cache>



The
application's final section sets the contexts that should be loaded
by the application. This is also the starting point for loading the
context specification. The location '.' means that the context
configuration is located within the same configuration file.
Otherwise, the location attribute should contain the URL where the
configuration file is located, e.g. file:///c:/jwarp/conf/config.xml .



      <context name="example" location="."/>
      <!-- <context name="context2" location="c:/temp/fileTest.xml"/> -->
  </application>



 



Context
Section



The
context section describes the services to be loaded (including their
load order if necessary). The securityService and logService tags
define the references to the respective services since these services
share specialised common tasks within the framework. Note that the
referenced securityService must implement the
org.jwarp.service.security.ISecurityService interface. Likewise, the
logService has to implement the org.jwarp.service.log.ILogService
interface.



  <context name="example">
      <securityService>service.security</securityService>
               <log name="log.context" />
          ....



Service
Definition



  <service class="org.jwarp.service.security.SecurityService" depRef="sec" name="services.security""security">
        <dependencies>
          ....
        </dependencies>
        <specific>
                <log name="log.context"/>
          ....
        </specific>
  </service>



The
following sections configure the services to be loaded by the
context. At the beginning of each service , each service dependency
can be defined in its loading order compared to the other services
within the dependency section. 



The
specific section depends entirely on its implementation in the
service. The actual class loaded as service is determined by the
class-attribute in the service header. 



Security
Service Configuration



The
tag <impl-class> specifies which class should be loaded and who
implements the ISecurity interface. The <secFile>
tag contains a specific parameter for the FileSecurity
implementation. It determines to which file the settings should be
stored to (and loaded from if already existing).



      <service class="org.jwarp.service.security.SecurityService" depRef="sec" name="services.securityy">
        <dependencies>
        </dependencies>
        <specific>
          <impl-class>org.jwarp.service.security.FileSecurity</impl-class>
          <secFile>E:/java/projekte/JWarp/conf/Security.dat</secFile>
        </specific>
      </service>



Log
Service Configuration 



We
adapted the whole JWarp implementation to use apache's log4J log
implementation. As known from our previous log implementation, which
is still available but not supported anymore, several logs can be
defined. For details please go to the Apache
site. For each service the log can be
specified by an optional log tag within the specific service config.
This tag is then read (and thus only then useful) when the service
implementation class reads this tag and interpretes and initialises
the given name as a log4J category. All contributed services within
the JWarp framework do this by inheriting from the
org.jwarp.service.AService class. If no log tag is
provided the service class is taken as log category, e.g.
org.jwarp.service.security.SecurityService. The log
configuration is read in by the org.apache.log4J.xml.DOMConfigurator.
You can specify here the log4J configuration file that should be read
(cf. first example) or add the log4J configuration directly (cf.
second example).



<!-- First Example: Not yet implemented -->

<!-- Second Example: Integrate Config into JWarp Config File -->
<service class="org.jwarp.service.log.Log4JService" name="services.log4J">
        <dependencies />
        <specific>
          <!--<configFile>E:\Projects\JWarp\core\conf\log4JSampleConfig.xml</configFile>-->
          <log4j:configuration debug="true" xmlns:log4j='http://jakarta.apache.org/log4j/' >
                <appender name="OUT" class="org.apache.log4j.ConsoleAppender">
                   <layout class="org.apache.log4j.PatternLayout">
                      <param name="ConversionPattern"
                             value="%p - %m%n"/>
                   </layout>
                </appender>

                <appender name="STDOUT" class="org.apache.log4j.FileAppender">
                   <param name="File" value="System.out" />
                   <layout class="org.apache.log4j.PatternLayout">
                     <param name="ConversionPattern"
                            value="%d %-5p [%t] %C{2} (%F:%L) - %m%n"/>
                   </layout>
                </appender>

                <!-- /services/log/log4J -->
                <category name="org.jwarp.service" class="org.apache.log4j.Category">
                  <priority value="info" />
                  <appender-ref ref="STDOUT" />
                </category>

                <root>
                   <priority value="info" />
                   <appender-ref ref="STDOUT" />
                </root>
        </log4j:configuration>
        </specific>
      </service>

<service class="org.jwarp.service.cache.CacheService" name="services.cache">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <cache name="webCache">
            <minAccess>2</minAccess>
            <maxTime>600000</maxTime>
            <updateTime>120000</updateTime>
            <maxElements>5000</maxElements>
          </cache>
          <cache name="WFJobCache">
            <minAccess>-1</minAccess>
            <maxTime>600000</maxTime>
            <updateTime>120000</updateTime>
            <maxElements>5000</maxElements>
          </cache>
        </specific>
      </service>



Configuration
Service Configuration



Each
configuration is given a name under which it can be referenced within
the framework. The checkmodification setting tells the manager to
examine if the configuration has checked on the disc and hence to
reload it if necessary.



<service class="org.jwarp.service.configuration.ConfigurationService" name="services.config">
        <dependencies />
        <specific>
            <configuration name="basic" checkmodification="true">
              <file>j:/projekte/JWarp/conf/config1.xml</file>
            </configuration>

            <configuration name="personal" checkmodification="true">
              <file>j:/projekte/JWarp/conf/config1.xml</file>
            </configuration>
        </specific>
      </service>



Persistence
Service Configuration



The
persistence service in the form here is based on the org.exolab.castor persistence engine. Though the
persistence settings in the forthcoming JWarp persistence service
will be quite similar there will be some differences. The only
parameter is the name of the persistence store and the location of
the castor persistence main configuration file.



      <service class="org.jwarp.service.persistence.PersistenceService" name="services.persistence">
        <dependencies>
          <service name="services.security"/>
          <service name="services.log"/>
          <service name="services.dbpool"/>
        </dependencies>
        <specific>
          <store name="JWarp" url="file:///E:/java/projekte/JWarp/conf/db/JWarpDB.xml"/>
        </specific>
      </service>




Connection
Pool Service Configuration



The
connection pool service is a JDBC connection pool manager. Within the
drivers section you ensure which drivers the system is trying to
load. If the loading of a driver failed, a detailed message will be
logged. Within the pools section you can configure an arbitrary
number of pools using connection urls for any loaded drivers. Further
settings are:



    
   
  • initConns - The initial number of open connections when
   creating the pool
    • 
   
   
  • maxConns - The maximum number of connections created by the
   pool
    • 
   
   
  • maxFreeConns - The minimal number of unused connections that
   trigger the closing of unused connections.
    • 
   
   
  • releaseConns - The number of connections that are closed when
   an update was triggered and too many connections were unused.
    • 
   
   
  • timeout - Timeout in seconds after which the creation of a
   new connection is aborted. This is necessary since, under certain
   circumstances, the Oracle driver hangs and does not return any
   more from the call.
    • 
   
   
  • initStatement - This statement is executed on each newly created
   connection. For example if you want to ensure a date-month-year
   order on SQL Server you can send the query 'dateformat dmy'
    • 




 



<service class="org.jwarp.service.connectionpool.PoolService" name="services.dbpool">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <updateTime>30000</updateTime>
        <  drivers>
			 <driver>org.enhydra.instantdb.jdbc.idbDriver</driver>
              <driver>com.oracle.JdbcDriver</driver>
              <driver>com.inzoom.jdbcado.Driver</driver>
          </drivers>
          <pools>
            <connectionPool name="defaultPool" logTarget="System.err" logLevel="error">
              <url>jdbc:idb:E:/java/projekte/JWarp/idb/sample1.prp</url>
              <uid>fritz</uid>
              <pwd>guck</pwd>
              <initConns>5</initConns>
              <maxConns>100</maxConns>
              <maxFreeConns>25</maxFreeConns>
              <releaseConns>20</releaseConns>
              <timeout>120</timeout>
              <initStatement>SET @@DATEFORMAT DDMMYYYY</initStatement>
            </connectionPool>
            <connectionPool name="JWeb" logTarget="System.err" logLevel="error">
              <url>jdbc:izmado:PROVIDER=SQLOLEDB.1;PASSWORD=andorra;PERSIST SECURITY INFO=TRUE;USER ID=SA;INITIAL CATALOG=JWeb;DATA SOURCE=redbean</url>
              <uid>sa</uid>
              <pwd>andorra</pwd>
              <initConns>5</initConns>
              <maxConns>20</maxConns>
              <maxFreeConns>5</maxFreeConns>
              <releaseConns>3</releaseConns>
              <timeout>120</timeout>
              <initStatement>SET @@DATEFORMAT DDMMYYYY</initStatement>
            </connectionPool>
          </pools>
        </specific>
      </service>




ID
Service Configuration



The
ID service is a simple identifier generator service. Following you
see a configuration where several instances of the same service class
are loaded under two different names. Basically you can do that with
all services except the security service. In the case of the security
service you can declare and load several services. But there is only
one service which is actually loaded as the context's security
service which is also responsible for handling the loggings to the
context (in fact the first loaded security service will be the active
one). Here is an example for a logging configuration where no log
service is referenced. Instead of this, a new private log instance is
created and used for logging: 



      <service class="org.jwarp.service.id.IdService"  name="services.id.id1">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <enabled>true</enabled>
        </specific>
      </service>

      <service class="org.jwarp.service.id.IdService" name="services.id.id2">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <enabled>true</enabled>
        </specific>
      </service>



Localization
Service Configuration



The
localization service allows you to load different localization
schemes. Accordingly, a default scheme is set as shown below:




      <service class="org.jwarp.service.localization.LocalizationService"  name="services.localization">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <default>
            <language>GER</language>
            <country>SUI</country>
          </default>
        </specific>
      </service>



Mail
Service Configuration



The
mail service is very simple to configure. The only setting is a valid
SMTP host entry or IP where the mails should be sent to. If you are
interested in how you can send an email with this service, have a
look at the org.jwarp.service.mail.IMailService interface. 



      <service class="org.jwarp.service.mail.MailService"  name="services.email">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <smtpHost>smtp.swissonline.ch</smtpHost>
        </specific>
      </service>



Threadpool
Service Configuration



The
threadpool service allows you to define several independent thread
pools. For each pool you can define the initial and the maximal
number of running threads. Each threadpool also has its own work
queue which takes objects that implement the java.lang.Runnable interface. 



      <service class="org.jwarp.service.threadpool.ThreadPoolService"  name="services.threadpool">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <pool name="test1">
            <startSize>1</startSize>
            <maxSize>2</maxSize>
          </pool>
          <pool name="test2">
            <startSize>4</startSize>
            <maxSize>8</maxSize>
          </pool>
        </specific>
      </service>



Work
Service Configuration



The
work service is a service that, additionally to a threadpool service,
supports persistency of the jobs. This is made possible through
encapsulating the executing code within classes that implement the org.jwarp.service.work.ITool interface. it is shown below how and which tools
are loaded. The work manager stores the state of each running job as
well as its time of creation and the parameters (as strings) to a
database. That state of all executed as well as lso non-executed jobs
is stored every time. By adding jobs to the job list, they can be
started automatically each time the work manager is loaded and
started. 



      <service class="org.jwarp.service.work.WorkService"  name="services.work">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
          <service name="services.cache"/>
        </dependencies>
        <specific>
          <property name="anonymousJobsAllowed" value="true"/>
          <property name="anonymousHighPriorityJobsAllowed" value="true"/>
            <toolManager class="org.jwarp.service.work.ToolManager">
              <tools>
                <tool class="org.jwarp.tools.SampleTool">
                </tool>
              </tools>
            </toolManager>

            <persistence>
              <ref path="services.persistence.JWebDB"/>
            </persistence>
            <objectpool>
              <ref path="services.objectpool.ToolJob"/>
            </objectpool>

            <jobs>
              <job tool="Email" type="normal">
                <property name="to" value="tresch@orcasys.ch"/>
                <property name="subject" value="Service started."/>
              </job>
            </jobs>
        </specific>
      </service>



Web
Service Configuration



The
web service is one of the most complex service implementations in the
framework since it encorporates the environment for a whole web
application. The settings have the following meanings:



    
   
  • sessionInit - Class to be loaded as session initializer. The
   session initializer is called whenever a web request is
   encountered which is not attached to a session.
   The <sessionInit> tag can create and
   initialize a session, or it may remain empty (default case).
    • 
   
   
  • requestInit - Class to be loaded as request initializer. This
   implementation class is called whenever a request is made.
    • 
   
   
  • dispatcher - Class to be loaded in order to handle the
   effective request. A standard JWarp application has an action
   parameter that is dispatched to the action fthat eventually
   handles the request.
    • 
   
   
  • actions - List of the web actions to be loaded by the
   dispatcher. Actions can have pre-conditions to be verified before
   the action's execution body is called. The action sees if such a
   pre-condition check failed and subsequently undertakes whatever is
   necessary. Since there are pre-conditions, there are also
   post-conditions. Failed post-conditions typically lead to a
   redirection onto an error page and should only occur during action
   development.
    • 
   
   
  • forwarders - Each forwarder implements a specific kind of
   forward to the request. HTML-, JSP- and XSL-forwarders are used to
   create the output presentation. Servlet-forwarders forward to
   another action or servlet implementation.
    • 




      <service class="org.jwarp.service.web.WebService"  name="services.web">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
          <service name="services.cache"/>
        </dependencies>
        <specific>
          <sessionInit class="org.jwarp.service.web.init.SessionInit"/>
          <requestInit class="org.jwarp.service.web.init.RequestInit"/>
          <dispatcher class="org.jwarp.service.web.dispatch.ActionDispatchAlg">
            <decodeAlg class=""/>
            <actions>
              <action name="printrequest" class="org.jwarp.service.web.dispatch.PrintRequest">
                <preCondition class="org.jwarp.service.web.dispatch.ComplexCondition1"/>
                <preCondition class="org.jwarp.service.web.dispatch.ComplexCondition2"/>
                <preCondition class="org.jwarp.service.web.dispatch.SimpleCondition">
                  <type>param</type>
                  <field>action</field>
                  <class>org.jwarp.service.param.NotEmptyValidator</class>
                </preCondition>

                <postCondition class="org.jwarp.service.web.dispatch.ComplexCondition3"/>
              </action>
              <action name="printrefs" class="org.jwarp.service.web.dispatch.PrintRefs"/>
            </actions>
          </dispatcher>

          <forward id="html" class="org.jwarp.service.web.forward.ForwardHtmlAlg">
            <historyNameID>__HISTORY</historyNameID>
            <baseDir>file:///e:/java/projekte/JWarp/html</baseDir>
          </forward>
          <forward id="jsp" class="org.jwarp.service.web.forward.ForwardJspAlg">
            <historyNameID>__HISTORY</historyNameID>
            <baseDir>c:/</baseDir>
          </forward>
          <forward id="xsl" class="org.jwarp.service.web.forward.ForwardXSLAlg">
            <historyNameID>__HISTORY</historyNameID>
            <baseDir>c:/</baseDir>
          </forward>
        </specific>
      </service>



Param
Service Configuration



The
parameter service is used to implement parameter and request
validations. Validators implement the checking of single
objects/values whereas validations take parameters of a whole
request. Both can be defined within and called through the service
interface:



      <service class="org.jwarp.service.param.ParamService"  name="services.param">
        <dependencies>
          <service name="services.log"/>
          <service name="services.security"/>
        </dependencies>
        <specific>
          <validators>
            <validator name="Name" class="org.jwarp.service.param.StringValidator" min="1" max="255"/>
            <validator name="Date" class="org.jwarp.service.param.DateTimeValidator" dateFormat="dd.MM.yyyy"/>
            <validator name="Email" class="org.jwarp.service.param.EmailValidator"/>
            <validator name="CreditCard" class="org.jwarp.service.param.CreditCardValidator"/>
            <validator name="Boolean" class="org.jwarp.service.param.BooleanValidator" trueString="true" falseString="false"/>
            <validator name="Number" class="org.jwarp.service.param.NumberValidator" min="-1" max="100" type="int"/>
          </validators>
          <validations>
            <validation name="TestValidation" class="org.jwarp.service.param.MutableValidation">
              <params>
                <param name="TestParameter" class="org.jwarp.service.param.ParameterDescription">
                  <required>true</required>
                  <mayBeEmpty>true</mayBeEmpty>
                  <contentValidator>
                    <validator name="Name" class="org.jwarp.service.param.StringValidator" min="1" max="255"/>
                  </contentValidator>
                </param>
                <param name="TestParameter2" class="org.jwarp.service.param.ParameterDescription">
                  <required>true</required>
                  <mayBeEmpty>true</mayBeEmpty>
                  <contentValidator>
                    <validator ref="Name"/>
                  </contentValidator>
                </param>
              </params>
            </validation>
          </validations>
        </specific>
      </service>





The
End



There
is only one thing missing: the closing tags.



</context>
</jwarp>