[jboss-cvs] JBossAS SVN: r72328 - in projects/docs/trunk/AS_4/Server_Configuration_Guide: en-US and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Apr 17 01:45:08 EDT 2008
Author: skittoli at redhat.com
Date: 2008-04-17 01:45:08 -0400 (Thu, 17 Apr 2008)
New Revision: 72328
Modified:
projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_Additional_Services.xml
projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Web_Services.xml
projects/docs/trunk/AS_4/Server_Configuration_Guide/pom.xml
Log:
minor typographic corrections
Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_Additional_Services.xml
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_Additional_Services.xml 2008-04-17 05:21:14 UTC (rev 72327)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/J2EE_Additional_Services.xml 2008-04-17 05:45:08 UTC (rev 72328)
@@ -39,7 +39,7 @@
</varlistentry>
</variablelist>
<para>
- These are useful metrics for monitoring and alerting, but developers and administrators need a little more insite than this. The Java 5 JVMs from Sun provide more detailed information about the current state of the JVM. Some of these details are exposed by JBoss through operations on the SystemInfo MBean.
+ These are useful metrics for monitoring and alerting, but developers and administrators need a little more insight than this. The Java 5 JVMs from Sun provide more detailed information about the current state of the JVM. Some of these details are exposed by JBoss through operations on the SystemInfo MBean.
</para>
<variablelist>
<varlistentry>
@@ -944,7 +944,7 @@
</listitem>
<listitem>
<para>
- <emphasis role="bold">NotificationMapResName</emphasis>: Specifies the resource name of the <literal>notications.xml</literal> file.
+ <emphasis role="bold">NotificationMapResName</emphasis>: Specifies the resource name of the <literal>notifications.xml</literal> file.
</para>
</listitem>
<listitem>
Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Web_Services.xml
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Web_Services.xml 2008-04-17 05:21:14 UTC (rev 72327)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/en-US/Web_Services.xml 2008-04-17 05:45:08 UTC (rev 72328)
@@ -717,7 +717,7 @@
</section>
<section>
<title>Fault Handling</title>
- <para>An implementation may thow a SOAPFaultException</para>
+ <para>An implementation may throw a SOAPFaultException</para>
<programlisting> <![CDATA[
public void throwSoapFaultException()
{
@@ -977,7 +977,7 @@
<para> Replacing the implementation of an existing Web Service, and you can't break compatibility with older clients</para>
</listitem>
<listitem>
- <para> Exposing a service that conforms to a contract specified by a third party (e.g. a vender that calls you back using an already defined protocol).</para>
+ <para> Exposing a service that conforms to a contract specified by a third party (e.g. a vendor that calls you back using an already defined protocol).</para>
</listitem>
<listitem>
<para> Creating a service that adheres to the XML Schema and WSDL you developed by hand up front</para>
@@ -1050,7 +1050,7 @@
}
}
]]> </programlisting>
- <para>A JSE or EJB3 deployment can be built using this class, and it is the only Java code needed to deploy on JBossWS. The WSDL, and all other Java artifacts called "wrapper classes" will be generated for you at deploy time. This actually goes beyond the JAX-WS specification, which requires that wrapper classes be generated using an offline tool. The reason for this requirement is purely a vender implementation problem, and since we do not believe in burdening a developer with a bunch of additional steps, we generate these as well. However, if you want your deployment to be portable to other application servers, you will unfortunately need to use a tool and add the generated classes to your deployment.</para>
+ <para>A JSE or EJB3 deployment can be built using this class, and it is the only Java code needed to deploy on JBossWS. The WSDL, and all other Java artifacts called "wrapper classes" will be generated for you at deploy time. This actually goes beyond the JAX-WS specification, which requires that wrapper classes be generated using an offline tool. The reason for this requirement is purely a vendor implementation problem, and since we do not believe in burdening a developer with a bunch of additional steps, we generate these as well. However, if you want your deployment to be portable to other application servers, you will unfortunately need to use a tool and add the generated classes to your deployment.</para>
<para>This is the primary purpose of the <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=Wsprovide">wsprovide</ulink> tool, to generate portable JAX-WS artifacts. Additionally, it can be used to "provide" the abstract contract (WSDL file) for your service. This can be obtained by invoking <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=Wsprovide">wsprovide</ulink> using the "-w" option:</para>
<programlisting> <![CDATA[
$ javac -d . -classpath jboss-jaxws.jar Echo.java
@@ -1409,7 +1409,7 @@
<title>Web Service Extensions</title>
<section>
<title>WS-Addressing</title>
- <para>This section describes how <ulink url="http://www.w3.org/TR/ws-addr-core">WS-Addressing</ulink> can be used to provide a staful service endpoint.</para>
+ <para>This section describes how <ulink url="http://www.w3.org/TR/ws-addr-core">WS-Addressing</ulink> can be used to provide a stateful service endpoint.</para>
<section>
<title>Specifications</title>
<para>WS-Addressing is defined by a combination of the following specifications from the W3C Candidate Recommendation 17 August 2005. The WS-Addressing API is standardized by <ulink url="http://www.jcp.org/en/jsr/detail?id=261">JSR-261 - Java API for XML Web Services Addressing</ulink></para>
@@ -1449,7 +1449,7 @@
{ ... }
}
]]> </programlisting>
- <para>It uses the <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_Endpoint_Configuration#_Standard_WSAddressing_Endpoint">JAX-WS Endpoint Configuration# Standard WSAddressing Endpoint</ulink> to enable the server side addressing handler. It processes the incomming WS-Addressing header elements and provides access to them through the JSR-261 API.</para>
+ <para>It uses the <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_Endpoint_Configuration#_Standard_WSAddressing_Endpoint">JAX-WS Endpoint Configuration# Standard WSAddressing Endpoint</ulink> to enable the server side addressing handler. It processes the incoming WS-Addressing header elements and provides access to them through the JSR-261 API.</para>
<para>The endpoint handler chain</para>
<programlisting> <![CDATA[
<handler-chains xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
@@ -1465,11 +1465,11 @@
</handler-chains>
]]> </programlisting>
- <para>defines an application specific hander that assignes/processes stateful client ids.</para>
+ <para>defines an application specific handler that assigns/processes stateful client ids.</para>
</section>
<section>
<title>Addressing Client</title>
- <para>On the client side there are simmilar handlers that does the reverse. It uses the JSR-261 API to add WS-Addressing header elements including the clientid association.</para>
+ <para>On the client side there are similar handlers that does the reverse. It uses the JSR-261 API to add WS-Addressing header elements including the clientid association.</para>
<para> The client sets a custom handler chain in the binding</para>
<programlisting> <![CDATA[
Service service = Service.create(wsdlURL, serviceName);
@@ -1511,7 +1511,7 @@
<para>
<emphasis role="bold">SOAP message exchange</emphasis>
</para>
- <para>Below you see the SOAP messages that are beeing exchanged.</para>
+ <para>Below you see the SOAP messages that are being exchanged.</para>
<programlisting> <![CDATA[
<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Header xmlns:wsa='http://schemas.xmlsoap.org/ws/2004/08/addressing'>
@@ -1591,7 +1591,7 @@
</para>
</listitem>
</itemizedlist>
- <para>The following section will introduce the main eventing actors and their responsiblities.</para>
+ <para>The following section will introduce the main eventing actors and their responsibilities.</para>
<para>
<note><title>Note</title>
<para>The original eventing specification builds upon WS-Addressing 2004/08. JBossWS however decided to stick to the latest version, which is the W3C candidate release.</para>
@@ -1612,7 +1612,7 @@
<para>Eventing collaboration</para>-->
<orderedlist>
<listitem>
- <para> An event sink (web service client) sends a subscribtion request to the event source endpoint. This includes the event sink endpoint address where notifications should delivered. Upon successful subscription the sink receives a leased subscription ID that can be used to identify the client in subsequent requests.</para>
+ <para> An event sink (web service client) sends a subscription request to the event source endpoint. This includes the event sink endpoint address where notifications should delivered. Upon successful subscription the sink receives a leased subscription ID that can be used to identify the client in subsequent requests.</para>
</listitem>
<listitem>
<para> A successfully registered event sink directs management requests (Renew, GetStatus, Unsubscribe) to the subscription manager endpoint using the previously received subscription ID. The subscription manager endpoint address was returned as part of the subscription response in the first place.</para>
@@ -1625,7 +1625,7 @@
</listitem>
</orderedlist>
</para>
- <para>It is the users responsibilty to supply the web service endpoints (EventSourceEndpoint, SubscriptionManagerEndpoint) that are required for a complete event source deployment. Fortunatly JBossWS-Eventing already ships with a implementation that can be used right away. All that's left todo is packaging of standard JSR-109 deployment archive that includes the event source specific WSDL and points to the JBossWS-Eventing endpoint implementations.</para>
+ <para>It is the users responsibility to supply the web service endpoints (EventSourceEndpoint, SubscriptionManagerEndpoint) that are required for a complete event source deployment. Fortunately JBossWS-Eventing already ships with a implementation that can be used right away. All that's left todo is packaging of standard JSR-109 deployment archive that includes the event source specific WSDL and points to the JBossWS-Eventing endpoint implementations.</para>
<para>The relevant steps are:</para>
<itemizedlist>
<listitem>
@@ -1761,7 +1761,7 @@
<para> Include the default eventing Types</para>
</listitem>
<listitem>
- <para> Specifiy the notitification message schema.</para>
+ <para> Specify the notification message schema.</para>
</listitem>
<listitem>
<para> Declare a port type, attributed "wse:EventSource='true'" that points to your notification message schema.</para>
@@ -1770,7 +1770,7 @@
</section>
<section>
<title>Emitting notifications</title>
- <para>JBossWS-Eventing registeres a event dispatcher within local JNDI tree that can be used to emit notifications from applications.</para>
+ <para>JBossWS-Eventing registers a event dispatcher within local JNDI tree that can be used to emit notifications from applications.</para>
<programlisting> <![CDATA[
java:/EventDispatcher
]]> </programlisting>
@@ -1819,7 +1819,7 @@
<programlisting> <![CDATA[
jboss.ws.eventing:service=SubscriptionManager
]]> </programlisting>
- <para>Management operations exist to monitor and maintain active subscritions and deployed event sources. The current implementation is backed by a ThreadPoolExecutor, that asynchronously delivers messages to event sink endpoints. It can be configured through the following attributes:</para>
+ <para>Management operations exist to monitor and maintain active subscriptions and deployed event sources. The current implementation is backed by a ThreadPoolExecutor, that asynchronously delivers messages to event sink endpoints. It can be configured through the following attributes:</para>
<itemizedlist>
<listitem>
<para> corePoolSize - average number of idle threads</para>
@@ -1875,7 +1875,7 @@
</itemizedlist>
<section>
<title>Endpoint configuration</title>
- <para>JBossWS uses handlers to identify ws-security encoded requests and invoke the security components to sign and encrypt messages. In order to enable security processing, the client and server side need to include a corressponding handler configuration. The preferred way is to reference a predefined <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_Endpoint_Configuration">JAX-WS Endpoint Configuration</ulink> or <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_Client_Configuration">JAX-WS Client Configuration</ulink> respectively.</para>
+ <para>JBossWS uses handlers to identify ws-security encoded requests and invoke the security components to sign and encrypt messages. In order to enable security processing, the client and server side need to include a corresponding handler configuration. The preferred way is to reference a predefined <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_Endpoint_Configuration">JAX-WS Endpoint Configuration</ulink> or <ulink url="http://jbws.dyndns.org/mediawiki/index.php?title=JAX-WS_Client_Configuration">JAX-WS Client Configuration</ulink> respectively.</para>
<para>
<note><title>Note</title>
<para>You need to setup both the endpoint configuration and the WSSE declarations. That's two separate steps.</para>
@@ -1984,8 +1984,8 @@
<para>
<emphasis role="bold">SOAP message exchange</emphasis>
</para>
- <para>Below you see the incomming SOAP message with the details of the security headers ommited. The idea is, that the SOAP body is still plain text, but it is signed in the security header and can therefore not manipulated in transit.</para>
- <para>Incomming SOAPMessage</para>
+ <para>Below you see the incoming SOAP message with the details of the security headers omitted. The idea is, that the SOAP body is still plain text, but it is signed in the security header and can therefore not manipulated in transit.</para>
+ <para>Incoming SOAPMessage</para>
<programlisting> <![CDATA[
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
@@ -2013,7 +2013,7 @@
</section>
<section>
<title>Installing the BouncyCastle JCE provider (JDK 1.4)</title>
- <para>The information below has originaly been provided by <ulink url="http://www.bouncycastle.org/specifications.html#install">The Legion of the Bouncy Castle</ulink>.</para>
+ <para>The information below has originally been provided by <ulink url="http://www.bouncycastle.org/specifications.html#install">The Legion of the Bouncy Castle</ulink>.</para>
<para>The provider can be configured as part of your environment via static registration by adding an entry to the java.security properties file (found in $JAVA_HOME/jre/lib/security/java.security, where $JAVA_HOME is the location of your JDK/JRE distribution). You'll find detailed instructions in the file but basically it comes down to adding a line:</para>
<programlisting> <![CDATA[
security.provider.<n>=org.bouncycastle.jce.provider.BouncyCastleProvider
Modified: projects/docs/trunk/AS_4/Server_Configuration_Guide/pom.xml
===================================================================
--- projects/docs/trunk/AS_4/Server_Configuration_Guide/pom.xml 2008-04-17 05:21:14 UTC (rev 72327)
+++ projects/docs/trunk/AS_4/Server_Configuration_Guide/pom.xml 2008-04-17 05:45:08 UTC (rev 72328)
@@ -4,9 +4,8 @@
<modelVersion>4.0.0</modelVersion>
-
- <groupId>org.hibernate-sandbox</groupId>
- <artifactId>docbook-testing</artifactId>
+ <groupId>org.jboss.jbossas</groupId>
+ <artifactId>admministration-and-configuration-${translation}</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jdocbook</packaging>
<name>Server Configuration Guide (${translation})</name>
@@ -18,61 +17,83 @@
<artifactId>maven-jdocbook-plugin</artifactId>
<version>2.0.0</version>
<extensions>true</extensions>
- <!--dependencies>
+ <dependencies>
<dependency>
- <groupId>org.hibernate</groupId>
- <artifactId>hibernate-docbook-xslt</artifactId>
+ <groupId>org.jboss</groupId>
+ <artifactId>jbossorg-docbook-xslt</artifactId>
+ <version>1.1.0-SNAPSHOT</version>
+ </dependency>
+ <dependency>
+ <groupId>org.jboss</groupId>
+ <artifactId>jbossorg-jdocbook-style</artifactId>
+ <version>1.1.0-SNAPSHOT</version>
<type>jdocbook-style</type>
- <version>0.1</version>
</dependency>
- </dependencies-->
+ </dependencies>
<configuration>
- <sourceDocumentName>Server_Configuration_Guide.xml</sourceDocumentName>
+ <minmemory>1024m</minmemory>
+ <maxmemory>1024m</maxmemory>
+ <sourceDocumentName>resolved.xml</sourceDocumentName>
+ <sourceDirectory>en-US</sourceDirectory>
<imageResource>
<directory>en-US</directory>
- <excludes>
- <exclude>*.xml</exclude>
- </excludes>
+ <includes>
+ <include>images/*</include>
+ </includes>
</imageResource>
- <cssResource>
- <directory>en-US</directory>
- <excludes>
- <exclude>*.xml</exclude>
- </excludes>
- </cssResource>
+ <!--<cssResource>
+ <directory>src/main/css</directory>
+ </cssResource>-->
<formats>
- <format>
- <formatName>pdf</formatName>
- <!--stylesheetResource>classpath:/standard/fopdf.xsl</stylesheetResource-->
- <finalName>Server_Configuration_Guide.pdf</finalName>
- </format>
- <format>
+
+ <format>
<formatName>html</formatName>
- <!--stylesheetResource>classpath:/standard/html_chunk.xsl</stylesheetResource-->
+ <stylesheetResource>classpath:/xslt/org/jboss/main-html.xsl</stylesheetResource>
<finalName>index.html</finalName>
- </format>
-<!--
- <format>
+ </format>
+
+ <format>
<formatName>html_single</formatName>
- <stylesheetResource>classpath:/xslt/nochunk-html.xsl</stylesheetResource>
+ <stylesheetResource>classpath:/xslt/org/jboss/nochunk-html.xsl</stylesheetResource>
+ <finalName>index.html</finalName>
</format>
--->
-<!-- <format>
+
+ <!-- <format>
+ <formatName>pdf</formatName>
+ <stylesheetResource>classpath:/xslt/org/jboss/main-pdf.xsl</stylesheetResource>
+ <finalName>Server_Configuration_Guide.pdf</finalName>
+ </format> -->
+
+
+
+ <!--<format>
<formatName>eclipse</formatName>
<stylesheetResource>classpath:/xslt/main-eclipse.xsl</stylesheetResource>
<finalName>index.html</finalName>
- </format>
--->
- </formats>
- <options>
+ </format>-->
+
+ </formats>
+
+ <options>
<xincludeSupported>true</xincludeSupported>
<xmlTransformerType>saxon</xmlTransformerType>
<!-- needed for uri-resolvers; can be ommitted if using 'current' uri scheme -->
<!-- could also locate the docbook dependency and inspect its version... -->
<docbookVersion>1.72.0</docbookVersion>
+ <transformerParameters>
+ <property>
+ <name>javax.xml.parsers.DocumentBuilderFactory</name>
+ <value>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl</value>
+ </property>
+ <property>
+ <name>javax.xml.parsers.SAXParserFactory</name>
+ <value>org.apache.xerces.jaxp.SAXParserFactoryImpl</value>
+ </property>
+ <!--<javax.xml.parsers.DocumentBuilderFactory>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl</javax.xml.parsers.DocumentBuilderFactory>
+ <javax.xml.parsers.SAXParserFactory>org.apache.xerces.jaxp.SAXParserFactoryImpl</javax.xml.parsers.SAXParserFactory>
+ <javax.xml.validation.SchemaFactory:http\://www.w3.org/2001/XMLSchema>org.apache.xerces.jaxp.validation.XMLSchemaFactory</javax.xml.validation.SchemaFactory:http\://www.w3.org/2001/XMLSchema>-->
+ </transformerParameters>
</options>
-
- <sourceDirectory>${basedir}/en-US</sourceDirectory>
</configuration>
</plugin>
</plugins>
@@ -80,6 +101,5 @@
<properties>
<translation>en-US</translation>
- </properties>
-
+ </properties>
</project>
More information about the jboss-cvs-commits
mailing list