<< Back to previous view

[JAVASERVERFACES_SPEC_PUBLIC-909] I18N - improve case where locale info is dropped using redirect or GET request Created: 15/Nov/10  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.3

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 909
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns and sheetalv

 Description   

Craig and Peter can provide more information - this was seen as part
of using creator by customers using i18n features and multiple locales.

For JSF, the architectural issue is that the locale selected by the
user (or the application) is dropped under two circumstances:

  • When a redirect is used to navigate from one page to another
  • When a GET request is used (such as when you use the
    "Bookmarkable URLs" technique

for creator, what is needed is to support changing the locale at runtime for
the whole user-session (i.e. all user-pages) out-of-the-box. It seems
that this is currently not supported if the application
has multiple pages and redirects are used between page-transitions.

      • (#1 of 1): 2006-05-03 12:00:21 EDT ken.frank@sun.com

Taken over from CR6421300



 Comments   
Comment by sheetalv [ 16/Nov/10 01:53 PM ]

target

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-872] The View Metadata tag is not processed unless at least one <f:viewParam> is defined Created: 29/Jul/10  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Critical
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 872
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: arjan tijms, Ed Burns, lincolnbaxter and rogerk

 Description   

Section 2.2.1 of the JSF 2 spec requires that if no view-parameters exist in the
view-metadata, that the render response phase be invoked immediately following
the current phase on a GET request. This prevents custom metadata from being
provided that may require lifecycle processing (view-actions, for example.)

This is a hindrance to creating custom metadata-since even if a tool (such as
prettyfaces) wishes to add custom url-parameter handling (or custom action
invocation), it must also add an empty view-param in order to trigger the
lifecycle. Also, not many people expect this behavior, since it is relatively
counter-intuitive.

I propose defining a new contract that would allow for individual meta-data
components to determine whether or not the full lifecycle should be invoked:

public interface ViewMetadata {
/**

  • If true, the full faces lifecycle will be invoked; if false, the
  • lifecycle will skip directly to render-response, unless another
  • {@link ViewMetadata} object requests that the lifecycle be executed.
    */
    public boolean requiresLifecycle();
    }

This new contract would still honor the behavior of previous implementations,
and should be mostly backwards compatible (because unless the custom tag
requests the lifecycle, it will still be skipped.)

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. Call
ViewMetadata.getViewParameters(). If the result is a non-empty Collection, do
not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."



 Comments   
Comment by lincolnbaxter [ 29/Jul/10 08:26 AM ]

I'd like to revise my proposal; I now oppose my original suggestion of adding a
new interface:

Solution:

It's possible we could just get away with changing the verbiage a little bit in
order to resolve this issue, thereby avoiding changes to any existing, or adding
any new APIs. (Note the **starred** change.) The change is very subtle, and
not very invasive, but perfectly addresses this situation.

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getViewParameters()***. If the result is a non-empty Collection,
do not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Proposed verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getChildren()***. If the result is a non-empty Collection, do not
call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Comment by rogerk [ 27/Oct/10 02:32 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

Bulk assign all of Sheetal's spec issues to me.

Comment by arjan tijms [ 20/Mar/13 03:56 PM ]

I think this is an exact duplicate of JAVASERVERFACES_SPEC_PUBLIC-762.





[JAVASERVERFACES_SPEC_PUBLIC-1176] Separate implicit bean navigation from action method via additional outcome attribute Created: 18/Mar/13  Updated: 22/Mar/13

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: djmj Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: action outcome separate view logic
Participants: djmj, Ed Burns and Manfred Riem

 Description   

The submit/command components: 'commandButton' and 'commandLink' use implicit navigation via their 'action' attribute and the returned String in the bean method that is invoked and referenced from the 'action' attribute.

Why is the navigation outcome handled in the called method of the bean and not within the the view?
Should the view not be as much separated from the logic as possible, especially if reusing code.

Adding the 'outcome' attribute of the 'button' and 'link' components to the related command components 'commandButton' and 'commandLink' would resolve this issue.

If the command component is invoked by the user the method of its 'action' attribute is called and navigates to the target defined in its 'outcome' attribute.

<h:commandButon action="#{bean.method()}" outcome="/index.xhtml"/>

Currently I used a workaround by adding my own outcome via an 'f:param' to my command, since for the few cases where I used bean-navigation the logic had to be reusable and not be bound to a specific view or application.



 Comments   
Comment by Manfred Riem [ 18/Mar/13 10:31 PM ]

Thank you for suggesting a new feature.

Note that feature requests that change existing behavior or add to it
need to be filed at the JAVASERVERFACES_SPEC_PUBLIC issue tracker.

Can you file the issue there? Thank you!

Comment by djmj [ 21/Mar/13 11:26 PM ]

I got an email that it was moved automatically to public issue tracker.

Is the closed status because of the wrong issue tracker?

So should it not be reopened, or is the issue itself invalid?

Comment by Ed Burns [ 22/Mar/13 12:43 AM ]

Re-open.





[JAVASERVERFACES_SPEC_PUBLIC-960] View params do not support multiple values Created: 01/Apr/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-2230 Add <f:viewParams> for parameters wit... Closed
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns and Mathias Werlitz

 Description   

HTTP allows multiple values for a request parameter so view params should do the same. <f:viewParam> should support a List or array as the target type of the value.

Maybe a new component <f:viewParams> should be introduced that behaves a bit like <h:select...>, but limiting the possible values may not be required in every case.



 Comments   
Comment by Ed Burns [ 06/Jun/11 05:35 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-1149] Add method getCurrentViewScope() to javax.faces.application.ViewHandler Created: 28/Nov/12  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 13
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Neil Griffin

 Description   

Currently, the javax.faces.flow.FlowHandler class has an abstraction that hides the CDI dependency of Mojarra's @FlowScoped annotation:

public abstract class FlowHandler { ... public abstract Map<Object, Object> getCurrentFlowScope(); ... }

This is quite helpful, because it provides JSF Portlet Bridges with the ability to decorate the FlowHandler.getCurrentFlowScope() method with an implementation that doesn't depend on CDI. (CDI+Portlet integration hasn't been formally defined yet at the JSR level).

But the same cannot be said for the new javax.faces.flow.ViewScoped annotation. In order to remedy this, I would like to propose that the following method signature be added to the javax.faces.application.ViewHandler class:

public abstract class ViewHandler { ... public abstract Map<Object, Object> getCurrentViewScope(); ... }






[JAVASERVERFACES_SPEC_PUBLIC-1093] The id attribute of javax.faces.ViewState is not unique Created: 01/May/12  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dmsinotte Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any


File Attachments: Zip Archive viewstate.zip    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-790 javax.faces.ViewState + PPR does not ... Open
Tags:
Participants: dmsinotte, Ed Burns and tedgoddard

 Description   

As per the work done for this spec change, http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-220, the id of each hidden ViewState element is supposed to be unique on the page. This should hold true for multiple forms in a single view as well as multiple views on the page (e.g. portlets). The documentation in ResponseStateManager indicates that this should be done by setting the id to be:

namingContainerId:javax.faces.ViewState:counterUniqueToView

I have attached a test case which has two forms on it. The resulting ViewState elements both have identical ids:

ViewState for form1: j_id1:javax.faces.ViewState:0
ViewState for form2: j_id1:javax.faces.ViewState:0

The counter is not incremented and the id of the form (which should be the naming container in this case) is not used.

Also, I noticed that the method for getting the ViewState id is com.sun.faces.util.Util.getViewStateId(FacesContext fc). For those of us working on extending the framework who might need access to the information in their own renderers, will there be a way to get at the information in a more public way?



 Comments   
Comment by tedgoddard [ 03/May/12 04:25 PM ]

(First of all, javax.faces.ViewState should not be modified for Ajax updates using server-side state-saving, but this simple approach does not appear to be the current direction.)

We are a bit unclear on how the current implementation is intended to work, but expect that something like the following is necessary:

When the request is submitted, call getElementsByName('javax.faces.ViewState') and store the list of IDs for all with equal value to that of the javax.faces.ViewState in the submitting form. In the case of future JSP inclusion or current Portlets, there will be javax.faces.ViewState fields not associated with the current view. They will have different values and are not included in the list.

When the partial response is generated, it may contain rendered hidden inputs with name javax.faces.ViewState and unique IDs, but also contains the special case <update id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously stored list of IDs are now all updated to use the new value. Any javax.faces.ViewState hidden fields that have been modified by the page update itself (potentially now having different IDs) have the correct value anyway because they were just updated.

Comment by Ed Burns [ 03/May/12 06:35 PM ]

TG> (First of all, javax.faces.ViewState should not be modified for Ajax
TG> updates using server-side state-saving, but this simple approach
TG> does not appear to be the current direction.)

Can you please elaborate more on what you mean by this? The issue
doesn't mention anything about Ajax specifically. Is this a separate
concern you are raising, Ted?

TG> We are a bit unclear on how the current implementation is intended
TG> to work, but expect that something like the following is necessary:

TG> When the request is submitted, call
TG> getElementsByName('javax.faces.ViewState') and store the list of IDs
TG> for all with equal value to that of the javax.faces.ViewState in the
TG> submitting form. In the case of future JSP inclusion or current
TG> Portlets, there will be javax.faces.ViewState fields not associated
TG> with the current view. They will have different values and are not
TG> included in the list.

TG> When the partial response is generated, it may contain rendered
TG> hidden inputs with name javax.faces.ViewState and unique IDs, but
TG> also contains the special case <update
TG> id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously
TG> stored list of IDs are now all updated to use the new value. Any
TG> javax.faces.ViewState hidden fields that have been modified by the
TG> page update itself (potentially now having different IDs) have the
TG> correct value anyway because they were just updated.

These two comments are better suited to JAVASERVERFACES_SPEC_PUBLIC-790,
so I'll copy them there. Ted, can you please take a look at 790 and see
if you agree that your comments pertain more to that issue than this
one?





[JAVASERVERFACES_SPEC_PUBLIC-1135] Add PostRenderViewEvent Created: 04/Oct/12  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File i_spec_1135-draft.patch    
Tags:
Participants: arjan tijms and kithouna

 Description   

In JSF 2.0 a PreRenderViewEvent was added that is published just before a view is rendered, but there's no corresponding event published just after rendering a view.

There are several alternatives for this, but none of them is really perfect. A per-view PhaseListener can be used, but it fires relatively early and sticks around after a post-back which may be undesirable. A global PhaseListener that picks up a delegating listener in request scope is another option that does work, but is not as intuitively clear (we use this approach in OmniFaces' CallbackPhaseListener).

I therefor propose to add a PostRenderViewEvent that is published right after a view is rendered.

Among the use cases for such an event is doing per request clean-ups; for instance a view scoped backing bean where a value is set such that for one particular request an item is rendered with some emphasis and then after the first post-back rendered normally again.



 Comments   
Comment by arjan tijms [ 04/Oct/12 10:39 PM ]

Draft of PostRenderViewEvent implementation including rudimentary test.

Comment by kithouna [ 07/Mar/13 09:20 AM ]

Would be great if this can still be put in JSF 2.2. Seems to be a very trivial thing.

Comment by kithouna [ 14/Mar/13 09:29 AM ]

On second thoughs, don't add this to JSF 2.2 for the mere reason that the team should focus 100% on polishing and finishing work that has already started and should not do anything new for 2.2.

For 2.3 this would be really great though





[JAVASERVERFACES_SPEC_PUBLIC-1040] Outstanding PhaseListener.afterPhase() calls for the current phase should be made before any requested redirect actually takes place Created: 19/Oct/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle, Navigation
Affects Version/s: 2.1
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Matt Benson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Matt Benson

 Description   

See email thread beginning at http://java.net/projects/javaserverfaces/lists/dev/archive/2011-10/message/5 .






[JAVASERVERFACES_SPEC_PUBLIC-912] FacesMessage.Severity should be Serializable Created: 15/Nov/10  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 912
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Ed Burns and ramiromagalhaes

 Description   

A DESCRIPTION OF THE REQUEST :
FacesMessage.Severity is a typesafe enumeration with the meaning to describe the
severity of an error message displayed using JSF. As a typesafe enumeration, it
is basically a simple class reference without any transient meaning. This class
is unfortunately not serializable.

JUSTIFICATION :
In order to create error pages which contain jsf style error descriptions (a
summary, a detail, and a severity), it can be clever to add a FacesMessage as a
managed bean with e.g. session scope. As such, it will fail a web session to be
serialized e.g. in failover or server redeployment situations.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Make it serializable. Implement FacesMessage.Severity.readResolve as described
in Joshua Bloch, Effective Java Programming Language Guide, 2001, Addison
Wesley, Item 21.

CUSTOMER SUBMITTED WORKAROUND :
Store two strings regarding the error description. Hardcode or otherwise encode
the severity.

(Due to the construction of FacesMessage, you cannot instantiate it with a null
Severity field without encountering a NPE)

      • (#1 of 1): 2005-09-20 22:30:34 EDT girish.manwani@sun.com


 Comments   
Comment by ramiromagalhaes [ 14/Apr/11 09:49 AM ]

This is a duplication of JAVASERVERFACES_SPEC_PUBLIC-921.

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-897] New getSessionId() for ExternalContext Created: 15/Oct/10  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: nick_belaevski Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 897
Status Whiteboard:

size_small importance_small

Tags:
Participants: Ed Burns, nick_belaevski and rogerk

 Description   

Please add getSessionId() method for ExternalContext. It's useful to provide
session handling for Flash-based components.



 Comments   
Comment by rogerk [ 27/Oct/10 02:42 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-871] Need events before and after the entire JSF lifecycle processing Created: 26/Jul/10  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 871
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, lincolnbaxter and rogerk

 Description   

In order to facilitate custom contexts and other extensions, it would be helpful
if there were events to mark the beginning and end of the JSF lifecycle.

PreExecuteLifecycleEvent
PostExecuteLifecycleEvent

This would enable bean/transaction/security creating/interception at a time that
is independent of phase listeners, which present ordering problems when users
create custom phase listeners, and also cause issues when dealing with exception
handling, since exception handlers are created outside of the faces lifecycle:

https://jira.jboss.org/browse/SEAMFACES-42



 Comments   
Comment by rogerk [ 27/Oct/10 02:29 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-816] ViewHandler.initView() called too late Created: 28/May/10  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: michael_kurz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 816
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, michael_kurz and rogerk

 Description   

In my examples I have a phase listener that outputs all request parameters . I
accidentially did this before restore view and got some strange behaviour. With
MyFaces 2.0, reading the request parameters before the restore view phase kills
german umlauts. This happens because the character encoding is calculated and
set in the request at the beginning of restore view but after the before phase
listeners are executed.

As this is not happening with Mojarra, I set a breakpoint in
ServletRequest.setCharacterEncoding and saw that they are setting this somewhere
at the beginning of the lifecycle.

The spec says the following about this problem:

*) Spec section 2.2.1: "The JSF implementation must perform the following tasks
during the Restore View phase of the request processing lifecycle: Call
initView() on the ViewHandler. This will set the character encoding properly for
this request. ....."

*) Spec section 7.5.1: "The initView() method must be called as the first method
in the implementation of the Restore View Phase of the request processing
lifecycle, immediately after checking for the existence of the FacesContext
parameter...."

In my understanding, the phase listeners belong to the lifecycle and not to the
phases. This would mean that according to the spec ViewHandler.initView() should
be called AFTER the invocation of the before phase listeners, which is too late.



 Comments   
Comment by Ed Burns [ 22/Jun/10 09:05 PM ]

sheetalv

Comment by rogerk [ 27/Oct/10 02:24 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-675] Allow for multiple system-event-class elements in an listener Created: 24/Nov/09  Updated: 23/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: nickarls Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 675
Status Whiteboard:

cat2 javadoc size_medium importance_medium

Tags:
Participants: Ed Burns, nickarls and rogerk

 Description   

Since system-event-class:es aren't applicable for SystemEvent, it would be handy
to be able to register all (six?) direct subclasses to a single "catch all" system
event listener in faces-config.xml



 Comments   
Comment by Ed Burns [ 04/Mar/10 01:58 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:25 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:11 PM ]

triage. Also, the performance implications of fixing this must be addressed.

Comment by Ed Burns [ 22/Jun/10 09:05 PM ]

sheetalv

Comment by rogerk [ 27/Oct/10 01:14 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-581] New getRequestMethod() for ExternalContext Created: 01/Jul/09  Updated: 24/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: Ryan Lubke Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 581
Status Whiteboard:

cat2 javadoc size_small importance_medium

Tags:
Participants: Ed Burns, rogerk and Ryan Lubke

 Description   

Please add getRequestMethod() for ExternalContext. We need to distinguish between
GET/HEAD when servicing resources.



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 24/Feb/10 09:50 AM ]

Disagree for 2.0 Rev a. Cause TCK change.

Comment by rogerk [ 05/Mar/10 07:55 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:01 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 18/Jun/10 03:10 AM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:05 PM ]

sheetalv

Comment by rogerk [ 27/Oct/10 12:26 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-510] Expose the MessageFactory API Created: 20/Nov/08  Updated: 24/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: driscoll Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAVASERVERFACES-721 Expose the MessageFactory Closed
Issuezilla Id: 510
Status Whiteboard:

cat2 javadoc size_medium importance_large draft

Tags:
Participants: driscoll, Ed Burns, kito75 and rogerk

 Description   

We should expose the MessageFactory API publicly - either by changing the spec,
or as part of our API.

Justification: I've found that several books and websites offer utilities to
get around this lack of functionality - it's commonly needed if you're writing
any internationalized component. Also, I've heard its a commonly requested
feature on the IRC channel.



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 12:38 PM ]

I said to Craig we should do this in 2003.

Comment by Ed Burns [ 04/Mar/10 01:36 PM ]
      • Issue 496 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Mar/10 10:53 AM ]

javadoc

Comment by Ed Burns [ 22/Mar/10 11:06 AM ]

lifecycle

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 09:19 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:05 PM ]

sheetalv

Comment by rogerk [ 27/Oct/10 12:20 PM ]

triage

Comment by kito75 [ 20/Apr/11 08:30 AM ]

Any time people have to re-invent a utility class in every project, you know it should be start of the standard API. This has been annoying me for a long time, too.

We should consider another take on this, like MyFaces CODI's message context https://cwiki.apache.org/EXTCDI/message-intro.html or Seam's messages http://docs.jboss.org/seam/3/international/latest/reference/en-US/html_single/#international.messages

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-473] FacesEvent should have a convenience getFacesContext() method. Created: 23/Sep/08  Updated: 24/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 473
Status Whiteboard:

EGEasy5 effort_easy cat2 javadoc sig size_small importance_small

Tags:
Participants: Ed Burns, kito75, rogerk and sheetalv

 Description   

FacesEvent should have a convenience getFacesContext() method. This is very
useful for event listeners.

I'm not sure, but SystemEvent could probably use this method too.



 Comments   
Comment by Ed Burns [ 23/Sep/08 09:53 AM ]

EGEasy5 effort_easy edburns

Comment by Ed Burns [ 15/Oct/08 06:43 AM ]

Change target milestone to 2.0

Comment by Ed Burns [ 10/Aug/09 01:55 PM ]

This didn't make it.

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 07:30 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 10:49 AM ]

javadoc

Comment by Ed Burns [ 27/Apr/10 09:03 AM ]

sig change

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:57 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 01:32 PM ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 12:39 PM ]

triage - api





[JAVASERVERFACES_SPEC_PUBLIC-240] more events from the framework Created: 07/Feb/07  Updated: 24/Jan/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: ajesse Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: Text File message.txt     Text File message.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-433 Support "view controllers" Resolved
Issuezilla Id: 240
Status Whiteboard:

EGTop5 effort_moderate cat2 frame size_medium importance_large draft

Tags:
Participants: ajesse, Ed Burns and Ryan Lubke

 Description   

Often it would be usefull be able to attach a event-listener to the jsf-
framework. But the framework does not fire events...
Eg: after successfull initialization I would like to get a event with a
reference to the completed runtime-config > I could register used custom
components (eg. for license fees), during dev: dump out the complete config-info
Or: after a successfull component-tree-creation a event carying a reference to
the component-tree -> I could check whether I need to inject some values into
managed beans used in the components in the tree (an idea for a http-GET
interface)

Most probably other events might prove usefull as well...



 Comments   
Comment by Ed Burns [ 06/Mar/07 11:31 AM ]

This issue is already on the list of issues to be addressed in JSF 2.0.

Comment by Ed Burns [ 12/Feb/08 01:05 PM ]

Created an attachment (id=123)
First part of fixing this bug, first iteration.

Comment by Ed Burns [ 12/Feb/08 02:59 PM ]

Created an attachment (id=124)
First part of fixing this bug, second iteration.

Comment by Ed Burns [ 20/Feb/08 11:05 AM ]

290 blocks this.

Comment by Ryan Lubke [ 20/Aug/08 02:11 PM ]

Depends on 178.

Comment by Ryan Lubke [ 20/Aug/08 02:12 PM ]

Adding 443 as dependency.

Comment by Ryan Lubke [ 20/Aug/08 02:24 PM ]

Also consider a ComponentCreatedEvent.

Comment by Ryan Lubke [ 09/Sep/08 10:13 AM ]

Request from a 314 observer:

---------------------------------------

I did not able to send this email to JSR-314 EG because not member of
it. But I think maybe useful to add two other listener
and event to the Kito D. listener list; these are

  • ConverterInvokedEvent/ConverterInvokedListener

public ConverterInvokedListener extends EventListener{ public void beforeConverterInvoked(ConverterInvokedEvent event) ; public void afterConverterInvoked(ConverterInvokedEvent event); }

public ConverterInvokedEvent extends EventObject{ public FacesContext getContext(); public String getEventType(); //Before or After public boolean isExceptionThrown(); //If converter exception throws public ConverterException getException(); public UIComponent getComponent(); }

  • ValidatorInvokedEvent/ValidatorInvokedListener

public ValidatorInvokedListener extends EventListener{ public void beforeValidatorInvoked(ValidatorInvokedEvent event) ; public void afterValidatorInvoked(ValidatorInvokedEvent event); }

public ConverterInvokedEvent extends EventObject{ public FacesContext getContext(); public String getEventType(); //Before or After public boolean isExceptionThrown(); //If converter exception throws public ValidatorException getException(); public UIComponent getComponent(); }

Comment by Ed Burns [ 13/Oct/08 07:37 AM ]

Will mark 491 as dup of this.

Comment by Ed Burns [ 13/Oct/08 07:38 AM ]
      • Issue 491 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 06/Feb/09 01:17 PM ]

ConverterInvokedEvent

I assert that we don't need this since we have the validate events.

ComponentCreatedEvent

I assert that we don't need this because you could decorate Application
and override its createComponent* methods.

Comment by Ed Burns [ 03/Apr/09 05:31 AM ]

We should have system events for pre and post every lifecycle phase.

Comment by Ed Burns [ 30/Jun/09 10:26 AM ]

From: Gurkan Erdogdu <gurkanerdogdu@yahoo.com>
Sender: dev-return-1710-ed.burns=sun.com@javaserverfaces.dev.java.net
To: dev@javaserverfaces.dev.java.net
Subject: Re: [240-Megalisteners] Naming
Date: Mon, 14 Apr 2008 10:02:33 -0700 (PDT)
Content-type: multipart/alternative;
boundary="Boundary_(ID_uuZw7vnbr+OC0VpICackyA)"
MIME-version: 1.0

Yeap. If not getting exception than able to get this from event.

public void beforeConverterInvoked(ConverterInvokedEvent event){
public Object getLocalValue(); // Gets the local, unconverted value
}

public void afterConverterInvoked(ConverterInvokedEvent event){
public Object getConvertedValue(); //Gets the converted value after conversion
}

Thanks;

Gurkan

Comment by Ed Burns [ 24/Sep/09 08:17 AM ]

Move to 2.1

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by Ed Burns [ 02/Mar/10 05:14 PM ]

At JSFdays last week, Leonardo Uribe suggested we add events for iterating components. Iteration
begin, etc.

Comment by Ed Burns [ 04/Mar/10 12:45 PM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:14 PM ]

frame

Comment by Ed Burns [ 22/Mar/10 06:36 AM ]

lifecycle

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 01:52 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 02:55 PM ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 12:11 PM ]

Move these to 2.2

Comment by Ed Burns [ 23/Sep/10 09:15 AM ]

Another event that we need is one that allows the installation of a client side JavaScript listener that will be
called, on the client side when the user tries to navigate away from the current view. The listener must
have the ability to veto the navigation. This feature could be used to allow developers to throw up a modal
dialog saying something like, "you have unsaved changes in this page, are you sure you want to discard
them?" and have the chance to cancel the navigation.





[JAVASERVERFACES_SPEC_PUBLIC-437] Immediately process update HtmlInputHidden values during conversion/validation phase Created: 11/Aug/08  Updated: 11/Feb/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Jason Lee Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 437
Status Whiteboard:

cat2 frame javadoc size_medium importance_small

Tags:
Participants: Ed Burns, Jason Lee, kito75, rogerk and sheetalv

 Description   

Requested by use balusc
(https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=765):

Imagine a request scoped bean with a h:inputHidden field and another UIInput
field which is to be converted and/or validated. If the h:inputHidden already
has a value but the conversion and/or validation of the another UIInput field
fails, then the value of the h:inputHidden will get lost.

Truly, this is behaviour by specification, but it is not very intuitive. One
would expect that hidden input values (read: the values which aren't to be
filled in by the client, but by the server) should retain its value. In real
world web applications the sole purpose of hidden input elements is to transfer
values from request to request without any client interaction.

Thus, hereby my request for an enhancement in the API: make sure that the API
retains hidden input values regardless of the global outcome of the
conversion/validation phase. And only if the hidden input value itself is
already successfully converted and validated.

In theory this can simply be achieved by adding the following lines at the
bottom of the if (isValid()) {} block which starts at line 887 of
javax.faces.component.UIInput in 2.0.0 EDR1:

if (this instanceof HtmlInputHidden) { processUpdates(context); }

If necessary you can also let it implement a certain marker interface, e.g.
RetainableValueHolder or so (I just say something) so that one can decide to let
some custom component implement it.

I am almost sure that this will be greatly appreciated by the web development
world. It is certainly much more intuitive. And it is much more elegant than the
'workaround' to bind the h:inputHidden and using the UIInput#getValue() /
setValue() instead.



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by kito75 [ 24/Feb/10 08:34 AM ]

This is probably more complicated than it seems, because it's quite possible
that JavaScript code could be updating a hidden field, in which case we would
want the updates to occur.

What is the use case for attaching a value to both a hidden field and a field
with validation?

Comment by kito75 [ 24/Feb/10 08:40 AM ]

I re-read this, and I now I understand it more clearly. Wouldn't using
immediate="true" solve this problem?

Bypassing validation/conversion is generally not a good idea.

Comment by kito75 [ 24/Feb/10 08:41 AM ]

Changed subcomponent to validation/conversion.

Comment by rogerk [ 05/Mar/10 07:25 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 10:46 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:32 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:05 PM ]

sheetalv

Comment by rogerk [ 27/Oct/10 11:03 AM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

Bulk assign all of Sheetal's spec issues to me.

Comment by Ed Burns [ 24/Jan/14 09:23 PM ]

Are JAVASERVERFACES_SPEC_PUBLIC-{575,437} [1] solved by the cancel button work
we did in JSF 2.2? I think they might be.

Can you please take a look and check?

Thanks,

Ed

Comment by Ed Burns [ 11/Feb/14 06:58 PM ]

Cagatay got back to me and confirmed this was not resolved by that work.

Will target to 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-1216] Inconsistent exception handling for phaselisteners Created: 14/Aug/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: frederickkaempfer

 Description   

Exception handling for phase listeners behaves differently depending on if they are registered globally in faces-config.xml or with f:phaseListener for a particular view root.

In the first (global) case any exception thrown by them gets forwarded to an exception handler as described in the spec.

In the second (per view root) case all exceptions get logged and swallowed as described in the UIViewRoot documentation.

This inconsistent behavior adds increased complexity when implementing PhaseListeners. Ideally both cases should forward any exception to the exception handler so they can be handled there.

See also the discussion of the problem in: https://java.net/jira/browse/JAVASERVERFACES-2985






[JAVASERVERFACES_SPEC_PUBLIC-559] Support for the "Synchronizer Token" pattern (avoiding double submits) Created: 05/May/09  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 11
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


File Attachments: File jsf2csrf.war     File jsf2token.war    
Issuezilla Id: 559
Status Whiteboard:

cat2 frame size_medium importance_large cat3 draft

Tags:
Participants: Ed Burns, joshbrookes, kito75, rogerk and sheetalv

 Description   

This is a very common web application problem
(http://www.javajunkies.org/index.pl?lastnode_id=3361&node_id=3355) – avoiding
double submits. Struts had built-in support for this. JSF-related implementations:

Spring Web Flow, Struts 2, and Grails 1.1
(http://www.grails.org/1.1+Release+Notes) also support this natively.

I'd really like to see this in JSF 2.1 at the very latest.



 Comments   
Comment by Ed Burns [ 11/Aug/09 12:46 PM ]

Move to 2.1. Also make this handle Dan's concern here:

DA> It's crucial that the enablement of this feature be accompanied by a
DA> secure token being exchanged in the case of server-side state
DA> saving.

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 07:49 AM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:12 PM ]

lifecycle

Comment by Ed Burns [ 07/May/10 10:57 AM ]

Transaction token has been requested many times over the years.

Comment by kito75 [ 08/May/10 12:40 PM ]

I've got some code I wrote for a client based on Shale's token that I can clean up and submit as a
prototype. If you're interested, just let me know when it's time.

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:48 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 02:52 PM ]

xsrf

Security related, target for GlassFish 3.1 M3

Comment by Ed Burns [ 30/Jun/10 05:58 PM ]

cat3

Comment by rogerk [ 01/Jul/10 05:41 AM ]

Hey Kito -

It's time. Let's see what you have. If you can also submit a proposal that
would be helpful as well.

-roger

Comment by rogerk [ 01/Jul/10 05:47 AM ]

This could probably reside in the core namespace - like f:token ?

Comment by Ed Burns [ 01/Jul/10 06:47 AM ]

Roger, please take a look at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812 for more
valuable information.

Comment by rogerk [ 01/Jul/10 12:26 PM ]

Ahh yes - thanks for the pointer. Apparently there are many ways to skin this
cat ....

Comment by kito75 [ 14/Jul/10 10:06 AM ]

Created an attachment (id=255)
Sample CSRF Solution (JSF 1.2)

Comment by kito75 [ 14/Jul/10 10:19 AM ]

Created an attachment (id=256)
Sample CSRF Solution (JSF 1.2) – the other file is for avoiding double submits

Comment by kito75 [ 14/Jul/10 10:38 AM ]

I have attached two samples:

  • jsf2token.war – sample UIToken component specifically for avoiding double submits (but would
    probably handle CSRF attacks too)
  • jsf2csrf.war – sample solution for handing Cross-site Request Forgery (CSRF) attacks only.

The source for both is in the WEB-INF/classes directory.

The token approach uses a standard JSF component that outputs a hidden field in the form. The hidden
field is created based on a server-generated secret key plus other information, such as the current view
id. What's a little different is that a phase listener decodes the component before Apply Request Values.
The goal here was to check the token before any other decoding takes place. Also, the token isn't
released until after Invoke Application to ensure that application processing has occurred.

For JSF 2, I think either enhancing UIForm, providing an alternate UIForm, or using a ClientBehavior
might be a better option than a separate component. Using UIForm would avoid the need to handle
decoding in the PhaseListener.

The CSRF approach is a little different. It still generates a special token based on a server-generated
secret key, but it does so based on the session, not on the view. It then appends the token to every JSF-
generated request through ViewHandler.getActionURL(). It uses a PhaseListener to ensure that every
incoming request has a valid token.

It's possible to combine these approaches, but I like the way the CSRF approach doesn't require anything
on the part of the developer. The caveat is that since it's session-based, it's probably not secure as a
form-based approach. Also, a form-based variant is required to avoid double-submits.

I'm not familiar with back button solutions, so I can't comment on how this code is applicable.

Comment by kito75 [ 14/Jul/10 10:46 AM ]

We should also consider the Seam <s:token> approach
(http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF). This is
component-based approach by Dan Allen with two key artifacts:

This approach also uses a cookie to ensure the requests are coming from the same browser, which is a
nice feature (but it should be optional). It also has explicit support for client-side state saving, which
my solution does not.

Comment by rogerk [ 22/Jul/10 05:25 PM ]

re-target

Comment by rogerk [ 23/Jul/10 07:33 AM ]

I've created a separate spec issue for CSRF:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
as it solves a different problem.

Comment by rogerk [ 13/Aug/10 05:08 AM ]

target

Comment by rogerk [ 13/Aug/10 05:58 AM ]

Starting

Comment by rogerk [ 27/Aug/10 10:52 AM ]

reset priority

Comment by rogerk [ 13/Sep/10 08:21 AM ]

target 2.2

Comment by joshbrookes [ 18/May/11 12:11 PM ]

This issue has remained untouched since mid-Sept of 2010. Is this still being targeted for development or is there a recommended 3rd-party utility that can be used with Mojarra?





[JAVASERVERFACES_SPEC_PUBLIC-1007] Explicit support for dynamic component tree manipulation Created: 22/May/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: 2.3

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: components
Participants: arjan tijms, Ed Burns, kennardconsulting and Manfred Riem

 Description   

In JSF it's possible to manipulate a component tree using Java code after it has been build by the ViewHandler. From the very first JSF version on, there have been explicit APIs to do this manipulation.

E.g.

UIViewRoot root = FacesContext.getCurrentInstance().getViewRoot();
UIOutput output = new UIOutput();
output.setValue("Dynamically added component");
root.getChildren().add(output);

However, the exact moment when this kind of manipulation is legal to do has not been specified. In the past, people have been using various moments in the life-cycle, where success ranged from an exception, the component appearing in the rendered response but not surviving a postback, to everything working as expected. Furthermore, behavior varied between MyFaces and Mojarra.

In JSF 2.0, the PreRenderViewEvent seems like an excellent opportunity for this manipulation, but it has not been specified that this is the right moment and in practice implementations might still not support full manipulation here. See http://java.net/jira/browse/JAVASERVERFACES-1826

Proposal: Explicitly provide support for dynamic component tree manipulation, possibly by proving a special system event for this and mandating conforming implementations to fully allow such manipulations. In case this is not technically feasible, specify what kind of manipulations are guaranteed to work.



 Comments   
Comment by kennardconsulting [ 22/May/11 03:32 PM ]

Hi guys,

Thanks for opening this spec issue!

I'd like to point out that MyFaces, as of 2.0.3, has successfully supported dynamic component tree manipulation in all my SystemEvent Acid Tests (see https://issues.apache.org/jira/browse/MYFACES-2935) and in Metawidget (http://metawidget.org) which exercises dynamic component tree manipulation more than most.

So this spec change may be as simple as 'blessing' the MyFaces behaviour. Certainly this would seem preferrable to introducing a new SystemEvent. My only concerns:

1. The name of PreRenderViewEvent is fine, but the way you have to use it seems odd:

root.subscribeToViewEvent( PreRenderViewEvent.class, this );

I believe Ryan Lubke came up with this approach (see http://kennardconsulting.blogspot.com/2010/10/safely-manipulating-component-tree-with.html). It works, but it seems strange a component has to register against the 'UIViewRoot.subscribeToEvent' as opposed to just calling 'this.subscribeToViewEvent'? Perhaps this could be explained and documented in the spec.

2. Rinner23 has expressed concerns whether PreRenderViewEvent works inside a UIRepeat (see http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=308718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_308718). I have never tested this use case myself.

Regards,

Richard.

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

Bulk assign all of Sheetal's spec issues to me.

Comment by arjan tijms [ 16/Jul/11 12:26 PM ]

rogerk hinted at a possible necessity for this behavior to be spec'd:

I know there was some initial discussion on the EG related to this area - perhaps some of this should be spec'd so implementations have a blueprint to follow and MyFaces/Mojarra will be doing it the same way.

See: http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=316876&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_316876

Comment by kennardconsulting [ 07/Nov/11 09:21 PM ]

I have done some further experiments using PreRenderViewEvent within 'repeater' components (such as ui:repeat and h:column).

There appears to be a fundamental problem whereby components that use PreRenderViewEvent cannot also access 'bound attribute values' (such as <h:dataTable var="internal">). Ed believes this is defined at the spec level, so needs to be fixed there too.

See http://java.net/jira/browse/JAVASERVERFACES-2089

Note there is a workaround if the parent component is defined by the developer. But this workaround is not available when using the built-in components (such as h:column).

See https://issues.apache.org/jira/browse/MYFACES-3168

Comment by Manfred Riem [ 16/May/12 01:37 PM ]

All the changes included in 1826, 2371, 2372 and 2373 should account for the ability to manipulate the component tree. Note that dynamic component tree manipulation can happen at any time after restoring the view and before state saving.

Comment by kennardconsulting [ 16/May/12 11:06 PM ]

I must point out that "the changes included in 1826, 2371, 2372 and 2373" do not fully "account for the ability to manipulate the component tree". Several show stopper bugs remain, as reported here http://java.net/jira/browse/JAVASERVERFACES-2283

Please address this! I have been waiting 2.5 years

Comment by arjan tijms [ 17/May/12 07:16 AM ]

Please also note the difference between the practical ability of Mojarra to allow dynamic manipulation and the spec actually demanding that compliant implementations should support this.

Comment by Manfred Riem [ 17/May/12 02:42 PM ]

OK I guess I need to clarify what I meant with my previous comment about 1826, 2371, 2372 and 2373. As this is a spec issue what I meant with it was the fact we have now identified at what point in the lifecycle it is save to do dynamic component tree manipulation. The following clarification / explanation can be added somewhere in the JavaDoc and/or specification. So any JSF implementation is aware of what is expected with regards to dynamic component tree manipulation.

"Dynamic component tree manipulation can happen at any time during and after restoring the view and before state saving and needs to function properly with respect to rendering and state saving"





[JAVASERVERFACES_SPEC_PUBLIC-1171] Specify interaction of Stateless and CSRF protection Created: 13/Mar/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and kithouna

 Description   

LU> 2. Stateless views that needs to be protected against CSRF attack, must
LU> include its token in javax.faces.ViewState field as if it was the view
LU> state, but only contains the info related to the secret stored in session
LU> or encoded/encrypted when client side state saving is used. In few words
LU> if the view is protected, javax.faces.ViewState generation may requires
LU> additional steps.



 Comments   
Comment by kithouna [ 14/Mar/13 09:31 AM ]

Don't stateless views also loose the implicit CSRF protection offerd by the required view state Id that stateful views have?





[JAVASERVERFACES_SPEC_PUBLIC-925] Helper methods for FacesContext Created: 31/Jan/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 6
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Status Whiteboard:

size_small importance_medium

Tags:
Participants: arjan tijms, Ed Burns, kithouna and tedgoddard

 Description   

There are a number of fairly common tasks for web applications that require a
fairly long method string to capture. A set of helper methods would be handy...

For instance getting a parameter, or getting an EL value, both require chained
method calls that are 5 levels or so deep. There are probably others - I'll
think about it and see if I can come up with a list.



 Comments   
Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

Bulk assign all of Sheetal's spec issues to me.

Comment by arjan tijms [ 08/Aug/11 09:06 PM ]

This would be really handy. The FacesContext not only requires deep chaining, but since especially ExternalContext doesn't make too many assumptions about its environment (basically a Good Thing) a lot of casting is typically done in web applications.

Since Servlet based web applications seem to be the most common use case for JSF, a (additional) utility class could be created that already assumed this environment. Many JSF applications that I've seen already create such utility classes anyway. Besides the mentioned helper methods, the following might be useful:

  • HttpServletRequest getRequest()
  • HttpServletResponse getResponse()
  • HttpSession getSession()
  • Map<String, String> getRequestParameterMap()
  • ServletContext getServletContext()
  • Locale getLocale()
  • UIComponent findComponent(String expression)
  • addPhaseListener(PhaseListener phaseListener)
  • <T> T evaluateExpression(String expression)

And finally two (perhaps) more exotic helper methods:

  • void addBeforePhaseListener(PhaseId phaseId, final Runnable runnable)
  • void addAfterPhaseListener(PhaseId phaseId, final Runnable runnable)

The last two not only flatten the FacesContext chain, but allow a single interface type (SAM type) to be a PhaseListener, which is already more convenient to implement but will ever further reduce complexity when/if Java 8 closures are introduced. It can be implemented by simply adding some DefaultPhaseListener that calls the provided Runnable:

public static void addAfterPhaseListener(PhaseId phaseId, final Runnable runnable) {

    FacesContext.getCurrentInstance().getViewRoot().addPhaseListener(new DefaultPhaseListener(phaseId) {

        @Override
        public void afterPhase(PhaseEvent event) {
            runnable.run();
        }
    });
}

Not sure if it's in scope for this issue, but some helper methods for components would also be nice. Some tasks that you'd think would be simple, still require some amount of code. E.g.:

  • boolean hasValue(UIInput input) // without firing validators
  • <T> T getValue(UIInput input) // validated value, without need to know if validation already happened before call
  • String getComponentLabel(UIComponent component)
Comment by Ed Burns [ 09/Aug/11 02:59 PM ]

I've added this issue to the JSF_2_2_WORKING_SET JIRA filter.

Comment by arjan tijms [ 15/Oct/11 04:22 PM ]

Another simplification that could be caught in a single method is adding faces messages.

Currently, idiomatic code to adding such a message (globally) is this:

FacesContext context = FacesContext.getCurrentInstance();
FacesMessage message = new FacesMessage("Error message here");
message.setSeverity(FacesMessage.SEVERITY_ERROR);
context.addMessage(null, message);

It gets more verbose when i18n is involved:

FacesContext context = FacesContext.getCurrentInstance();
Locale locale = context.getViewRoot().getLocale();
String bundleName = context.getApplication().getMessageBundle();
ResourceBundle bundle = ResourceBundle.getBundle(bundleName, locale);
String text = null;
try {  
    text = MessageFormat.format(bundle.getString(key), param1, param2);
} catch (MissingResourceException e) {
    text = "Missing key: " + key;
}
FacesMessage message = new FacesMessage(text);
message.setSeverity(SEVERITY_ERROR);
context.addMessage(null, message);

Every JSF project in practice that I've seen thus abstracts this code away in some utility method. For instance, the following captures a great chunk of practical usage:

FacesMessages.addMessageFromBundle(SEVERITY_ERROR, key, param1, param2);

(incidentally, this was one of the original gripes Matt Raible had with JSF: http://raibledesigns.com/rd/entry/the_joy_of_developing_with)

Several variants are possible (but to keep it simple, not too many variants should be introduced, else the user is better of using the existing API).

Don't look up in bundle, but use text provided by user:

FacesMessages.addMessage(SEVERITY_ERROR, text, param1, param2);

Overloaded to add message to specific component:

FacesMessages.addMessage(componentId, SEVERITY_ERROR, text, param1, param2);
Comment by arjan tijms [ 28/Dec/11 04:33 PM ]

One more request for a helper method, although it's more related to components so I'm not sure it's in scope for this ticket, but it's a method to get hold of all select items for a given component.

Currently almost everybody seems to be creating their own version of this (e.g. Mojarra's com.sun.faces.renderkit.SelectItemsIterator, MyFaces' org.apache.myfaces.shared_impl.util.SelectItemsIterator and PrimeFaces' org.primefaces.util.ComponentUtils#createSelectItems).

Comment by tedgoddard [ 21/Feb/12 10:26 PM ]

Implementation for a given helper method is likely straightforward, but some may be controversial. For instance, getRequest() (as above) is only valid in a Servlet environment. Not all application code requires Servlet/Portlet portability, so potentially a helper with a type-safe API could be instantiated and used:

helper = new FacesServletHelper(facesContext)

but perhaps a better question is why direct access to the HttpServletRequest is required. Once this is understood, type-safe portable methods could potentially be added to FacesContext or ExternalContext.

Comment by arjan tijms [ 21/Feb/12 11:12 PM ]

Not all application code requires Servlet/Portlet portability, so potentially a helper with a type-safe API could be instantiated and used:

That was indeed exactly what I meant with "Since Servlet based web applications seem to be the most common use case for JSF, a (additional) utility class could be created that already assumed this environment."

but perhaps a better question is why direct access to the HttpServletRequest is required

A quick scan in the JSF application I build with my team reveals that among others this is used to access the request attributes, to get a specific request header, interaction with legacy/non-jsf code that requires the HttpServletRequest as input, getting the userPrincipal or doing the isUserInRole check.

Clearly, a lot on that on that list is also available on the type-safe ExternalContext.

Comment by kithouna [ 28/Jan/13 09:24 AM ]

@tedgoddard what about HttpServletRequest#login, logout, authenticate etc?





[JAVASERVERFACES_SPEC_PUBLIC-1172] ClientWindow: deal gracefully with multiple client windows having the same id Created: 13/Mar/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

AS> + * <p>In addition to the hidden field already described. The runtime
AS> + * must ensure that any component that renders a hyperlink that causes
AS> + * the user agent to send a GET request to the Faces server when it is
AS> + * clicked has a query parameter with a name and value specified in
AS> + * {@link ResponseStateManager#CLIENT_WINDOW_URL_PARAM}. This
AS> + * requirement is met by several of the "encode" methods on {@link AS> + * javax.faces.context.ExternalContext}. See {@link AS> + * javax.faces.context.ExternalContext#encodeActionURL(java.lang.String) AS> + * } for details.</p>

AS> What is the expected behavior when the end user creates a second browser
AS> tab/window with an existing window id? For example, this can happen by:

AS> - Bookmarking an url with a window id and opening that URL in multiple tabs.
AS> - Copying and pasting an url from one tab into a second tab.
AS> - (On some browsers) Using the browser's "New Window" action.

AS> For each of the above cases, each window/tab should be assigned its own
AS> unique id, even though it would require additional work to determine
AS> when a client window id has been copied across windows/tabs






[JAVASERVERFACES_SPEC_PUBLIC-1198] Specify behavior when multiple phase-listener decls with same FQCN are encountered Created: 11/Jun/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

The XSD for <phase-listener> states:

The "phase-listener" element contains the fully qualified class
name of the concrete PhaseListener implementation class that will
be registered on the Lifecycle.

What is the correct behavior if multiple decls with the exact same FQCN are encountered? I think it should be "last one wins, log a message if more than one".






[JAVASERVERFACES_SPEC_PUBLIC-1155] Require FacesContext.getCurrentInstance() to work at Servlet "SessionDestroyed" event time Created: 16/Jan/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-2691 Session scoped beans and activeViewMa... Closed
Tags:
Participants: Ed Burns

 Description   

JSF 2.0 requires that FacesContext.getCurrentInstance() is valid to call at three times in the application lifecycle.

1. Startup time

2. Request processing time

3. Shutdown time

This feature request proposes adding an additional time to this list: Servlet "SessionDestroyed" event time.






[JAVASERVERFACES_SPEC_PUBLIC-950] Pluggable Annotation Scanner Created: 21/Mar/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns

 Description   

Looking at JSR-314-EG discussion from September 2008, I see that the 287-PluggableScanning thread appears to have been dropped.

http://archives.java.sun.com/cgi-bin/wa?A2=ind0809&L=JSR-314-EG&P=R6009&D=0&H=0&O=D&T=0&X=67011806635D16CFFF&Y=ed.burns%40sun.com

The code was attached at <http://java.net/jira/secure/attachment/13638/287-FacesAnnotationHandler.zip> on JAVASERVERFACES_SPEC_PUBLIC-287, but it seems never to have been committed.



 Comments   
Comment by Ed Burns [ 30/Mar/11 11:44 AM ]

Set to lifecycle

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-1021] Expose component local values in single key/value data structure Created: 23/Jun/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small

Tags:
Participants: arjan tijms, Ed Burns, Hanspeter Duennenberger and Jakob Korherr

 Description   

Every ValueHolder JSF component has a local value. It would be nice to have access to these local values knowing only the name of component. Something like this. We could specify that the viewMap must be populated with references to the ValueHolder instances in the current view. Then, you could say:

ValueHolder comp = (ValueHolder) context.getViewMap().get("<your componentId>");

Look at the API for ValueHolder.

http://download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/api/javax/faces/component/ValueHolder.html



 Comments   
Comment by Jakob Korherr [ 23/Jun/11 10:12 AM ]

Nice idea. This would make the binding attribute kinda obsolete, right?

Comment by arjan tijms [ 05/Jul/11 04:39 PM ]

Just wondering, will this view map only contain ValueHolder instances or also other components? In case it also contains other components, it's perhaps a bit similar to:

ValueHolder comp = (ValueHolder) context.getViewRoot().findComponent("<your componentId>");

Nice idea. This would make the binding attribute kinda obsolete, right?

Well, with the binding attribute a backing bean receives an instance of a component without having to know its ID at all. This is handy since within a backing bean there might be situations where you can't know this ID and/or do not want to know it. So the binding attribute doesn't seem to be made obsolete if I understand the proposal correctly.

Comment by Hanspeter Duennenberger [ 07/Jul/11 01:44 PM ]

Why should that be on ViewMap? That would mean the ViewMap has to be cleared of these component references before state is saved.

Comment by Ed Burns [ 07/Jul/11 09:22 PM ]

HD> Why should that be on ViewMap? That would mean the ViewMap has to be
HD> cleared of these component references before state is saved.

Good point. It should really be on the FacesContext attributes Map.

Here is more from the reporter.

>>>>> On Wed, 6 Jul 2011 10:53:46 +0200, Rainer Sinkwitz said:

RS> Hi Mr. Burns,
RS> Thanks for your mail. Actually what you describe is possible and I use it
RS> as part of my IMHO kludgy solution. The key issue are the AJAX expressions
RS> and it seems I can either access the view for unsaved values or work with
RS> a copy of my model and extra code for loading and saving the copy against
RS> the model. Right now I think I should first update myself to JSF 2.0
RS> before I continue with any further proposal for this.

RS> For your information here is what I do right now: I make the UIComponent
RS> available as EL expression through a Map implementation with a only get()
RS> coded like
RS> public Object get(Object key) { RS> UIViewRoot viewRoot = FacesContext. RS> getCurrentInstance().getViewRoot(); RS> return viewRoot.findComponent(((String) RS> key)); RS> }

RS> So if I have that map in the session, then I can use an EL expressions
RS> like
RS> value="#{viewMap['form:fld_pr_customer'].value.displayCity}"

RS> ... and viewMap[...].value gives me the converted object since there is
RS> UIComponent.getValue()/setValue(). So I have already what you describe,
RS> and even as a JSF expression, but I still find this kludgy.

RS> Lets me again describe by basic setting: Most of our forms have a "View"
RS> and an "Edit" mode, so that concurrent editing can be prevented with
RS> global locks. The main issue is the "Cancel" functionality which instead
RS> of updating the model must revert the form to it. Since the model is an
RS> attached JPA entity, JSF phase 4 must be suppressed. I currently do this
RS> with 'immediate="true"' on the cancel button and an action method that
RS> replaces the entire view with an empty one, then calling RenderResponse()
RS> to skip to phase 6, which in turn rebuilds the view and reloads the values
RS> from the model.

RS> So far so good, but the complication begins when I do AJAX updates with
RS> JBoss RichFaces Ajax4Jsf updating some dependent fields from unsaved
RS> values. Here it is that I need to use the above expressions.

RS> An alternative solution would be to let the form work against a copy of
RS> the JPA entity. Then AJAX could update the copy instead and use normal
RS> expressions against the copy. But then I need to do all the field copying
RS> from JPA entity to the copy and back and then somebody adds a new field
RS> and misses the copy code. Not a nice solution either.

RS> Anyway, thanks for your response, with best regards, Rainer

Comment by Hanspeter Duennenberger [ 08/Jul/11 08:16 AM ]

EB> Good point. It should really be on the FacesContext attributes Map.

And even in FacesContext it needs to be cleared whenever ViewRoot changes. That remembers me to something we discussed some time back - a View-related-Request scope. That is something that lifes during a request but only as long as the ViewRoot does not change. I guess that could easily be handled on FacesContext and that would be the place for such things as the references to EditableValueHolders.





[JAVASERVERFACES_SPEC_PUBLIC-920] Enhance ProjectStage to contain DesignTime value Created: 20/Jan/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium

Tags: 3_1-exclude
Participants: Ed Burns, Jakob Korherr and mwessendorf

 Description   

http://markmail.org/message/v742dgxrnovm7fpl

Hi,

opening a ADF/Trinidad application in JDeveloper's I am seeing a
"warning" like this:

WARNING: Your environment is configured as production and Apache
Trinidad is running with debug javascript. See the
"org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT" parameter in
/WEB-INF/web.xml

The WARNING itself is fine, since the web.xml doesn't have any
ProjectStage setting, but it contains a flag to not obfuscate our
JavaScript (to make it readable)...

However, in DT (DesignTime) mode this can be pretty annoying..
Therefore I was wondering if the standard ProjectStage ([1]) should
contain a "DesingTime" value?
In a similar fashion like the java.beans.Beans class does have a
isDesignTime() method ([2]).

Not sure if that has been already discussed when specifying the new
ProjectStage contract.

Greetings,
Matthias

[1]
http://myfaces.apache.org/core20/myfaces-api/xref/javax/faces/application/ProjectStage.html
[2]
http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/beans/src/main/java/java/beans/Beans.java



 Comments   
Comment by mwessendorf [ 20/Jan/11 11:36 PM ]

The ApplicationImpl's getProjectStage() would immediately return "ProjectStage.DesignTime", if Beans.isDesignTime() is true.

Comment by Jakob Korherr [ 15/Apr/11 04:14 AM ]

We could even allow custom ProjectStages like MyFaces CODI enables you to!

Comment by Ed Burns [ 06/Jun/11 05:35 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-876] ViewChangedEvent Created: 13/Aug/10  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 876
Status Whiteboard:

size_small importance_small

Tags:
Participants: Darious3, Ed Burns, Hanspeter Duennenberger and rogerk

 Description   

>>>>> On Fri, 30 Jul 2010 10:11:33 +0200, Dünnenberger Hanspeter said:

HD> as an outcome of this discussion, would you welcome a new
HD> SystemEvent (e.g. named ViewRootChangeEvent) to be fired whenever
HD> the current ViewRoot instance changes?



 Comments   
Comment by rogerk [ 27/Oct/10 02:33 PM ]

triage

Comment by Hanspeter Duennenberger [ 06/Jun/11 09:24 AM ]

Actually, it would be nice if the event object would provide references to the old and new ViewRoot - that would allow for some usage to copy viewScope entries from one ViewRoot to the next if a user wants to, e.g. in case both view's have the same viewId.

Comment by Ed Burns [ 06/Jun/11 09:40 AM ]

##jsf freenode IRC discussion

<hpdueni> Hi all. I discovered a problem using component binding and teh detection of annotated ResourceDependencies e.g. in renderers
<hpdueni> when navigating to the same page, I end up with a new ViewRoot instance but I don't get the resource dependencies from annotations.
<hpdueni> that is because the component binding prevents the tag handlers from beeing invoked in the render phase after the viewRoot was exchanged.
<edburns> hpdueni: Wow, that's subtle.
<edburns> hpdueni: I think it's really because Application.createComponent() is not being called based on the scope of the binding.
<hpdueni> Now I suspect if we need a binding-scope or if we should just rely on the ViewRootChangeEvent (which i requested in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876) to reset all component bindings

  • rogerk1 (~Adium@pool-96-237-170-36.bstnma.fios.verizon.net) has joined ##jsf
    <edburns> hpdueni: When you say "reset all component bindings" do you mean that funny little traversal we do of the tree before really getting started with the lifecycle?
    <hpdueni> or what we already have in CS JSF is a Bindings bean that should be used for all component bindings - and that one is cleared whenever ViewRoot changes
    <ioss> hpdueni: if your binding would always return null, wouldn't that solve the problem? not sure I got your issue right?
    <hpdueni> with reset component binding when viewroot changes I mean, the backing bean which holds the bound component must release that component which is from the previous view
    <ioss> or why would you want to hold the component for longer then a request?
    <hpdueni> for simplicity we used e.g. h:panelGroup bindgin="#{facesContext.attributes['someid']} " and then ass that el into another CC to pass on teh dynamic clientId
    <hpdueni> ioss: that problem already happens within one request - as required, we never hold bindings longer than a request.
    <hpdueni> ioss: but as it tunred out, request scope is already too long in case when viewroot changes -
    <edburns> hpdueni: Yes, I know requestscope is too long when the viewroot changes, but I'm still trying to understand your quandry.
    <hpdueni> edburns: exactly, since the component that was created in restore phase is bound to something in request scope, the component is still there after viewRoot changed and therfore Application.createComponent() will not be invoked and none of teh resource dependencies are detected
    <ioss> Hanspeter: how about always returning null?
    <ioss> then your component binding should get reset on the render-phase
    <ioss> you should possibly get a call on restore-view and another one after the view changes
    <edburns> ak: I see. Actually, there were no changes in the XSD for facelet taglibs in 2.1, so you can just use the 2.0 one.
    <hpdueni> ioss: if teh binding always returns null I can't use it anymore to pass component references to some other component ...
    <ioss> hpdueni: sure, name the binding in another way
    <ioss>
    <edburns> In fact, I just had to make the first change in the facelet taglib xsd since 2.0 a few weeks ago.
    <ioss> getTemplateComponent => null, setTemplateComponent => normal setter + getComponent => returns the one that was set by setTemplateComponent
    <hpdueni> ioss: would mean to have one attribute name with only a set method to pass teh component and another read-only name to retrieve it ...
    <ioss> right
    <hpdueni> ioss: that could work, would that be your general recommendation for component binding ?
    <ioss> hpdueni: not the nicest approach I agree, but still not horrible I would say
    <ioss> hpdueni: for components that you will never provide yourself (you can not return null there) I guess it is a possible approach
    <ioss> hpdueni: I nearly never use componentbinding
    <ioss> hpdueni: I am more a "lookup"-guy
    <hpdueni> ioss: yea, it has its pitfalls
  • mbenson_ (~mbenson@apache/committer/mbenson) has joined ##jsf
    <ioss> also there is a myfaces codi extension to bind components to longer scopes, that works that way (I think it is still in development)
    <edburns> ak: Can you please file an issue in the docmentation sub-component on this JIRA: http://java.net/jira/browse/JAVASERVERFACES
    <hpdueni> ioss: now we are close to what we do - we actually need to pass the id of one component to some CC - but as the component's clientId is unknown at development time we pass the component using this binding .
    <ioss> hpdueni: so the template author does not know the id?
    <hpdueni> ioss: not the full clientId - that may change depending on if you are running as a web app or as a Portlet - both is possible from the same web app instance
    <ioss> hpdueni: If it is different templates (inclusion/etc) it is probably cleaner to bind the component in question
    <ioss> ok
    <ioss> so this is really some sort of fire-and-(partially)-forget
    <ioss> i guess a readonly property describes exactly your "contract", as that component is never meant to be set directly
    <ioss> directly=by java code
    <ioss> by java code=non jsf implementation java code
    <hpdueni> ioss: kind of, but still I need a writable property to get hold on the component which I want to read-only from somewhere else
    <hpdueni> I just think some of the new features interfere with component binding and we need a general approach for that
    <ioss> hpdueni: if you like to go creazy you could add an ELResolver, that will set even a private property
    <ioss> or one that will return null always when el is used
    <ioss> that's actually not to bad
    <ioss> if you can come up with a naming convention, or annotations
    <ioss> or a "fake" scope
    <ioss> #{componentwriteonlybinding.mybean.property}
    <ioss> so setter and getter would work normally, but el will always return null
    <ioss> hpdueni: but i think the viewchangedevent is not a bad one, you'll just have to find a good place to "bind" them too
    <hpdueni> ioss: sounds somehow weird - actually, thinking on that kind of use my binding should work as readonly only while component tree is built - (buildView) - to prevent passing the component to the new view and allow Application.createComponent() doing it's work
    <hpdueni> ioss: I wouldn't like another ELResolver for that as there are already so many ELResolvers involved - and writing to private method would involve reflection and is somehow dirty
    <hpdueni> ioss: talking about face scope - a custom scope could hanlde that
    <ioss> hpdueni: right
    <hpdueni> ioss: on the other hand, I'd like a solution for all JSF users, not only the ones that are aware of that potential problem
    <ioss> hpdueni: couldn't you use a prerender event?
    <ioss> hpdueni: it guess it does not matter for you, if the view changed or not, you just have to get rid of that component before rendering
    <hpdueni> ioss: sure - to always get a fresh or updated component in buildView all such bindings could be thrown away in before render phase
    <ioss> hpdueni: I think a scope is the easiest way to cope with that for now. either clean the scope, or let the scope have a "special" getter, while the normal getter will return null always
    <hpdueni> ioss: but now, where does that lead us - would that mean standard bindings usage should behave always like this? Then we could really use a BindingsScope to support that
    <ioss> hpdueni: well i wouldn't call it bindingscope, but there might be use for a scope that has a "half-request" lifetime
    <hpdueni> ioss: such a bindings scope would survive during the execute phases and be a separate instance for the render phase
    <ioss> right
    <hpdueni> ioss: whatever it's called - it would have separate lifetime for execute phases and render phase
    <hpdueni> ioss: that is pretty close to the two Portlet phases
    <ioss> you could probably even use it for some fancy persistence stuff, like make the "execute" phase transactional and write enabled, while the request-phase would have an long-running em to cope with lazy-load, but also would not allow to persist anything
    <ioss> Reminds me, that I have to read about portlets!
    <hpdueni> ioss: guess we close the discussion for now - was anybody else listening on that? Any other positions on that?
    <edburns> hpdueni: Ok, so ioss proposed a workaround involving an extra javabeans property, and then the discussion went to having a scope for this use-case.
    <hpdueni> edburns: yes, some special ELResolver was also in discussion
    <edburns> hpdueni: But really, this is closelely related to <http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876>.
    <edburns> Let me capture this discussion to the comment thread on the issue.
    <hpdueni> edburns: what would be a solution for everybody - or should binding be considered as advanced usage where one has to know the bindings might need to be cleared in certain cases even in the middle of the request?
Comment by Darious3 [ 07/Oct/12 10:42 AM ]

The bindings issue mentioned in the chat is somewhat related to the problem that if the view navigated to contains meta-data, that meta-data isn't processed. See JAVASERVERFACES-2279





[JAVASERVERFACES_SPEC_PUBLIC-959] Common StateHelper for all JSF StateHolder/PartialStateHolder Created: 01/Apr/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns and Mathias Werlitz

 Description   

There should be a common StateHelper for all JSF "components" that can implement StateHolder/PartialStateHolder e.g. Behavior, Converter and Validator.

There could be a base class like UIComponentBase for this purpose for each type that exposes the StateHelper (e.g. something like ConverterBase). BehaviorBase should be extended to expose the helper.



 Comments   
Comment by Ed Burns [ 06/Jun/11 05:35 PM ]

Bulk assign all of Sheetal's spec issues to me.





[JAVASERVERFACES_SPEC_PUBLIC-1045] Flash created in ExceptionHandler not work Created: 27/Oct/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: lu4242

 Description   

Original issue created on

https://issues.apache.org/jira/browse/MYFACES-3358

by Keith Wong:

------------------------------------------------

I have a custom ExceptionHandler for handling ViewExpiredException as occurred in session timeout or application restart. I have to tell the user in the redirected page the reason for being redirected. Here is the handler:

public void handle() throws FacesException {
for (Iterator<ExceptionQueuedEvent> i=getUnhandledExceptionQueuedEvents().iterator(); i.hasNext(); ) {
ExceptionQueuedEventContext context = i.next().getContext();
Throwable t = context.getException();
if (t instanceof ViewExpiredException) {
FacesContext ctx = FacesContext.getCurrentInstance();
ViewExpiredException vee = (ViewExpiredException)t;
try { ctx.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, vee.getClass().getName(), vee.getMessage())); Flash flash = ctx.getExternalContext().getFlash(); flash.put("expiredViewId", vee.getViewId()); flash.setKeepMessages(true); ctx.getApplication().getNavigationHandler().handleNavigation(ctx, null, "/login?faces-redirect=true"); ctx.renderResponse(); }
finally { i.remove(); }
}
}
super.handle();
}

In the login.xhtml, it has #{flash.expiredViewId} and <f:messages> but both are empty when displayed.

------------------------------------------------

Unfortunately the code proposed does not work by spec. See JSF 2.0 section 12.3. In few words, the problem is handle() is called after the current phase is processed, so flash scope has been already processed. Maybe in this case it is possible to call Flash.doPostPhaseActions(FacesContext) and doPrePhaseActions(FacesContext) to wrap flash operations inside handle() method, but we can't do anything from MyFaces point of view. Maybe it should be possible to do something on the spec, because it sounds like a common use case.

Really it is curious people trying to create custom ExceptionHandler implementations using JSF usually finds problems like this one and others, for example if you try to create a jsf page to handle jsf errors. It is worth to take a look to this API, to see if in practice requires some fixes to make it more practical.






[JAVASERVERFACES_SPEC_PUBLIC-1028] Clarify partial state save/restore traversal requirements Created: 02/Aug/11  Updated: 17/Dec/13

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.1
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Status Whiteboard:

size_small importance_medium

Tags:
Participants: aschwart and Ed Burns

 Description   

Mojarra and MyFaces differ in how they implement the partial state save/restore traversals. Mojarra uses tree visiting. MyFaces does not. The spec should define requirements for this area to ensure consistency across implementations.



 Comments   
Comment by aschwart [ 02/Aug/11 05:01 PM ]

Expert group discussion can be found here:

http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-08/message/0

At this point it looks like we should specify that tree visiting should be used for these traversals, as this allows components (eg. Trinidad's UIXCollection) to intercept the traversal in order to perform component-specific processing.

Comment by Ed Burns [ 10/Aug/11 03:49 PM ]

Added to JSF_2_2_WORKING_SET <http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10531>. Added estimates.

Comment by Ed Burns [ 22/Dec/11 03:32 PM ]

Deprecate StateManager, point to StateManagementStrategy. In StateManagementStrategy, require the use of the visit API to perform the saving. http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1028

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/Application.java

  • mark {get,set}StateManager() as deprecated, pointing to the new
    equivalents.

M jsf-api/src/main/java/javax/faces/application/StateManager.java
M jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java

  • Deprecate these classes, pointing to the new equivalents.

M jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java

  • require the use of the visit API to perform the saving.

M jsf-api/src/main/java/javax/faces/context/FacesContext.java

  • fix javadoc error

Committed to trunk:

Sending jsf-api/src/main/java/javax/faces/application/Application.java
Sending jsf-api/src/main/java/javax/faces/application/StateManager.java
Sending jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java
Sending jsf-api/src/main/java/javax/faces/context/FacesContext.java
Sending jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java
Transmitting file data .....
Committed revision 9542.

Comment by Ed Burns [ 22/Dec/11 04:41 PM ]

Need to re-open to consider Ted Goddard's additional requests on this issue.

Comment by Ed Burns [ 22/Dec/11 05:00 PM ]

Roll back deprecation of entire StateManager in favor of just deprecating two methods: {save,restore}View(). http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1028

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/Application.java

  • Roll back deprecation of the stateManager property.

M jsf-api/src/main/java/javax/faces/application/StateManager.java

  • Roll back deprecation of the entire class.
  • Deprecated {restore,save}View().

M jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java

  • Roll back deprecation of the entire class.

M jsf-api/src/main/java/javax/faces/context/PartialResponseWriter.java

  • In the value for VIEW_STATE_MARKER, rather than duplicating the
    literal string, refer to the symbolic constant
    ResponseStateManager.VIEW_STATE_PARAM, the value of which is
    equivalent to the literal string being replaced.

Committed to trunk:

Sending jsf-api/src/main/java/javax/faces/application/Application.java
Sending jsf-api/src/main/java/javax/faces/application/StateManager.java
Sending jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java
Sending jsf-api/src/main/java/javax/faces/context/PartialResponseWriter.java
Transmitting file data ....
Committed revision 9543.

Comment by Ed Burns [ 03/Feb/12 07:32 PM ]

Move to sprint 11





[JAVASERVERFACES_SPEC_PUBLIC-1245] Section "Determining the active Locale" includes too narrow language Created: 26/Dec/13  Updated: 26/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

There is text in section "Determining the active Locale" (section number 2.5.2.1 as of version 2.2 of the JSF spec) that speaks too narrowly of how the system must process the <supported-locale> entries in the <locale-config> of the faces-config.xml file. In particular, this text runs afoul of the changes for script tags specified in IETF BCP47.

This text must be generalized so that existing behavior continues to be spec compliant, while BCP47 style entries can also be supported.

The spec for the <f:view locale> attribute must also be inspected so that it is compatible with BCP47.






[JAVASERVERFACES_SPEC_PUBLIC-1201] Require that the cookie used to store the Flash key is setHttpOnly(true) Created: 02/Jul/13  Updated: 02/Jul/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Dependency
depends on JAVASERVERFACES-2911 For JSF 2.2 and beyond, do setHttpOnl... Closed
Tags:
Participants: Ed Burns

 Description   

Require that the cookie used to store the Flash key is setHttpOnly(true)






Generated at Sat Apr 19 15:45:02 UTC 2014 using JIRA 4.0.2#472.