[jboss-cvs] JBossAS SVN: r104700 - projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue May 11 21:11:23 EDT 2010
Author: laubai
Date: 2010-05-11 21:11:22 -0400 (Tue, 11 May 2010)
New Revision: 104700
Modified:
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Alternative_DBs.xml
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Reference_Introduction.xml
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Security_On_JBOSS.xml
projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Web_Services.xml
Log:
Corrected tagging issues and updated pot file.
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Alternative_DBs.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Alternative_DBs.xml 2010-05-12 00:30:26 UTC (rev 104699)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Alternative_DBs.xml 2010-05-12 01:11:22 UTC (rev 104700)
@@ -34,41 +34,42 @@
<section><title>Special notes on Sybase</title>
<para>
Some of the services in JBoss uses null values for the default tables that are created.
- Sybase Adaptive Server should be configured to allow nulls by default.
+ Sybase Adaptive Server should be configured to allow nulls by default.</para>
<screen><command>sp_dboption db_name, "allow nulls by default", true</command></screen>
-
+ <para>
Refer the sybase manuals for more options.
</para>
<formalpara><title>Enable JAVA services</title>
<para>
To use any java service like JMS, CMP, timers etc. configured with Sybase, java should be enabled on Sybase Adaptive Server.
- To do this use:
+ To do this use:</para>
+ </formalpara>
<screen><command>sp_configure "enable java",1</command></screen>
+ <para>
+ Refer to the sybase manuals for more information.
+ </para>
- Refer the sybase manuals for more information.
- </para>
- </formalpara>
<para>
- If java is not enabled you might see this exception being thrown when you try to use any of the above services.
+ If java is not enabled you might see this exception being thrown when you try to use any of the above services.</para>
<screen>com.sybase.jdbc2.jdbc.SybSQLException: Cannot run this command because Java services are not enabled. A user with System Administrator (SA) role must reconfigure the system to enable Java</screen>
- </para>
+
<formalpara><title>CMP Configuration</title>
<para>
To use Container Managed Persistence for user defined Java objects with Sybase Adaptive Server Enterprise the java classes
should be installed in the database.
- The system table 'sysxtypes' contains one row for each extended, Java-SQL datatype.This table is only used for
+ The system table 'sysxtypes' contains one row for each extended, Java-SQL datatype. This table is only used for
Adaptive Servers enabled for Java.
- Install java classes using the installjava program.
+ Install java classes using the installjava program.</para>
+ </formalpara>
-
<screen><command>installjava -f <jar-file-name> -S<sybase-server> -U<super-user> -P<super-pass> -D<db-name></command></screen>
-
+ <para>
Refer the installjava manual in Sybase for more options.
</para>
- </formalpara>
+
<note><title>Installing Java Classes</title>
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-05-12 00:30:26 UTC (rev 104699)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-05-12 01:11:22 UTC (rev 104700)
@@ -355,7 +355,7 @@
down_thread="false" up_thread="false"/>
</programlisting>
<para>
- Here is another example PING configuration for contacting a Gossip Router.
+ Here is another example PING configuration for contacting a Gossip Router.</para>
<programlisting><![CDATA[
<PING gossip_host="localhost"
gossip_port="1234"
@@ -364,7 +364,6 @@
down_thread="false" up_thread="false"/>]]>
</programlisting>
- </para>
<para>The available attributes in the <literal>PING</literal> element are listed below.</para>
@@ -1063,39 +1062,38 @@
<itemizedlist>
<listitem>
<para>
- Binding JGroups to the same interface as other services. Simple, just use -b:
+ Binding JGroups to the same interface as other services. Simple, just use -b:</para>
<screen>./run.sh -b 192.168.1.100 -c all</screen>
- </para>
+
</listitem>
<listitem>
<para>
- Binding services (e.g., JBoss Web) to one interface, but use a different one for JGroups:
+ Binding services (e.g., JBoss Web) to one interface, but use a different one for JGroups:</para>
<screen>./run.sh -b 10.0.0.100 -Djgroups.bind_addr=192.168.1.100 -c all</screen>
-
+ <para>
Specifically setting the system property overrides the -b value. This is a common usage pattern; put client traffic on one network, with intra-cluster traffic on another.
</para>
</listitem>
<listitem>
<para>
-
- Binding services (e.g., JBoss Web) to all interfaces. This can be done like this:
+ Binding services (e.g., JBoss Web) to all interfaces. This can be done like this:</para>
<screen>./run.sh -b 0.0.0.0 -c all</screen>
+ <para>
However, doing this will not cause JGroups to bind to all interfaces! Instead , JGroups will bind to the machine's default interface. See the Transport Protocols section for how to tell JGroups to receive or send on all interfaces, if that is what you really want.
</para>
</listitem>
<listitem>
<para>
- Binding services (e.g., JBoss Web) to all interfaces, but specify the JGroups interface:
+ Binding services (e.g., JBoss Web) to all interfaces, but specify the JGroups interface:</para>
<screen>./run.sh -b 0.0.0.0 -Djgroups.bind_addr=192.168.1.100 -c all</screen>
-
+ <para>
Again, specifically setting the system property overrides the -b value.
</para>
</listitem>
<listitem>
<para>
- Using different interfaces for different channels:
+ Using different interfaces for different channels:</para>
<screen>./run.sh -b 10.0.0.100 -Djgroups.ignore.bind_addr=true -c all</screen>
- </para>
</listitem>
</itemizedlist>
@@ -1134,19 +1132,21 @@
The group name for a JGroups channel is configured via the service that starts the channel. Unfortunately, different services use different attribute names for configuring this. For HAPartition and related services configured in the deploy/cluster-service.xml file, this is configured via a PartitionName attribute. For JBoss Cache services, the name of the attribute is ClusterName.
</para>
<para>
- Starting with JBoss AS 4.0.4, for the HAPartition and all the standard JBoss Cache services, we make it easy for you to create unique groups names simply by using the -g (a.k.a. –partition) switch when starting JBoss:
+ Starting with JBoss AS 4.0.4, for the HAPartition and all the standard JBoss Cache services, we make it easy for you to create unique groups names simply by using the -g (a.k.a. –partition) switch when starting JBoss:</para>
<screen>./run.sh -g QAPartition -b 192.168.1.100 -c all</screen>
- This switch sets the jboss.partition.name system property, which is used as a component in the configuration of the group name in all the standard clustering configuration files. For example,
+ <para>
+ This switch sets the jboss.partition.name system property, which is used as a component in the configuration of the group name in all the standard clustering configuration files. For example: </para>
<screen><![CDATA[<attribute name="ClusterName">Tomcat-${jboss.partition.name:Cluster}</attribute>]]></screen>
- </para>
+
</section>
<section><title>Changing the multicast address and port</title>
<para>
- The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services.
+ The -u (a.k.a. --udp) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services.</para>
<screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c all]]></screen>
+ <para>
This switch sets the jboss.partition.udpGroup system property, which you can see referenced in all of the standard protocol stack configs in JBoss AS:
</para>
@@ -1177,15 +1177,15 @@
<para><emphasis>Nodes do not form a cluster</emphasis></para>
<para>
- Make sure your machine is set up correctly for IP multicast. There are 2 test programs that can be used to detect this: McastReceiverTest and McastSenderTest. Go to the <literal>$JBOSS_HOME/server/all/lib</literal> directory and start McastReceiverTest, for example:
+ Make sure your machine is set up correctly for IP multicast. There are 2 test programs that can be used to detect this: McastReceiverTest and McastSenderTest. Go to the <literal>$JBOSS_HOME/server/all/lib</literal> directory and start McastReceiverTest, for example:</para>
<screen>java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr 224.10.10.10 -port 5555 </screen>
-</para>
+
<para>
-Then in another window start <literal>McastSenderTest</literal>:
+Then in another window start <literal>McastSenderTest</literal>:</para>
<screen>java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr 224.10.10.10 -port 5555</screen>
-</para>
+
<para>
If you want to bind to a specific network interface card (NIC), use <literal>-bind_addr 192.168.0.2</literal>, where 192.168.0.2 is the IP address of the NIC to which you want to bind. Use this parameter in both the sender and the receiver.
</para>
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Reference_Introduction.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Reference_Introduction.xml 2010-05-12 00:30:26 UTC (rev 104699)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Reference_Introduction.xml 2010-05-12 01:11:22 UTC (rev 104700)
@@ -3167,7 +3167,6 @@
<para>
There is nothing manifestly different about this version of the XMBean at this point because we have done nothing to test that changes to attribute value are actually persisted. Perform this test by running example xmbean2a several times:
</para>
- <para>
<programlisting>[examples] ant -Dchap=jmx -Dex=xmbean2a run-example
...
[java] InitialValues.length=2
@@ -3179,8 +3178,6 @@
[java] key=key10, value=value10
[java] key=key2, value=value2
</programlisting>
- </para>
- <para>
<programlisting>[examples] ant -Dchap=jmx -Dex=xmbean2a run-example
...
[java] InitialValues.length=6
@@ -3188,7 +3185,6 @@
[java] key=key2, value=value2
[java] key=key3, value=value3
</programlisting>
- </para>
<para>
The <literal>org.jboss.book.jmx.xmbean.TestXMBeanRestart</literal> used in this example obtains the current <literal>InitialValues</literal> attribute setting, and then adds another key/value pair to it. The client code is shown below.
</para>
@@ -4506,7 +4502,6 @@
<para>
Either create or extend an existing MBean to support an invoke operation. Its signature is <literal>Object invoke(Invocation invocation) throws Exception</literal>, and the steps it performs are as shown here for the <literal>SRPRemoteServerInterface</literal> interface. Note that this uses the <literal>marshalledInvocationMapping</literal> from step 1 to map from the <literal>Long</literal> method hashes in the <literal>MarshalledInvocation</literal> to the <literal>Method</literal> for the interface.
</para>
- <para>
<programlisting>import org.jboss.invocation.Invocation;
import org.jboss.invocation.MarshalledInvocation;
@@ -4538,7 +4533,6 @@
return value;
}
</programlisting>
- </para>
</listitem>
<listitem>
<para>
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Security_On_JBOSS.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Security_On_JBOSS.xml 2010-05-12 00:30:26 UTC (rev 104699)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/J2EE_Security_On_JBOSS.xml 2010-05-12 01:11:22 UTC (rev 104700)
@@ -2991,7 +2991,7 @@
<section id="Adding_SSL_to_EJB3_Generating_the_keystore_and_truststore">
<title>Generating the keystore and truststore</title>
<para>
- For SSL to work you need to create a public/private key pair, which will be stored in a keystore. Generate this using the <literal>genkey</literal> command that comes with the JDK.
+ For SSL to work you need to create a public/private key pair, which will be stored in a keystore. Generate this using the <literal>genkey</literal> command that comes with the JDK.</para>
<programlisting>
$cd $JBOSS_HOME/server/production/conf/
$keytool -genkey -alias ejb3-ssl -keypass opensource -keystore localhost.keystore
@@ -3010,19 +3010,19 @@
[Unknown]:
Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct?
[no]: yes
-</programlisting>
+</programlisting>
+ <para>
where <literal>alias</literal> is the name ("ejb2-ssl") of the key pair within the keystore. <literal>keypass</literal> is the password ("opensource") for the keystore, and <literal>keystore</literal> specifies the location ("localhost.keystore") of the keystore to create/add to.
</para>
<para>
- Since you have not signed our certificate through any certification authoritiy, you also need to create a truststore for the client, explicitly saying that you trust the certificate you just created. The first step is to export the certificate using the JDK keytool:
+ Since you have not signed our certificate through any certification authoritiy, you also need to create a truststore for the client, explicitly saying that you trust the certificate you just created. The first step is to export the certificate using the JDK keytool:</para>
<programlisting>
$ keytool -export -alias ejb3-ssl -file mycert.cer -keystore localhost.keystore
Enter keystore password: opensource
Certificate stored in file <mycert.cer>
</programlisting>
- </para>
<para>
- Then you need to create the truststore if it does not exist and import the certificate into the trueststore:
+ Then you need to create the truststore if it does not exist and import the certificate into the trueststore:</para>
<programlisting>
$ keytool -import -alias ejb3-ssl -file mycert.cer -keystore localhost.truststore
Enter keystore password: opensource
@@ -3036,12 +3036,11 @@
Trust this certificate? [no]: yes
Certificate was added to keystore
</programlisting>
- </para>
</section>
<section>
<title id="Adding_SSL_to_EJB3_Setting_up_the_SSL_transport">Setting up the SSL transport</title>
<para>
- The simplest way to define an SSL transport is to define a new Remoting connector using the <literal>sslsocket</literal> protocol as follows. This transport will listen on port 3843:
+ The simplest way to define an SSL transport is to define a new Remoting connector using the <literal>sslsocket</literal> protocol as follows. This transport will listen on port 3843:</para>
<programlisting>
<mbean code="org.jboss.remoting.transport.Connector"
xmbean-dd="org/jboss/remoting/transport/Connector.xml"
@@ -3057,20 +3056,18 @@
</attribute>
</mbean>
</programlisting>
- </para>
<para>
- Now you need to tell JBoss Remoting where to find the keystore to be used for SSl and its password. This is done using <literal>javax.net.ssl.keyStore</literal> and <literal>javax.net.ssl.keyStorePassword=opensource</literal> system properties when starting JBoss, as the following example shows:
+ Now you need to tell JBoss Remoting where to find the keystore to be used for SSl and its password. This is done using <literal>javax.net.ssl.keyStore</literal> and <literal>javax.net.ssl.keyStorePassword=opensource</literal> system properties when starting JBoss, as the following example shows:</para>
<programlisting>
$cd $JBOSS_HOME/bin
$ run -Djavax.net.ssl.keyStore=../server/production/conf/localhost.keystore
-Djavax.net.ssl.keyStorePassword=opensource
</programlisting>
- </para>
</section>
<section id="Adding_SSL_to_EJB3_Configuring_your_beans">
<title>Configuring your beans to use the SSL transport</title>
<para>
- By default all the beans will use the default connector on <literal>socket://0.0.0.0:3873</literal>. By using the <literal>@org.jboss.annotation.ejb.RemoteBinding</literal> annotation you can have the bean invokable via SSL.
+ By default all the beans will use the default connector on <literal>socket://0.0.0.0:3873</literal>. By using the <literal>@org.jboss.annotation.ejb.RemoteBinding</literal> annotation you can have the bean invokable via SSL.</para>
<programlisting>
@RemoteBinding(clientBindUrl="sslsocket://0.0.0.0:3843", jndiBinding="StatefulSSL"),
@Remote(BusinessInterface.class)
@@ -3079,12 +3076,11 @@
...
}
</programlisting>
- </para>
<para>
This bean will be bound under the JNDI name <literal>StatefulSSL</literal> and the proxy implementing the remote interface returned to the client will communicate with the server via SSL.
</para>
<para>
- You can also enable different types of communication for your beans
+ You can also enable different types of communication for your beans</para>
<programlisting>
@RemoteBindings({
@RemoteBinding(clientBindUrl="sslsocket://0.0.0.0:3843", jndiBinding="StatefulSSL"),
@@ -3096,7 +3092,6 @@
...
}
</programlisting>
- </para>
<para>
Now if you look up <literal>StatefulNormal</literal> the returned proxy implementing the remote interface will communicate with the server via the normal unencrypted socket protocol, and if you look up <literal>StatefulSSL</literal> the returned proxy implementing the remote interface will communicate with the server via SSL.
</para>
@@ -3104,12 +3099,12 @@
<section id="Adding_SSL_to_EJB3_Setting_up_the_client_to_use_truststore">
<title>Setting up the client to use the truststore</title>
<para>
-If not using a certificate signed by a certificate authorization authority, you need to point the client to the truststore using the <literal>javax.net.ssl.trustStore</literal> system property and specify the password using the <literal>javax.net.ssl.trustStorePassword</literal> system property:
+If not using a certificate signed by a certificate authorization authority, you need to point the client to the truststore using the <literal>javax.net.ssl.trustStore</literal> system property and specify the password using the <literal>javax.net.ssl.trustStorePassword</literal> system property:</para>
<programlisting>
java -Djavax.net.ssl.trustStore=${resources}/test/ssl/localhost.truststore
-Djavax.net.ssl.trustStorePassword=opensource com.acme.RunClient
</programlisting>
- </para>
+
</section>
</section>
<section id="Adding_SSL_to_EJB2.1">
@@ -3123,15 +3118,15 @@
<section id="Adding_SSL_to_EJB2.1_Setting_up_the_SSL_transport">
<title>Setting up the SSL transport</title>
<para>
-Now you need to tell JBoss Remoting where to find the keystore to be used for SSl and its password. This is done using <literal>javax.net.ssl.keyStore</literal> and <literal>javax.net.ssl.keyStorePassword=opensource</literal> system properties when starting JBoss, as the following example shows:
+Now you need to tell JBoss Remoting where to find the keystore to be used for SSl and its password. This is done using <literal>javax.net.ssl.keyStore</literal> and <literal>javax.net.ssl.keyStorePassword=opensource</literal> system properties when starting JBoss, as the following example shows:</para>
<programlisting>
$cd $JBOSS_HOME/bin
$ run -Djavax.net.ssl.keyStore=../server/production/conf/localhost.keystore
-Djavax.net.ssl.keyStorePassword=opensource
</programlisting>
- </para>
+
<para>
- If you wish to customize the SSLSocketBuilder you need to add the following to your <literal>$JBOSS_HOME/server/${serverConf}/conf/jboss-service.xml</literal> file.
+ If you wish to customize the SSLSocketBuilder you need to add the following to your <literal>$JBOSS_HOME/server/${serverConf}/conf/jboss-service.xml</literal> file.</para>
<programlisting>
<!-- This section is for custom (SSL) server socket factory -->
<mbean code="org.jboss.remoting.security.SSLSocketBuilder"
@@ -3167,12 +3162,12 @@
proxy-type="attribute">jboss.remoting:service=SocketBuilder,type=SSL</depends>
</mbean>
</programlisting>
- </para>
+
</section>
<section id="Adding_SSL_to_EJB2.1_configuring_your_beans">
<title>Configuring your beans to use the SSL transport</title>
<para>
- In your <literal>$JBOSS_HOME/server/${serverConf}/conf/jboss-service.xml</literal> file, comment out the following lines:
+ In your <literal>$JBOSS_HOME/server/${serverConf}/conf/jboss-service.xml</literal> file, comment out the following lines: </para>
<programlisting>
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:service=Connector,transport=socket"
@@ -3256,7 +3251,9 @@
<depends>jboss.remoting:service=NetworkRegistry</depends>
</mbean>
</programlisting>
+ <para>
and add the following in it's place:
+ </para>
<programlisting>
<mbean code="org.jboss.remoting.transport.Connector"
xmbean-dd="org/jboss/remoting/transport/Connector.xml"
@@ -3283,7 +3280,6 @@
<depends>jboss.remoting:service=NetworkRegistry</depends>
</mbean>
</programlisting>
- </para>
</section>
<section id="Adding_SSL_to_EJB2.1_Setting_up_the_client_to_use_truststore">
<title>Setting up the client to use the truststore</title>
Modified: projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Web_Services.xml
===================================================================
--- projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Web_Services.xml 2010-05-12 00:30:26 UTC (rev 104699)
+++ projects/docs/enterprise/4.3.3/Server_Configuration_Guide/en-US/Web_Services.xml 2010-05-12 01:11:22 UTC (rev 104700)
@@ -11,7 +11,6 @@
<para>
With document style web services two business partners agree on the exchange of complex business documents that are well defined in XML schema. For example, one party sends a document describing a purchase order, the other responds (immediately or later) with a document that describes the status of the purchase order. No need to agree on such low level details as operation names and their associated parameters. The payload of the SOAP message is an XML document that can be validated against XML schema. Document is defined by the style attribute on the SOAP binding.
</para>
- <para>
<programlisting>
<binding name='EndpointInterfaceBinding' type='tns:EndpointInterface'>
@@ -27,9 +26,8 @@
</operation>
</binding>
</programlisting>
- </para>
<para>
- With document style web services the payload of every message is defined by a complex type in XML schema.
+ With document style web services the payload of every message is defined by a complex type in XML schema. </para>
<programlisting>
<complexType name='concatType'>
@@ -49,13 +47,13 @@
</message>
</programlisting>
- </para>
+
</section>
<section id="Server_Configuration_Guide-Web_Services-DocumentLiteral_Bare">
<title>Document/Literal (Bare)</title>
<para>
- Bare is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a bare endpoint recognizable. A bare endpoint or client uses a Java bean that represents the entire document payload.
+ Bare is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a bare endpoint recognizable. A bare endpoint or client uses a Java bean that represents the entire document payload. </para>
<programlisting>
@WebService
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
@@ -68,9 +66,9 @@
}
}
</programlisting>
- </para>
+
<para>
- The trick is that the Java beans representing the payload contain JAXB annotations that define how the payload is represented on the wire.
+ The trick is that the Java beans representing the payload contain JAXB annotations that define how the payload is represented on the wire. </para>
<programlisting>
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "SubmitBareRequest", namespace="http://soapbinding.samples.jaxws.ws.test.jboss.org/", propOrder = { "product" })
@@ -82,13 +80,13 @@
...
}
</programlisting>
- </para>
+
</section>
<section id="Server_Configuration_Guide-Web_Services-DocumentLiteral_Wrapped">
<title>Document/Literal (Wrapped)</title>
<para>
- Wrapped is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a wrapped endpoint recognizable. A wrapped endpoint or client uses the individual document payload properties. Wrapped is the default and does not have to be declared explicitly.
+ Wrapped is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a wrapped endpoint recognizable. A wrapped endpoint or client uses the individual document payload properties. Wrapped is the default and does not have to be declared explicitly. </para>
<programlisting>
@WebService
@@ -103,6 +101,7 @@
}
}
</programlisting>
+ <para>
Note, that with JBossWS the request/response wrapper annotations are not required, they will be generated on demand using sensible defaults.
</para>
</section>
@@ -110,7 +109,8 @@
<section id="Server_Configuration_Guide-Web_Services-RPCLiteral">
<title>RPC/Literal</title>
<para>
- With RPC there is a wrapper element that names the endpoint operation. Child elements of the RPC parent are the individual parameters. The SOAP body is constructed based on some simple rules: <itemizedlist>
+ With RPC there is a wrapper element that names the endpoint operation. Child elements of the RPC parent are the individual parameters. The SOAP body is constructed based on some simple rules: </para>
+ <itemizedlist>
<listitem>
<para>
The port type operation name defines the endpoint method name
@@ -122,7 +122,9 @@
</para>
</listitem>
</itemizedlist>
+ <para>
RPC is defined by the style attribute on the SOAP binding.
+ </para>
<programlisting>
<binding name='EndpointInterfaceBinding' type='tns:EndpointInterface'>
@@ -138,9 +140,10 @@
</operation>
</binding>
</programlisting>
- </para>
<para>
- With rpc style web services the portType names the operation (i.e. the java method on the endpoint) <programlisting>
+ With rpc style web services the portType names the operation (i.e. the java method on the endpoint)
+ </para>
+ <programlisting>
<portType name='EndpointInterface'>
<operation name='echo' parameterOrder='String_1'>
<input message='tns:EndpointInterface_echo'/>
@@ -148,7 +151,9 @@
</operation>
</portType>
</programlisting>
+ <para>
Operation parameters are defined by individual message parts.
+ </para>
<programlisting>
<message name='EndpointInterface_echo'>
<part name='String_1' type='xsd:string'/>
@@ -157,7 +162,10 @@
<part name='result' type='xsd:string'/>
</message>
</programlisting>
- Note, there is no complex type in XML schema that could validate the entire SOAP message payload. <programlisting>
+ <para>
+ Note, there is no complex type in XML schema that could validate the entire SOAP message payload.
+ </para>
+ <programlisting>
@WebService
@SOAPBinding(style = SOAPBinding.Style.RPC)
@@ -171,6 +179,7 @@
}
}
</programlisting>
+ <para>
The element names of RPC parameters/return values may be defined using the JAX-WS Annotations#javax.jws.WebParam and JAX-WS Annotations#javax.jws.WebResult respectively.
</para>
</section>
@@ -178,7 +187,8 @@
<section id="Server_Configuration_Guide-Web_Services-RPCEncoded">
<title>RPC/Encoded</title>
<para>
- SOAP encodeding style is defined by the infamous <ulink url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512">chapter 5</ulink> of the <ulink url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">SOAP-1.1</ulink> specification. It has inherent interoperability issues that cannot be fixed. The <ulink url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html">Basic Profile-1.0</ulink> prohibits this encoding style in <ulink url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16448072">4.1.7 SOAP encodingStyle Attribute</ulink>. JBossWS has basic support for rpc/encoded that is provided as is for simple interop scenarios with SOAP stacks that do not support literal encoding. Specifically, JBossWS does not support:- <itemizedlist>
+ SOAP encodeding style is defined by the infamous <ulink url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512">chapter 5</ulink> of the <ulink url="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/">SOAP-1.1</ulink> specification. It has inherent interoperability issues that cannot be fixed. The <ulink url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html">Basic Profile-1.0</ulink> prohibits this encoding style in <ulink url="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#refinement16448072">4.1.7 SOAP encodingStyle Attribute</ulink>. JBossWS has basic support for rpc/encoded that is provided as is for simple interop scenarios with SOAP stacks that do not support literal encoding. Specifically, JBossWS does not support:- </para>
+ <itemizedlist>
<listitem>
<para>
element references
@@ -190,7 +200,6 @@
</para>
</listitem>
</itemizedlist>
- </para>
</section>
<section id="Server_Configuration_Guide-Web_Services-Web_Service_Endpoints_">
@@ -204,6 +213,7 @@
<title>Plain old Java Object (POJO)</title>
<para>
Let's take a look at simple POJO endpoint implementation. All endpoint associated metadata is provided via JSR-181 annotations
+ </para>
<programlisting>@WebService
@SOAPBinding(style = SOAPBinding.Style.RPC)
public class JSEBean01
@@ -215,13 +225,12 @@
}
}
</programlisting>
- </para>
</section>
<section id="Server_Configuration_Guide-Web_Services-The_endpoint_as_a_web_application">
<title>The endpoint as a web application</title>
<para>
- A JAX-WS java service endpoint (JSE) is deployed as a web application.
+ A JAX-WS java service endpoint (JSE) is deployed as a web application. </para>
<programlisting>
<web-app ...>
<servlet>
@@ -234,13 +243,12 @@
</servlet-mapping>
</web-app>
</programlisting>
- </para>
</section>
<section id="Server_Configuration_Guide-Web_Services-Packaging_the_endpoint">
<title>Packaging the endpoint</title>
<para>
- A JSR-181 java service endpoint (JSE) is packaged as a web application in a *.war file.
+ A JSR-181 java service endpoint (JSE) is packaged as a web application in a *.war file. </para>
<programlisting>
<war warfile="${build.dir}/libs/jbossws-samples-jsr181pojo.war"
@@ -250,6 +258,7 @@
</classes>
</war>
</programlisting>
+ <para>
Note, only the endpoint implementation bean and web.xml are required.
</para>
</section>
@@ -259,11 +268,11 @@
<para>
A successfully deployed service endpoint will show up in the service endpoint manager. This is also where you find the links to the generated wsdl.
</para>
- <para>
+
<programlisting>
-http://yourhost:8080/jbossws/services
-
+http://yourhost:8080/jbossws/services
</programlisting>
+ <para>
Note, it is also possible to generate the abstract contract off line using jbossw tools. For details of that please see <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_User_Guide#Top_Down_.28Java_to_WSDL.29">#Top Down (Java to WSDL)</ulink>
</para>
</section>
More information about the jboss-cvs-commits
mailing list