Modjy servlet parameters are set as <init-param> name-value pairs in the servlet configuration, e.g. in web.xml. The following is the list of parameters that modjy understands.

Note that the values of all modjy initialisation parameters are provided to the application in the WSGI environment, under keys named modjy.param.param-name

Param-name	Value	Description	Default
python.home	A string giving the pathname to the local jython installation.	This is used to indicate to the jython interpreter embedded in modjy where to find the jython installation on the local machine. For more detail on why this property should be set, and how the value is used, see The Jython Registry.	None
python.*	A string giving a value for the relevant jython property.	Any parameter whose name begins with "python." is set in the java.util.Properties used to initialize the jython interpreter inside modjy. For example, values can be set for the following jython parameters: python.path, python.cachedir, etc. For more detail on the jython properties that can be set and what they mean, see The Jython Registry.	None
app_directory	A string giving a path to the directory where application source files are located.	You may wish to keep your application source files outside the modjy servlet/context directory. In that case, you should specify the name of the application directory with this parameter. If you do not specify a value for this parameter, it defaults to the servlet context root directory.	servlet context root
app_filename	A string giving the python filename which contains the callable.	This parameter can be used to change the filename which modjy uses to locate the file which contains the definition of the application callable. For example, this parameter could be set to '__wsgi_app__.py', in which case all application objects will need to be contained in files called '__wsgi_app__.py'. This process of locating callables is described above under Locating the application callable.	application.py
app_callable_name	A string giving the name of python callable which is the WSGI application object.	This parameter tells modjy the name of the application callable object inside the application source file. For more information, see How modjy locates application callable objects.	handler
callable_query_name	A string giving the name of the query parameter from which the callable name for this request should be taken.	This parameter tells modjy to extract the the name of the application callable object from a query parameter in the request URI. For more information, see How modjy locates application callable objects. If the value of this parameter is not changed from its default value of None, callable names will never be extracted from the request query string. Example: if the value of this parameter was set to python_object, then a request for a URI like this /index?python_object=my_callable will tell modjy to look for a callable named my_callable as the application callable.	None
cache_callables	0 == no caching, 1 == cache callables	This parameter tells modjy whether or not it should cache any callables it creates. Caching of callable objects is described under How modjy locates application callable objects.	1
reload_on_mod	0 == do not reload source, 1 == reload when source has been modified	This parameter tells modjy whether or not it should check to see if the python source file containing the application callable has been modified since the last time it was loaded. This is a useful flag for interactive development purposes. However, enabling the flag comes at a cost, which is that modjy must check the modification time of the application source file on every single request. When your application has been fully debugged and running in production, you will probably want to disable this flag. This flag has no effect when the 'cache_callables' parameter is false, i.e. caching is disabled, since a disabled cache means that application source is reloaded for every single request.	0
multithread	0 == access to callables should be synchronized, 1 == application may be called more than once simultaneously from multiple threads.	This parameter has an identical meaning to the WSGI variable 'wsgi.multithread'. If your application object is not thread-safe, you should set this flag to zero, thus ensuring that the application will only ever be called from one thread at a time. This is achieved by exclusively locking and unlocking the application callable before and after each request, so that the application services only one request at a time. This could cause considerable slowdown in a situation where multiple simultaneous calls are received for the same application.	1
log_class	The name of the class which should be used for logging.	If you wish to write your own logger class, create a new class in modjy_log, and change the value of this configuration parameter to its name.	modjy_logger
log_level	debug, info, warn, error, fatal	The level of diagnostic output that should be logged. There is currently only one type of logger supported in modjy: the modjy_logger class. This class provides very basic logging functionality, sending all messages to the J2EE ServletContext.log method.	info
exc_handler	standard, testing	The name of the class which be used to handle exceptions that occur while running applications. The standard handler simply re-raises the exception to be caught by the servlet container. The testing handler is there for two reasons: 1. To communicate with a simple client-side test suite, and 2. To illustrate how to create customised exception handlers.	standard
packages	semicolon-separated list of java package names to be added.	See below under Using external java packages.	None
classdirs	semicolon-separated list of directories containing java packages and classes.	Adds each of the named directories to the list of places checked by jython for java packages and classes.	None
extdirs	semicolon-separated list of directories containing java packages and classes.	Forces jython to scan all .jar and .zip files in each of the named directories for java packages and classes.	None

When using an external java package, it is not sufficient to simply add the package jar to theclasspath. The name of the package must also be declared to jython. This can be done in one of two ways

1. By specifying the java package names in the packages configuration parameter, e.g. org.apache.xerces ; org.apache.xalan.
2. By explicitly adding the package name in your own code, using the sys module, e.g.

   import sys
   sys.add_package('org.apache.xerces')
   sys.add_package('org.apache.xalan')
   

   .

If you don't believe the above, based on your experiences with the org.python.util.PyServlet class, take a look at the source for PyServlet.java: it explicitly adds the necessary javax.servlet packages.