You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Michael Freedman (JIRA)" <de...@myfaces.apache.org> on 2011/02/08 23:54:57 UTC
[jira] Created: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
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
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12994673#comment-12994673 ]
Leonardo Uribe commented on MYFACES-3039:
-----------------------------------------
The objective of defaultExternalContext is work as a fallback when jsf 1.2 or 1.1 libraries with custom ExternalContext wrapper are used. The idea is if the external wrapper does not implement a method introduced on jsf 2.0, it automatically fallback to the defaultExternalContext implementation.
It is known both myfaces and mojarra has different strategies to handle this case, and there is nothing on the spec related to this behavior.
In jsf 2.0 it was introduced ExternalContextWrapper, so all wrappers must extends from this class.
At the end, in my opinion, it should not be a concern in portlet case. It is a known problem in portlets (it happens with jsf 1.2 and some conditions, that's the reason why orchestra has a jsf 1.2 package). I tried once to comunicate this problem to you personally (in JSFDays) but in that time it was not clear why this detail was important (as now), so in that time I was not taken too seriously and really I don't see how this detail could be on the spec in other way. Note the wrapper solves the problem for future jsf versions.
> 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
> Assignee: Leonardo Uribe
> Fix For: 2.0.5-SNAPSHOT
>
>
> 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
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12993277#comment-12993277 ]
Scott O'Bryan commented on MYFACES-3039:
----------------------------------------
Ahhh yes. Mike, you're one hundred percent right. Pre-JSF 2.0 I don't think we delegated because there was no concept of an ExternalContextFactory. That was set up by the FacesContextFactory. Now, however, the ExternalContextFactory is the "hook point" for the container abstraction. Simply put the FacesContextFactory should not care what objects back the ExternalContext so long as the contracts are followed and, looking at the code above, it is unclear to me why the check is even there.
I suspect that its there because FacesContext used to instantiate externalContext itself (and there clearly used to be a cast to the native objects)..
So yeah, the FacesContext and Factory should be container agnostic for JSF 2.0.
> 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
[jira] Resolved: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leonardo Uribe resolved MYFACES-3039.
-------------------------------------
Resolution: Fixed
> 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
> Assignee: Leonardo Uribe
> Fix For: 2.0.5-SNAPSHOT
>
>
> 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
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992513#comment-12992513 ]
Scott O'Bryan commented on MYFACES-3039:
----------------------------------------
One other idea might be to move a container-neutral implementation of FacesCotextImpl into shared and then put container specific impl's into each container. This will allow us to use a common code base for most Of the FaceContext's stuff, butthen each container can have its own real implementation without Beig dependent on one another.
Further, this would work in Mojarra as well.
> 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
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Michael Freedman (JIRA)" <de...@myfaces.apache.org>.
[ 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
[jira] Reopened: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Michael Freedman (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Freedman reopened MYFACES-3039:
---------------------------------------
Can you clarify what the defaultExternalContext is being used for? On portlet requests this seemingly won't be set/used as its the Bridge's ExternalContext that is in use not the core MyFaces one (which does the attribute put that causes this default stuff to be enabled). Basically, I am trying to ensure there isn't a problem in the portlet env in not participating in this mechanism.
> 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
> Assignee: Leonardo Uribe
> Fix For: 2.0.5-SNAPSHOT
>
>
> 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
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992222#comment-12992222 ]
Leonardo Uribe commented on MYFACES-3039:
-----------------------------------------
I don't understand this one. Could you provide more details about the code you are trying to make it work. For my understanding, MyFaces allows override FacesContext / ExternalContext factories without problem. It has been widely tested, but I know portlet support is a special case.
> 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
[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992286#comment-12992286 ]
Scott O'Bryan commented on MYFACES-3039:
----------------------------------------
I think I disagree with this bug. This limitation is not spec'd in JSF and I'm not even sure it's needed provided MyFaces WORKS with a beige provided FacesContext. The Bridge's FacesContextFactory should be of the 0-parameter sort and should implement its own FacesContext and ExternalContext.
I believe that the FacesContext implementation is fairly trivial. Perhaps we should discuss his some on the list.
> 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
[jira] Resolved: (MYFACES-3039) MyFaces broken in Portlet
environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leonardo Uribe resolved MYFACES-3039.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.5-SNAPSHOT
Assignee: Leonardo Uribe
Ok, now I understand, it is more simple than it seems to be. The check is there just by historical reasons, so we can just comment it and prevent throw the exception. The current FacesContext implementation should work without problem in portlet case.
> 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
> Assignee: Leonardo Uribe
> Fix For: 2.0.5-SNAPSHOT
>
>
> 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