[
https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992575#comment-12992575
]
Michael Freedman commented on MYFACES-3039:
-------------------------------------------
I have to respectively disagree. The only servlet dependency I see in the
MyFaces FacesContextImpl I see is in the "special" constructor code used to
self create an external context. Isn't this a holdover from the JSF 1.2
pattern? In JSF 2.0 things were reorganized so the ExternalContext is
constructed from a factory and passed to the FacesContext constructor -- ala:
FacesContext ctx =
new FacesContextImpl(
externalContextFactory.getExternalContext(sc, request,
response),
lifecycle);
This allows the FacesContext to be environment neutral (all environmental stuff
is within the ExternalContext) -- and with the new FacesContext wrapper its now
easy for the bridge to wrap the core context and only override the few method
it changes.
What is the rationale for the MyFaces model and runtime dependency? If some of
that rationale needs to be maintained, can't it be isolated to the circumstance
it pertains to and the more general pattern (runtime neutral) be utilized in
other cases (like the bridge)?
Basically, what I am arguing is that the model supported by the spec and
implemented by Mojarra seems to be a general/broad model and should be
supported by MyFaces -- and if improvements can be made for specific
situations, so be it, but handle as such without penalizing the general.
> MyFaces broken in Portlet environment: Fails to support extendable
> FacesContextFactory/FacesContext/ExternalContext
> --------------------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-3039
> URL: https://issues.apache.org/jira/browse/MYFACES-3039
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
> Reporter: Michael Freedman
>
> JSF 2.0 improved the definition/handling of the instantiation of the
> FacesContext allowing non-servlet environments to wrap the base/core impl.
> This was done because most of the FacesContext apis are inherently runtime
> environment neutral -- allowing the portlet bridge to not have to
> duplicate/reimplement and maybe get wrong base core function. Unfortunately
> MyFaces doesn't conform to this change and hence the Portlet Bridge can't run
> in the MyFaces environment.
> Basically the bridge expects to be able to delegate from its
> FacesContextFactoryImpl.getFacesContext and then wrap the returned
> FacesContext with its own. This requires the underlying core impl to be
> runtime (servlet/portlet) neutral during the creation process. The bridge
> will wrap the FacesContext and supply its own ExternalContext such that any
> servlet dependent impl in the core FacesContext/ExternalContext will be
> hidden by overrides.
> FYI ... until this is addressed I can't begin any testing of the bridge on
> MyFaces.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
