Merge pull request #3 from ocpsoft/master

Update from master

Author: mdfst13

.travis.yml

@@ -18,6 +18,8 @@ matrix:
       jdk: oraclejdk8
     - env: CONTAINER=TOMEE_MANAGED_1.5
       jdk: openjdk7
+  allow_failures:
+    - env: CONTAINER=TOMEE_MANAGED_1.5
 notifications:
   email:
     - "[email protected]"

documentation/src/main/asciidoc/configuration/index.asciidoc

@@ -16,11 +16,11 @@ ConfigurationProvider:: An object that provides +Configuration+ instances to the
 
 Configuration:: A collection of +Rule+ objects that are processed in order until the system has determined the current inbound or oubound Rewrite event has been handled. Configurations may be provided by extensions, cached for performance, or built dynamically at run-time.
 
-ConfigurationBuilder:: This is likely the object you will interact with most when configuring the Rewrite system. Start with a +ConfigurationBuilder+ in each situation where you find yourself in need of a +Configuration+ object; this class may be used to add pre-constructed, or contruct custom +Rule+ instances for Rewrite.
+ConfigurationBuilder:: This is likely the object you will interact with most when configuring the Rewrite system. Start with a +ConfigurationBuilder+ in each situation where you find yourself in need of a +Configuration+ object; this class may be used to add pre-constructed, or construct custom +Rule+ instances for Rewrite.
 
 Condition:: Defines a requirement that must be met in order for rule evaluation to return true. You may create custom +Condition+ implementations. If creating custom implementations, you should likely extend +DefaultConditionBuilder+, which  adds logical operators +.and()+, +.or()+, and +.not()+.
 
-Operation:: Defines behavior to be performed after evaluation a +Rewrite+ event. These objects may be as simple or as complex as desired, ranging from simple logging to request forwarding. Typically +Operation+ instances may be chained to achieve more complex tasks. If creating custom umplementations, you should likely extend +DefaultOperationBuilder+, which adds logical chaining via +.and()+.
+Operation:: Defines behavior to be performed after evaluation a +Rewrite+ event. These objects may be as simple or as complex as desired, ranging from simple logging to request forwarding. Typically +Operation+ instances may be chained to achieve more complex tasks. If creating custom implementations, you should likely extend +DefaultOperationBuilder+, which adds logical chaining via +.and()+.
 
 Parameter:: Specifies a fragment of an HTTP request that may be referenced in both +Condition+ and +Operation+ instances. Parameters are defined using the +.where()+ method of the +ConfigurationBuilder+, which is available once the first +Rule+ (with conditions or operations) has been added.
 
@@ -91,7 +91,7 @@ java.lang.IllegalArgumentException: No such parameter [ foo ] exists.
 
 ==== A closer look
 
-Now that we have written a rule that uses a few different +Operation+ and +Condition+ objects, lets take a look at how the interaction works - we will break down the entire rule:
+Now that we have written a rule that uses a few different +Operation+ and +Condition+ objects, let's take a look at how the interaction works - we will break down the entire rule:
 
 [source,java]
 ----

documentation/src/main/asciidoc/faq.asciidoc

@@ -35,8 +35,8 @@ According to the Servlet spec +HttpServletRequest.getParameter*()+ and
 for +multipart/form-data+ request. Using these methods outside of such
 Servlets results in undefined behavior.
 
-Apache Tomcat provides an configuration parameter which changes this and
-allows to access these methods from a Servlet filter. To enable this
+Apache Tomcat provides a configuration parameter which changes this and
+allows access to these methods from a Servlet filter. To enable this
 behavior, create a file +META-INF/context.xml+ in your WAR file 
 (in case of Maven use +src/main/webapp/META-INF/context.xml+) and add
 the following content:

documentation/src/main/asciidoc/migration/prettyfaces3.asciidoc

@@ -116,7 +116,7 @@ Remove this entry completely and replace it with the corresponding entry for the
 </filter-mapping>
 ----
 
-NOTE: Please not that if you are using a Servlet 3.x container and your +web.xml+ doesn't set
+NOTE: Please note that if you are using a Servlet 3.x container and your +web.xml+ doesn't set
 +metadata-complete="true"+, you don't have to register the Rewrite filter manually, because
 this is done automatically. In this case just make sure to remove the old +PrettyFilter+ entry. 
 
@@ -277,7 +277,7 @@ code for an example:
 ).where("category").bindsTo(El.property("bean.category"))
 |===
 
-If your bean uses a JSF-specifc scope like +@ViewScoped+), you have to wrap 
+If your bean uses a JSF-specific scope like +@ViewScoped+), you have to wrap 
 the +El+ binding in a +PhaseBinding+. This will tell PrettyFaces to submit the 
 binding in the specified JSF phase which ensures, that the scope of the bean will
 be active.
@@ -531,7 +531,7 @@ public void action() {
 }
 |===
 
-TIP: Thie +@IgnorePostback+ annotation can also be used with +@Parameter+.
+TIP: The +@IgnorePostback+ annotation can also be used with +@Parameter+.
 
 If the annotated bean has a scope that requires an active JSF lifecycle like for example
 +@ViewScope+, you have to _defer_ the invocation so that it is executed within the JSF lifecycle. 
@@ -575,7 +575,7 @@ public class CustomerDetailsBean {
 
 PrettyFaces shipped with a special JSF component that simplified creating links to mapped URLs.
 However JSF 2.0 introduced +<h:link>+, which works fine for creating such links. Rewrite doesn't
-include any special JSF component. It is recomended to use the standard JSF component for rendering
+include any special JSF component. It is recommended to use the standard JSF component for rendering
 links.
 
 Using +<h:link>+ for creating links to Rewrite URLs is very easy. Just use the URL you