webspherewebxml

This class is responsible for generating the WebSphere specific deployment descriptors. It generates ibm-web-bnd.xmi and ibm-web-ext.xmi . The id attributes of various elements in the deployment descriptors and the web.xml file must be applied as a seperate step with the task <WebSphereWebXmlIds/> after the deployement descriptors have been generated.

ibm-web-bnd.xmi is responsible for:

  • Binding EJB references in web.xml to a JNDI name in the local namespace
  • Binding resource references in web.xml to a JNDI name in the local namespace

ibm-web-ext.xmi contains IBM specific extensions to the web.xml file and is responsible for specifying the following:

  • A Reload Interval . Every 'reload interval' seconds, the web application's files are checked and reloaded if they have been modified
  • A flag specifying whether Reloading is enabled
  • The URI of an error page
  • Enabling or disabling File Serving . If enabled, the application is allowed to serve static file types such as HTML and GIF. File serving can be disabled if, for example, the application contains only dynamic components. The default value is true.
  • Enabling or disabling Directory Browsing . If enabled, the application may browse disk directories. Directory browsing can be disabled if, for example, you want to protect data. The default value is true.
  • Enabling or disabling the serving of servlets by their classname. The default value is true
  • Association of responses with a given MIME type to a given target (servlet?); the idea being to either transform or filter a response.
  • Page List configuration. Page lists allow servlets, which have been configured to utilise page list support, to refer to resources by names which map onto URIs.
  • JSP Attribute configuration. To quote the IBM documentation "JSP attributes are used by the servlet that implements JSP processing behavior. ". No doubt IBM have lots of undocumented parameters to the JSP processing engine that can passed using this feature.
  • File Serving Attribute configuration. To quote the IBM documentation "File-serving attributes are used by the servlet that implements file-serving behavior. ". Another means to pass undocumented parameters, this time to the file serving servlet.
  • Invoker Attribute configuration. To quote the IBM documentation "Invoker attributes are used by the servlet that implements the invocation behavior. ". (I wonder if anyone at IBM knows what can be configured here)
  • Servlet Cache configuration.
  • An Additional ClassPath that will be used to reference resources outside of those specified in the archive.

    The following help is taken from the IBM documentation:

    Specify the values relative to the root of the EAR file and separate the values with spaces. Absolute values that reference files or directories on the hard drive are ignored. To specify classes that are not in JAR files but are in the root of the EAR file, use a period and forward slash (./). Consider the following example directory structure in which the file myapp.ear contains a Web module named mywebapp.war. Additional classes reside in class1.jar and class2.zip. A class named xyz.class is not packaged in a JAR file but is in the root of the EAR file.

    myapp.ear/mywebapp.war

    myapp.ear/class1.jar

    myapp.ear/class2.zip

    myapp.ear/xyz.class

    Specify class1.jar class2.zip ./ as the value of the Additional classpath property. (Name only the directory for .class files.)

Implementing Class

xdoclet.modules.ibm.websphere.web.WebSphereWebXmlSubTask

Attributes

AttributeDescriptionRequired
virtualHostNameSets the virtual host name configuration parameter. No.
reloadInterval No.
reloadingEnabledWe need an implementation of this method else the framework does not see 'reloadingEnabled' as a java bean property (ie. read-only properties don't seem to work). No.
defaultErrorPage No.
fileServingEnabled No.
directoryBrowsingEnabled No.
serveServletsByClassnameEnabled No.
additionalClassPath No.
useIdsIf this attribute is set to true, XDoclet will generate id attributes in the XML document. Note that this is only available in some subtasks. No. Default is "false"
xmlencodingThe encoding of the produced xml file. If your XML file uses international characters, you might want to set this to "ISO-8859-1". No, default is "UTF-8"
schemaThe XML Schema to which the generated document should conform. No.
validateXMLIf this is set to true, the generated XML will be validated against its DTD or XML Schema. No, default is false.
acceptInterfacesIndicates whether or not to generate for interfaces. No, default is "true"
acceptAbstractClassesIndicates whether or not to generate for abstract classes. No, default is "true"
packageSubstitutionsSets the PackageSubstitutions attribute of the TemplateSubTask object No.
packageSubstitutionInheritanceSupportedIndicates whether or not package substitution should be inherited No, default is "true"
prefixWithPackageStructureIndicates whether or not to prefix with package structure. No, default is "true"
destinationFileThe destination file name. If a {0} is found it's assumed that a per class output generation is needed, so {0} is substituted with class name; otherwise a single file is generated with the specified name. No, default is determined by this task.
templateFileSets the name of the template file to use for generation No, default is determined by this task.
havingClassTagSets the HavingClassTag attribute of the TemplateSubTask object No.
ofType No.
subTaskNameSets an optional name for the subtask that will be seen in XDoclet's debug messages. No.
destDirSets the directory where the generated file(s) will be written. No.
mergeDirSpecifies the location of the merge directory. This is where XDoclet will look for merge files. No.

Nested Elements

ElementDescription
configParamSpecifies a configuration parameter for the subtask.
ofType
packageSubstitutionSubstitutes the package of the generated files.