[jboss-cvs] JBossAS SVN: r105606 - projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Wed Jun 2 19:29:17 EDT 2010


Author: misty at redhat.com
Date: 2010-06-02 19:29:16 -0400 (Wed, 02 Jun 2010)
New Revision: 105606

Modified:
   projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Migration.xml
Log:
JBPAPP-4387

Modified: projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Migration.xml
===================================================================
--- projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Migration.xml	2010-06-02 23:12:52 UTC (rev 105605)
+++ projects/docs/enterprise/EAP/trunk/5.x/Seam_Reference_Guide/en-US/Migration.xml	2010-06-02 23:29:16 UTC (rev 105606)
@@ -36,7 +36,7 @@
             </listitem>
             <listitem>
                <para>Change the <varname>web-app</varname> version from <literal>2.4</literal> to <literal>2.5</literal>. In the namespace URL, change <literal>j2ee</literal> to <literal>javaee</literal>. For example:</para>
-<programlisting role="XML"><![CDATA[<web-app xmlns="http://java.sun.com/xml/ns/javaee"
+<programlisting language="XML" role="XML"><![CDATA[<web-app xmlns="http://java.sun.com/xml/ns/javaee"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="
          http://java.sun.com/xml/ns/javaee
@@ -67,7 +67,7 @@
             </listitem>
             <listitem>
                <para>Remove the Document Type Declaration (DTD) from the document and add the XML Schema declarations to the <literal><![CDATA[<faces-config>]]></literal> root tag, like so:</para>
-<programlisting role="XML"><![CDATA[<faces-config version="1.2"
+<programlisting language="XML" role="XML"><![CDATA[<faces-config version="1.2"
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="
@@ -182,13 +182,13 @@
             <para>
                Seam transaction management is now enabled by default. It is now controlled by <filename>components.xml</filename> instead of a JSF phase listener declaration in <filename>faces-config.xml</filename>. To disable Seam-managed transactions, use the following:
             </para>
-<programlisting role="XML"><![CDATA[<core:init transaction-management-enabled="false"/>]]></programlisting>
+<programlisting language="XML" role="XML"><![CDATA[<core:init transaction-management-enabled="false"/>]]></programlisting>
          </note>
          <note>
             <para>
                The <varname>expression</varname> attribute on <literal>event</literal> <literal>action</literal>s has been deprecated in favour of <literal>execute</literal>. For example:
             </para>
-<programlisting role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
+<programlisting language="XML" role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
   <action execute="#{redirect.captureCurrentView}"/>
 </event>
 <event type="org.jboss.seam.loginSuccessful">
@@ -237,7 +237,7 @@
          <para>
             If you use jBPM for business processes as well as pageflows, you must add the <literal>tx</literal> service to <filename>jbpm.cfg.xml</filename>:
          </para>
-<programlisting role="XML"><![CDATA[<service name="tx" factory="org.jbpm.tx.TxServiceFactory" />]]>
+<programlisting language="XML" role="XML"><![CDATA[<service name="tx" factory="org.jbpm.tx.TxServiceFactory" />]]>
 </programlisting>
       </section>
       <section id="Migration12.RFC">
@@ -266,7 +266,7 @@
                <literal><![CDATA[<s:decorate>]]></literal> has become a naming container. Client IDs have therefore changed from <literal>fooForm:fooInput</literal> to <literal>fooForm:foo:fooInput</literal>, assuming that the following has been declared:
             </para>
         </formalpara>
-<programlisting role="XML"><![CDATA[<h:form id="fooForm">
+<programlisting language="XML" role="XML"><![CDATA[<h:form id="fooForm">
   <s:decorate id="foo">
     <h:inputText id="fooInput" value="#{bean.property}"/>
   </s:decorate>
@@ -285,17 +285,17 @@
                Originally, classes were generated as follows:
             </para>
             <screen>
-  src/model/com/domain/projectname/model/EntityName.java
-  src/action/com/domain/projectname/model/EntityNameHome.java
-  src/action/com/domain/projectname/model/EntityNameList.java
+  <filename>src/model/com/domain/projectname/model/EntityName.java</filename>
+  <filename>src/action/com/domain/projectname/model/EntityNameHome.java</filename>
+  <filename>src/action/com/domain/projectname/model/EntityNameList.java</filename>
             </screen>
             <para>
                Now, they are generated like this:
             </para>
             <screen>
-  src/model/com/domain/projectname/model/EntityName.java
-  src/action/com/domain/projectname/action/EntityNameHome.java
-  src/action/com/domain/projectname/action/EntityNameList.java
+  <filename>src/model/com/domain/projectname/model/EntityName.java</filename>
+  <filename>src/action/com/domain/projectname/action/EntityNameHome.java</filename>
+  <filename>src/action/com/domain/projectname/action/EntityNameList.java</filename>
             </screen>
             <para>
                Home and Query objects are <emphasis>action</emphasis> components, not <emphasis>model</emphasis> components, and are therefore placed in the <literal>action</literal> package. This makes <literal>generate-entities</literal> conventions consistent with those of the <literal>new-entity</literal> command.
@@ -315,7 +315,7 @@
             <para>
                Add the following CSS to your style sheet to allow your style to accomodate a change in the RichFaces panel. Failing to add this code will mean that, in any page created by <literal>generate-entities</literal>, the <emphasis>search criteria</emphasis> block will bleed into the <emphasis>results table</emphasis>.
             </para>
-<programlisting>
+<programlisting language="CSS" role="CSS">
 .rich-stglpanel-body {
   overflow: auto;
 }
@@ -362,22 +362,22 @@
             <para>
                You can use either of these approaches to inject the Hibernate Session:
             </para>
-<programlisting role="JAVA">
+	    <programlisting language="Java" role="JAVA">
 @In private Session hibernateSession;
 </programlisting>
-<programlisting role="JAVA">
+<programlisting  language="Java" role="JAVA">
 @In(name = "hibernateSession") private Session session;
 </programlisting>
             <para>
                If your Seam-managed Hibernate Session is still named <literal>session</literal>, you can inject the reference explicitly with the <varname>session</varname> property:
             </para>
-<programlisting role="XML"><![CDATA[<framework:hibernate-entity-home session="#{session}".../>
+	    <programlisting language="Java" role="XML"><![CDATA[<framework:hibernate-entity-home session="#{session}".../>
 <transaction:entity-transaction session="#{session}".../>]]>
 </programlisting>
             <para>
                Alternatively, you can override the <literal>getPersistenceContextName()</literal> method on any persistence controller in the Seam Application Framework with the following:
             </para>
-<programlisting role="JAVA">
+	    <programlisting language="Java" role="JAVA">
 public String getPersistenceContextName() {
    "session";
 }
@@ -388,13 +388,13 @@
                The configuration for security rules in <filename>components.xml</filename> has changed for projects that use rule-based security. Previously, rules were configured as a property of the <literal>identity</literal> component:
             </para>
           </formalpara>
-<programlisting role="XML"><![CDATA[<security:identity security-rules="#{securityRules}" 
+<programlisting language="XML" role="XML"><![CDATA[<security:identity security-rules="#{securityRules}" 
           authenticate-method="#{authenticator.authenticate}"/>]]>
 </programlisting>
             <para>
                Seam 2.1 uses the <literal>ruleBasedPermissionResolver</literal> component for its rule-based permission checks. You must activate this component and register the security rules with it instead of with the <literal>identity</literal> component:
             </para>
-<programlisting><![CDATA[<security:rule-based-permission-resolver 
+<programlisting language="XML" role="XML"><![CDATA[<security:rule-based-permission-resolver 
           security-rules="#{securityRules}"/>]]>
 </programlisting>
             <important>
@@ -409,7 +409,7 @@
                <para>
                   The <emphasis>name</emphasis> would typically be the Seam component's name, entity class, or view ID. The <emphasis>action</emphasis> would be the method name, the JSF phase (restore or render), or an assigned term representing the intent of the activity. Optionally, one or more contextual objects can be inserted directly into the working memory to assist in decision-making. Typically, this would be the target of the activity. For example:
                </para>
-<programlisting role="JAVA">s:hasPermission('userManager', 'edit', user)</programlisting>
+<programlisting language="Java" role="JAVA">s:hasPermission('userManager', 'edit', user)</programlisting>
                <para>
                   In Seam 2.1, permissions have been simplified so that they contain two elements:
                </para>
@@ -420,18 +420,18 @@
                <para>
                   The <emphasis>target</emphasis> replaces the <emphasis>name</emphasis> element, becoming the focus of the permission. The <emphasis>action</emphasis> still communicates the intent of the activity to be secured. Within the rules file, most checking now revolves around the <emphasis>target</emphasis> object. For example:
                </para>
-<programlisting role="JAVA">s:hasPermission(user, 'edit')</programlisting>
+<programlisting language="Java" role="JAVA">s:hasPermission(user, 'edit')</programlisting>
                <para>
                   This change means that the rules can be applied more broadly, and lets Seam consult a persistent permission resolver (ACL) as well as the rule-based resolver.
                </para>
                <para>
                   Additionally, keep in mind that existing rules may behave oddly. This is because, given the following permission check format:
                </para>
-               <programlisting>s:hasPermission('userManager', 'edit', user)</programlisting>
+               <programlisting language="Java" role="JAVA">s:hasPermission('userManager', 'edit', user)</programlisting>
                <para>
                   Seam transposes the following to apply the new permission format:
                </para>
-               <programlisting>s:hasPemrission(user, 'edit')</programlisting>
+               <programlisting language="Java" role="JAVA">s:hasPemrission(user, 'edit')</programlisting>
                <para>
                   Read the Security chapter for a complete overview of the new design.
                </para>
@@ -445,7 +445,7 @@
             <para>
                If you use Seam's token-based <emphasis>Remember-Me</emphasis> feature, you must add the following section to <filename>components.xml</filename> to ensure that the user is logged in automatically when the application is first accessed:
             </para>
-<programlisting role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
+<programlisting language="XML" role="XML"><![CDATA[<event type="org.jboss.seam.security.notLoggedIn">
   <action execute="#{redirect.captureCurrentView}"/>
   <action execute="#{identity.tryLogin}"/>
 </event>
@@ -465,7 +465,7 @@
                Seam's <literal>ManagedEntityInterceptor</literal> (previously <literal>ManagedEntityIdentityInterceptor</literal>) is now disabled by default. If you need the <literal>ManagedEntityInterceptor</literal> for clustered conversation failover, you can enable it in <filename>components.xml</filename> with the following:
             </para>
           </formalpara>
-<programlisting role="XML"><![CDATA[<core:init>
+<programlisting language="XML" role="XML"><![CDATA[<core:init>
   <core:interceptors>
     <value>org.jboss.seam.core.SynchronizationInterceptor</value>
     <value>org.jboss.seam.async.AsynchronousInterceptor</value>
@@ -508,13 +508,12 @@
             <para>
                The <literal><![CDATA[<s:cache />]]></literal> has not changed, but the <literal>pojoCache</literal> component can no longer be injected. Instead, configure JBoss POJO Cache as your cache provider in <filename>components.xml</filename>, like so:
             </para>
-<programlisting role="XML"><![CDATA[<cache:jboss-pojo-cache-provider />]]>
+<programlisting language="XML" role="XML"><![CDATA[<cache:jboss-pojo-cache-provider />]]>
 </programlisting>
             <para>
                Then, inject it:
             </para>
-<programlisting><![CDATA[@In CacheProvider<PojoCache> cacheProvider;]]>
-</programlisting>
+<programlisting language="Java" role="JAVA">@In CacheProvider&lt;PojoCache&gt; cacheProvider;</programlisting>
             <para>
                The <literal>CacheProvider</literal> provides a Map-like interface. The <literal>getDelegate()</literal> method can then be used to retrieve the underlying cache.
             </para>
@@ -539,7 +538,7 @@
             <para>
                If you configure these objects with <filename>components.xml</filename>, no changes are necessary. If you configure the objects with JavaScript, you must create a value expression as follows:
             </para>
-<programlisting role="JAVA">
+<programlisting language="Java" role="JAVA">
 public ValueExpression getCreatedMessage() {
    return createValueExpression("New person #{person.firstName} 
                                             #{person.lastName} created");




More information about the jboss-cvs-commits mailing list