You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@myfaces.apache.org by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org> on 2007/07/31 15:19:53 UTC

[jira] Created: (TRINIDAD-134) StateManagerImpl is not fully compatible with JSR-301

StateManagerImpl is not fully compatible with JSR-301
-----------------------------------------------------

                 Key: TRINIDAD-134
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-134
             Project: MyFaces Trinidad
          Issue Type: Bug
          Components: Portlet
    Affects Versions: 1.2.1-core
            Reporter: Scott O'Bryan
             Fix For: 1.2.2-core


StateManagerImpl has a performance enhancement that is not compatible with JSR-301.  Inside of the popRoot method inside of org.apache.myfaces.trinidadinternal.application.StateManagerImpl, the view root is retrieved using Application.createComponent();.  The JSR-301 bridge has a special UIViewRoot that, due to limitations in the JSF specification, can only reasonably be retrieved through ViewHandler.createViewRoot().  We either need to try to try to retrieve the UIViewRoot using this mechanism OR we need to disable this performance optimization in a portal environment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Updated: (TRINIDAD-134) StateManagerImpl is not fully compatible with JSR-301

Posted by Scott O'Bryan <da...@gmail.com>.

Ahh.  I see how you may be confused.  Consider the following 
requirements of the JSR-301 portlet bridge:

1. Portlet Bridge jars should be optional in environments where the 
Portal is not in place.  In other words, a renderkit can be portlet 
compatible without having to have the bridge jars included in 
non-portlet web applications.

2. Portlet enabled applications may be coded to run both as a portlet 
AND as a servlet.  This means that, where possible, portlet logic is 
only executed when it is run within a portlet.  It also means that 
anything special that is needed to run something in a portlet would not 
preclude running the same code as a servlet.  Obviously this pertains to 
non-portal specific functionality.

3. Try to enable as many existing Faces applications to run as-is in a 
portlet environment as possible.

To accommodate all of these usecases, custom UIViewRoots need to follow 
a select set of requirements according to JSR-301.  If we're in a portal 
environment, however, and the UIViewRoot is the default system view 
root, we wrap the class in a decorator which implements all this stuff 
for you.  This means that when running as a servlet, you get back a 
non-namespaced view root.  When running as a portlet, however, the 
viewroot is a naming container and will handle namespacing.

Does this make sense?

Scott

Scott O'Bryan wrote:
> Andrew,
>
> Faces will not let us do this.  The Portlet UIViewRoot implements a 
> naming container and has some other logic.  What this means is that 
> the Portal's viewRoot needs to be the one being served to the 
> application at the topmost level.  If it's not, we loose the naming 
> container.  This was an issue discussed in JSR-301 EG and this was the 
> best we could come up with.  As it stands now, applications which want 
> to use the standard UIViewRoot need to retrieve the ViewRoot using the 
> ViewHandler OR they need to implement their own naming container.
>
> If you have any ideas about how this could be better supported by 301, 
> let me know and I can take it to the Expert Group.
>
> Scott
>
> Andrew Robinson wrote:
>> >From my understanding:
>>
>> Application.createComponent() is the correct way to create the
>> UIViewRoot. The view handler should use this method internally to get
>> an instance to the view root component. Instead, the bridge should be
>> registering the component type for the special view root in the
>> application, so that calls to createComponent return the one needed
>> for the bridge.
>>
>> -Andrew
>>
>> On 10/18/07, Scott O'Bryan (JIRA) <de...@myfaces.apache.org> wrote:
>>  
>>>      [ 
>>> https://issues.apache.org/jira/browse/TRINIDAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
>>> ]
>>>
>>> Scott O'Bryan updated TRINIDAD-134:
>>> -----------------------------------
>>>
>>>     Status: Patch Available  (was: Open)
>>>
>>>    
>>>> StateManagerImpl is not fully compatible with JSR-301
>>>> -----------------------------------------------------
>>>>
>>>>                 Key: TRINIDAD-134
>>>>                 URL: 
>>>> https://issues.apache.org/jira/browse/TRINIDAD-134
>>>>             Project: MyFaces Trinidad
>>>>          Issue Type: Bug
>>>>          Components: Portlet
>>>>    Affects Versions: 1.2.1-core
>>>>         Environment: JSR-168, JSR-301
>>>>            Reporter: Scott O'Bryan
>>>>            Assignee: Scott O'Bryan
>>>>             Fix For: 1.2.2-core
>>>>
>>>>         Attachments: trinidad-134.patch
>>>>
>>>>
>>>> StateManagerImpl has a performance enhancement that is not 
>>>> compatible with JSR-301.  Inside of the popRoot method inside of 
>>>> org.apache.myfaces.trinidadinternal.application.StateManagerImpl, 
>>>> the view root is retrieved using Application.createComponent();.  
>>>> The JSR-301 bridge has a special UIViewRoot that, due to 
>>>> limitations in the JSF specification, can only reasonably be 
>>>> retrieved through ViewHandler.createViewRoot().  We either need to 
>>>> try to try to retrieve the UIViewRoot using this mechanism OR we 
>>>> need to disable this performance optimization in a portal environment.
>>>>       
>>> -- 
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>>     
>>
>>   
>
>

Re: [jira] Updated: (TRINIDAD-134) StateManagerImpl is not fully compatible with JSR-301

Posted by Scott O'Bryan <da...@gmail.com>.

Andrew,

Faces will not let us do this.  The Portlet UIViewRoot implements a 
naming container and has some other logic.  What this means is that the 
Portal's viewRoot needs to be the one being served to the application at 
the topmost level.  If it's not, we loose the naming container.  This 
was an issue discussed in JSR-301 EG and this was the best we could come 
up with.  As it stands now, applications which want to use the standard 
UIViewRoot need to retrieve the ViewRoot using the ViewHandler OR they 
need to implement their own naming container.

If you have any ideas about how this could be better supported by 301, 
let me know and I can take it to the Expert Group.

Scott

Andrew Robinson wrote:
> >From my understanding:
>
> Application.createComponent() is the correct way to create the
> UIViewRoot. The view handler should use this method internally to get
> an instance to the view root component. Instead, the bridge should be
> registering the component type for the special view root in the
> application, so that calls to createComponent return the one needed
> for the bridge.
>
> -Andrew
>
> On 10/18/07, Scott O'Bryan (JIRA) <de...@myfaces.apache.org> wrote:
>   
>>      [ https://issues.apache.org/jira/browse/TRINIDAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Scott O'Bryan updated TRINIDAD-134:
>> -----------------------------------
>>
>>     Status: Patch Available  (was: Open)
>>
>>     
>>> StateManagerImpl is not fully compatible with JSR-301
>>> -----------------------------------------------------
>>>
>>>                 Key: TRINIDAD-134
>>>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-134
>>>             Project: MyFaces Trinidad
>>>          Issue Type: Bug
>>>          Components: Portlet
>>>    Affects Versions: 1.2.1-core
>>>         Environment: JSR-168, JSR-301
>>>            Reporter: Scott O'Bryan
>>>            Assignee: Scott O'Bryan
>>>             Fix For: 1.2.2-core
>>>
>>>         Attachments: trinidad-134.patch
>>>
>>>
>>> StateManagerImpl has a performance enhancement that is not compatible with JSR-301.  Inside of the popRoot method inside of org.apache.myfaces.trinidadinternal.application.StateManagerImpl, the view root is retrieved using Application.createComponent();.  The JSR-301 bridge has a special UIViewRoot that, due to limitations in the JSF specification, can only reasonably be retrieved through ViewHandler.createViewRoot().  We either need to try to try to retrieve the UIViewRoot using this mechanism OR we need to disable this performance optimization in a portal environment.
>>>       
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>     
>
>

Re: [jira] Updated: (TRINIDAD-134) StateManagerImpl is not fully compatible with JSR-301

Posted by Scott O'Bryan <da...@gmail.com>.

That is, of course, unless you want to implement your own ViewRoot 
according to the JSR-301 spec which is certainly a possibility.

Scott

Michael Freedman wrote:
> As Scott has pointed out, JSR-301 had to make some difficult choices 
> here because of the lack of flexibility in JSF 1.2.  We wanted where 
> ever possible to have the JSF artifact running in a portlet 
> environment to run in a NamingContainer that took the portlet 
> namespace id into account (ensuring proper namespacing in the 
> consumer).  Unfortunately we couldn't come up with a technical 
> solution for wrapping the UIViewRoot.  Because a major philosophy of 
> JSR-301 is to cohabitate with other Faces extensions we felt it was 
> inappropriate to replace any UIViewRoot extension with the special 
> bridge one.  Instead we compromised and said its only safe to replace 
> the UIViewRoot if its the RIs/standard one otherwise we ask the other 
> UIViewRoot implementors to add this NamingContainer feature to their 
> implementation.  The drawback to this is viewHandler.createView needs 
> to get called.     -Mike-
>
> Andrew Robinson wrote:
>> From my understanding:
>>
>> Application.createComponent() is the correct way to create the
>> UIViewRoot. The view handler should use this method internally to get
>> an instance to the view root component. Instead, the bridge should be
>> registering the component type for the special view root in the
>> application, so that calls to createComponent return the one needed
>> for the bridge.
>>
>> -Andrew
>>
>> On 10/18/07, Scott O'Bryan (JIRA) <de...@myfaces.apache.org> wrote:
>>  
>>>      [ 
>>> https://issues.apache.org/jira/browse/TRINIDAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel 
>>> ]
>>>
>>> Scott O'Bryan updated TRINIDAD-134:
>>> -----------------------------------
>>>
>>>     Status: Patch Available  (was: Open)
>>>
>>>    
>>>> StateManagerImpl is not fully compatible with JSR-301
>>>> -----------------------------------------------------
>>>>
>>>>                 Key: TRINIDAD-134
>>>>                 URL: 
>>>> https://issues.apache.org/jira/browse/TRINIDAD-134
>>>>             Project: MyFaces Trinidad
>>>>          Issue Type: Bug
>>>>          Components: Portlet
>>>>    Affects Versions: 1.2.1-core
>>>>         Environment: JSR-168, JSR-301
>>>>            Reporter: Scott O'Bryan
>>>>            Assignee: Scott O'Bryan
>>>>             Fix For: 1.2.2-core
>>>>
>>>>         Attachments: trinidad-134.patch
>>>>
>>>>
>>>> StateManagerImpl has a performance enhancement that is not 
>>>> compatible with JSR-301.  Inside of the popRoot method inside of 
>>>> org.apache.myfaces.trinidadinternal.application.StateManagerImpl, 
>>>> the view root is retrieved using Application.createComponent();.  
>>>> The JSR-301 bridge has a special UIViewRoot that, due to 
>>>> limitations in the JSF specification, can only reasonably be 
>>>> retrieved through ViewHandler.createViewRoot().  We either need to 
>>>> try to try to retrieve the UIViewRoot using this mechanism OR we 
>>>> need to disable this performance optimization in a portal environment.
>>>>       
>>> -- 
>>> This message is automatically generated by JIRA.
>>> -
>>> You can reply to this email to add a comment to the issue online.
>>>
>>>
>>>     
>

Re: [jira] Updated: (TRINIDAD-134) StateManagerImpl is not fully compatible with JSR-301

Posted by Michael Freedman <mi...@oracle.com>.

As Scott has pointed out, JSR-301 had to make some difficult choices 
here because of the lack of flexibility in JSF 1.2.  We wanted where 
ever possible to have the JSF artifact running in a portlet environment 
to run in a NamingContainer that took the portlet namespace id into 
account (ensuring proper namespacing in the consumer).  Unfortunately we 
couldn't come up with a technical solution for wrapping the UIViewRoot.  
Because a major philosophy of JSR-301 is to cohabitate with other Faces 
extensions we felt it was inappropriate to replace any UIViewRoot 
extension with the special bridge one.  Instead we compromised and said 
its only safe to replace the UIViewRoot if its the RIs/standard one 
otherwise we ask the other UIViewRoot implementors to add this 
NamingContainer feature to their implementation.  The drawback to this 
is viewHandler.createView needs to get called. 
     -Mike-

Andrew Robinson wrote:
> From my understanding:
>
> Application.createComponent() is the correct way to create the
> UIViewRoot. The view handler should use this method internally to get
> an instance to the view root component. Instead, the bridge should be
> registering the component type for the special view root in the
> application, so that calls to createComponent return the one needed
> for the bridge.
>
> -Andrew
>
> On 10/18/07, Scott O'Bryan (JIRA) <de...@myfaces.apache.org> wrote:
>   
>>      [ https://issues.apache.org/jira/browse/TRINIDAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Scott O'Bryan updated TRINIDAD-134:
>> -----------------------------------
>>
>>     Status: Patch Available  (was: Open)
>>
>>     
>>> StateManagerImpl is not fully compatible with JSR-301
>>> -----------------------------------------------------
>>>
>>>                 Key: TRINIDAD-134
>>>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-134
>>>             Project: MyFaces Trinidad
>>>          Issue Type: Bug
>>>          Components: Portlet
>>>    Affects Versions: 1.2.1-core
>>>         Environment: JSR-168, JSR-301
>>>            Reporter: Scott O'Bryan
>>>            Assignee: Scott O'Bryan
>>>             Fix For: 1.2.2-core
>>>
>>>         Attachments: trinidad-134.patch
>>>
>>>
>>> StateManagerImpl has a performance enhancement that is not compatible with JSR-301.  Inside of the popRoot method inside of org.apache.myfaces.trinidadinternal.application.StateManagerImpl, the view root is retrieved using Application.createComponent();.  The JSR-301 bridge has a special UIViewRoot that, due to limitations in the JSF specification, can only reasonably be retrieved through ViewHandler.createViewRoot().  We either need to try to try to retrieve the UIViewRoot using this mechanism OR we need to disable this performance optimization in a portal environment.
>>>       
>> --
>> This message is automatically generated by JIRA.
>> -
>> You can reply to this email to add a comment to the issue online.
>>
>>
>>