2.2.2. Changes to Components

Testing
SeamTest now boots Seam at the start of each suite, instead of the start of each class. This improves speed. Check the reference guide if you wish to alter the default.
Changes to DTD and Schema Format
Document Type Declarations (DTDs) for Seam XML files are no longer supported. XML Schema Declarations (XSDs) should be used for validation instead. Any file that uses Seam 2.0 XSDs should be updated to refer to the Seam 2.1 XSDs instead.
Changes to Exception Handling
Caught exceptions are now available in EL as #{org.jboss.seam.caughtException}. They are no longer available in #{org.jboss.seam.exception} form.
Changes to EntityConverter Configuration
You can now configure the entity manager used from the entity-loader component. For further details, see the documentation.
Changes in Managed Hibernate Sessions
Several aspects of Seam, including the Seam Application Framework, rely upon the existence of a common naming convention between the Seam-managed Persistence Context (JPA) and the Hibernate Session. In versions earlier than Seam 2.1, the name of the managed Hibernate Session was assumed to be session. Since session is an overloaded term in Seam and the Java Servlet API, the default has been changed to hibernateSession to reduce ambiguity. This means that, when you inject or resolve the Hibernate Session, it is much easier to identify the appropriate session.
You can use either of these approaches to inject the Hibernate Session:
@In private Session hibernateSession;
@In(name = "hibernateSession") private Session session;
If your Seam-managed Hibernate Session is still named session, you can inject the reference explicitly with the session property:
<framework:hibernate-entity-home session="#{session}".../>
      <transaction:entity-transaction session="#{session}".../>
Alternatively, you can override the getPersistenceContextName() method on any persistence controller in the Seam Application Framework with the following:
public String getPersistenceContextName() {
"session";
}
Changes to Security
The configuration for security rules in components.xml has changed for projects that use rule-based security. Previously, rules were configured as a property of the identity component:
<security:identity security-rules="#{securityRules}" 
      authenticate-method="#{authenticator.authenticate}"/>
Seam 2.1 uses the ruleBasedPermissionResolver component for its rule-based permission checks. You must activate this component and register the security rules with it instead of with the identity component:
<security:rule-based-permission-resolver 
      security-rules="#{securityRules}"/>

Important

The definition of a permission has changed. Prior to Seam 2.1, a permission consisted of three elements:
  • name
  • action
  • contextual object (optional)
The name would typically be the Seam component's name, entity class, or view ID. The action 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:
s:hasPermission('userManager', 'edit', user)
In Seam 2.1, permissions have been simplified so that they contain two elements:
  • target
  • action
The target replaces the name element, becoming the focus of the permission. The action still communicates the intent of the activity to be secured. Within the rules file, most checking now revolves around the target object. For example:
s:hasPermission(user, 'edit')
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.
Additionally, keep in mind that existing rules may behave oddly. This is because, given the following permission check format:
s:hasPermission('userManager', 'edit', user)
Seam transposes the following to apply the new permission format:
s:hasPemrission(user, 'edit')
Read the Security chapter for a complete overview of the new design.
Changes to Identity.isLoggedIn()
This method will no longer attempt to perform an authentication check if credentials have been set. Instead, it will return true if the user is currently unauthenticated. To make use of the previous behavior, use Identity.tryLogin() instead.
If you use Seam's token-based Remember-Me feature, you must add the following section to components.xml to ensure that the user is logged in automatically when the application is first accessed:
<event type="org.jboss.seam.security.notLoggedIn">
      <action execute="#{redirect.captureCurrentView}"/>
      <action execute="#{identity.tryLogin}"/>
      </event>
      <event type="org.jboss.seam.security.loginSuccessful">
      <action execute="#{redirect.returnToCapturedView}"/>
      </event>
Changes to iText (PDF)
The documentStore component has been moved from the external pdf/itext module into Seam itself. Any references to pdf:document-store in components.xml should therefore be replaced with document:document-store. Similarly, if your web.xml references org.jboss.seam.pdf.DocumentStoreServlet, you should change the reference to org.jboss.seam.document.DocumentStoreServlet.
Changes to Clustering
Seam's ManagedEntityInterceptor (previously ManagedEntityIdentityInterceptor) is now disabled by default. If you need the ManagedEntityInterceptor for clustered conversation failover, you can enable it in components.xml with the following:
<core:init>
      <core:interceptors>
      <value>org.jboss.seam.core.SynchronizationInterceptor</value>
      <value>org.jboss.seam.async.AsynchronousInterceptor</value>
      <value>org.jboss.seam.ejb.RemoveInterceptor</value>
      <value>org.jboss.seam.persistence.HibernateSessionProxyInterceptor</value>
      <value>org.jboss.seam.persistence.EntityManagerProxyInterceptor</value>
      <value>org.jboss.seam.core.MethodContextInterceptor</value>
      <value>org.jboss.seam.core.EventInterceptor</value>
      <value>org.jboss.seam.core.ConversationalInterceptor</value>
      <value>org.jboss.seam.bpm.BusinessProcessInterceptor</value>
      <value>org.jboss.seam.core.ConversationInterceptor</value>
      <value>org.jboss.seam.core.BijectionInterceptor</value>
      <value>org.jboss.seam.transaction.RollbackInterceptor</value>
      <value>org.jboss.seam.transaction.TransactionInterceptor</value>
      <value>org.jboss.seam.webservice.WSSecurityInterceptor</value>
      <value>org.jboss.seam.security.SecurityInterceptor</value>
      <value>org.jboss.seam.persistence.ManagedEntityInterceptor</value>
      </core:interceptors>
      </core:init>
Changes to Asynchronous Exception Handling
All asynchronous invocations are now wrapped by exception handling. By default, any exceptions that propagate out of an asynchronous call are caught and logged at the error level. You will find further information in Chapter 21, Asynchronicity and messaging.
Changes to Redeploy Events
The org.jboss.seam.postInitialization event is no longer called upon redeployment. org.jboss.seam.postReInitialization is called instead.
Changes to Cache Support
Cache support in Seam has been rewritten to support JBoss Cache 3.2, JBoss Cache 2 and Ehcache. Further information is available in Chapter 22, Caching.
The <s:cache /> has not changed, but the pojoCache component can no longer be injected.
The CacheProvider provides a Map-like interface. The getDelegate() method can then be used to retrieve the underlying cache.
Changes to Maven Dependencies
The provided platform is now JBoss Enterprise Application Platform 5.1.0, so javaassist:javaassist and dom4j:dom4j are now marked as provided.
Changes to the Seam Application Framework
A number of properties now expect value expressions:
  • entityHome.createdMessage
  • entityHome.updatedMessage
  • entityHome.deletedMessage
  • entityQuery.restrictions
If you configure these objects with components.xml, no changes are necessary. If you configure the objects with JavaScript, you must create a value expression as follows:
        public ValueExpression getCreatedMessage() {
        return createValueExpression("New person #{person.firstName} 
        #{person.lastName} created");
        }