Customizing the Installation

Customizing the Installation ^Locate

There are three ways of customizing your WSO2 SOA Enablement Server for Java installation:

At installation: WSO2 SOA Enablement Server for Java is divided into components, which in turn are contained in a number of JAR files. Usually upon installation you select one of the standard installation scenarios as described in Installation Scenarios. However, you can use the Installation Wizard to select components individually, as described in Custom Installation and Adding Components.
You may also manually add JAR files to the classpath. A classpath builder tool is included in the distribution at WASP_HOME/install-log.html.
One of the more likely custom installations is for a minimal client. The JAR files are listed in WSO2 SOA Enablement Server Client JARs.
After installation, by changing the default settings in serverconf.xml and clientconf.xml. There are only two use cases for altering these files:
- Changing the default options from installation: These default options include XML Protocol, SOAP Binding and Encoding Styles, Attachment Types and XML Schema Validation. See Standard Installation. Instructions are included in comments within the preferences element.
- Changing default transport settings, such as the port number: This is described for each transport in Built-In Transports.
Changing the universal WSO2 SOA Enablement Server for Java properties, as described in WSO2 SOA Enablement Server Configuration.

WS-I Compliance ^Locate

For WS-I compliance, WSO2 SOA Enablement Server for Java must use the wrapped/literal SOAP binding style as default. This means that WSDLs created by SSJ will be wrapped/literal unless specified otherwise by the user. This is the default option in installation (see Standard Installation). This default can be changed after installation, by altering the serverconf.xml and/or clientconf.xml. For more information, please see also SOAP Binding and Encoding Styles.

There are some backward compatibility issues. Previously the SSJ default setting was document/literal. The messages in wrapped/literal look different on the wire. Therefore for backward compatibility it is necessary to keep document/literal WSDLs for services. This is automatic when you use an existing service package (.jar) but may be a problem with services published via the runtime API, because unless the WSDL is set explicitly, SSJ generates one for these services. This can be solved by setting the WSDL explicitly or by changing clients. (Only the .xmap file should be different, the interface should be the same.)

For more information, please see WS-I Profile Compliance.

Using InfoPath with WSO2 SOA Enablement Server for Java ^Locate

In order to use Microsoft InfoPath™ with WSO2 SOA Enablement Server for Java, SSJ's namespace optimization must be turned off. This can be done globally by setting the wasp.soap.caching property to false, as described in WSO2 SOA Enablement Server Configuration.

Namespace optimization can also be turned off on a per-service basis, either through the runtime configuration (see InfoPath in Runtime Configuration) or persistently, by altering the service or client package's deployment descriptor (see Using InfoPath on a Standalone WSO2 SOA Enablement Server).

Running SSJ on an Enforced Address ^Locate

In certain cases the server address must be enforced, such as when:

The server is available at two different address (intranet and extranet) and you need to enforce of of them.
The hostname is not in the DNS records and a numeric IP address must be used to contact it.
The server is started on a machine with multiple network cards (I.E. ethernet and wireless) and one of them must be enforced.

For WSO2 SOA Enablement Server for Java to function correctly in these cases, certain postinstallation steps have to be taken:

	Important
	Do not forget in the Installation Wizard to specify the server address you want to use.

Postinstallation Steps for Enforcing Server Address

Open the configuration files serverconf.xml and clientconf.xml and replace all instances of the string localhost with your server address you need to enforce.
Add/replace the attribute hostName="yourServerAddress" to every HTTP server and HTTPS transport element (transport with the attribute name='http_server") in serverconf.xml.
Add/replace the element <hostName>yourServerAddress</hostName> in the httpsPreferences element of serverconf.xml.
Replace the attribute nonProxyHosts="yourServerAddress" in the httpsPreferences element in serverconf.xml.

	Caution
	Enforcing server address causes the server to listen ONLY on this address. The server cannot be contacted via any other address (localhost, DNS record, ect.).