[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3645) Support co-existence of multiple view layers in same deployment

[Clint Popetz (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBSEAM-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clint Popetz updated JBSEAM-3645:
---------------------------------

    Attachment: multi-view-take-2.patch


This is a new patch, replacing the previous.

Parts (2),(3), and (4) in the above description have been moved to separate jira issues.  So this patch now just deals specifically with how the Manager and StatusMessages components are chosen at request-time.

The approach to this is based on a conversation with Pete Muir and on the seam-dev list.    

- There is now a Instantiator base class which knows how to register implementations for a given component.  This class represents most of the work of this patch.  ManagerInstantiator and StatusMessagesInstantiator both extend this.   

- Manager and StatusMessages each extend the Instantiator.RegisteredImplementation class, which provides an @Unwrap method to create/lookup the Instantiator and ask it for the appropriate implementation.

- When the Instatiator<Type> is first created, it fires an event to which each RegisteredImplementation<Type>  listens and registers itself as a possible implementation with the instantiator. 

- When asked for the current implementation, the Instantiator queries each of the registered implementations, calling isActiveImplementation() to determine if it should be chosen for the current contexts.  If two components both return true for this, an exception is thrown.  If no component returns true, the default implementation (which is returned by the type-specific instantiator subclass) is used.  This is for edge cases like testing and initialization-time lookups which have no request.

- Provisions are made to ensure the mechanism is safe for re-entrancy.  

- Once the implementation is chosen, it is saved in the context under the default name, i.e. for a faces request, org.jboss.seam.faces.facesManager will be chosen, and it will be saved as both "org.jboss.seam.faces.facesManager" and "org.jboss.seam.core.manager."  This is important for efficiency, because the lookup of the manager component, for example, can happen hundreds of times for a given request.




> Support co-existence of multiple view layers in same deployment
> ---------------------------------------------------------------
>
>                 Key: JBSEAM-3645
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3645
>             Project: Seam
>          Issue Type: Patch
>            Reporter: Clint Popetz
>            Assignee: Clint Popetz
>         Attachments: multi-view-take-2.patch, multi-view.diff
>
>
> Currently one must choose between wicket and jsf when using seam, because the wicket support works by overriding certain faces components.  This patch eliminates that limitation.
> This patch should be applied after the patches from the issues linked to this issue, which are also related to wicket development.  There are four parts of this patch.  
> (1) The Manager and StatusMessages components are currently implemented in jsf with FacesManager and FacesMessages, and in wicket with WicketManager and WicketStatusMessages.   Since a mixed deployment would need all managers to be @Installed, this patch makes each have a separate @Name, and makes the base classes (Manager and StatusMessages) @Unwrap themselves as one of the subclass components.  Each subclass component registers itself with the base class component (by observing the postInitialization event) as a possible implementation.  When Manager.instance() or StatusMessages.instance() is invoked, and the base component is created, @Unwrap is called, and that method asks each subclass component whether they should be used for that event scope.  The Wicket implementations say yes if the wicket Application.exists() (which uses a ThreadLocal) returns true.  The Faces implementations says yes if facesContext is not null.    This patch assumes that both will not simultaneously return true, and if so, the behavior is undefined, as it's first-come-first-serve.  If neither return true, the default Manager and StatusMessages implementation will be used.  This happens during initialization and other edge cases where a manager is needed for event contexts that aren't tied to real requests.  Note that since the  FacesMessages component no longer has the same @Name as the StatusMessages component, it is now "org.jboss.seam.faces.facesMessages" which means the two factories for that name and its unqualified form in jboss-seam.jar's components.xml have been removed.
> (2) Seam's WicketFilter currently sets up scopes unconditionally if it is installed.  This causes faces requests to fail because the SeamPhaseListener also sets up and tears down scopes, and so when the wicket filter finishes and tries to tear down its scopes, it finds them gone and an exception occurs.  I've changed WicketFilter to not set up scopes, but instead to have WicketFilterInstantiator's anonymous subclass of the real WicketFilter install the scopes _if_ wicket has determined the request is a wicket request.
> (3) WicketExceptionFilter existed only to turn off the base ExceptionFilter for wicket classes.  I've removed this class, and we'll need to add to the wicket seam documentation the need to map the ExceptionFilter in components.xml to jsf paths if wicket is to be used alongside jsf.  
> (4) WicketRedirectFilter now co-exists with the base RedirectFilter, rather than replacing it.  It checks to see if Wicket is active (via the same Application.exists() call as above) before doing any work to redirects, so that it doesn't duplicate work that the jsf RedirectFilter does.  Likewise, The jsf RedirectFilter now checks to see if there is a faces context before doing any work. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira