[JAVASERVERFACES_SPEC_PUBLIC-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components. Created: 19/Dec/13  Updated: 10/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days


 Description   

Text copied from JAVASERVERFACES-3094

The JSF spec (2.1) requires in section 10.3.1 that "The runtime must ensure that EL expressions that appear in the page without being the right-hand-side of a tag attribute
are treated as if they appeared on the right-hand-side of the value attribute of an <h:outputText /> element in the http://java.sun.com/jsf/html namespace." This should also work in this case.

This text is problematic with respect to c:set and friends.

I suggest we soften the above language to make it clear that we don't need to have UIOutput instances in the tree. Rather, we just need it to render as if we did.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns. Created: 03/Jul/13  Updated: 10/Sep/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

JAVASERVERFACES_SPEC_PUBLIC-745 amended the language for the Composite Component Attributes ELResolver's getType() method.

An additional change is needed for correctness to the cc:attribute tag's type attribute. The existing language states:

Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored.

This needs to be changed. Instead of assuming java.lang.Object, the system must use the return from the CC attribute ELResolver's getType() method.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1397] Provide documentation and tuning options for activeViewMaps Created: 13/Aug/15  Updated: 13/Aug/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF, Managed Beans
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: fischermatte Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We are using JSF 2.2.12 with server side state saving and plenty of ViewScoped ManagedBeans. After investigating our load tests it turned out that the data in our ViewScoped Beans is kept in session memory for quite some time. We were debugging Mojarra and found that the ViewScopeManager holds all ViewScoped beans of the last 25 used views. Even when you set numberOfLogicalViews to 1, it will still keep the last 25.

Now there is also an undocumented parameter com.sun.faces.application.view.activeViewMapsSize. When tuning JSF applications it would be very interesting to know why 25 and which impact this parameter has in conjunction with numberOfLogicalViews and numberOfViewsInSession.

I created also a stackoverflow post about this: http://stackoverflow.com/questions/31959982/jsf-2-2-memory-consumption-why-does-mojarra-keep-the-viewscoped-beans-of-the-la



 Comments   
Comment by fischermatte [ 13/Aug/15 ]

sorry, this issue belongs to mojarra not to spec. unfortunately i am not allowed to delete or move this issue here. I created the same here for mojarra now: https://java.net/jira/browse/JAVASERVERFACES-4015





[JAVASERVERFACES_SPEC_PUBLIC-1194] Make it so web-facelettaglibrary and web-facesconfig XSD files are canonically stored in javaee schemas workspace. Created: 22/May/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: None

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

Attachments: File 20130523-web-partialresponse_2_2.xsds    

 Description   

This is the current workflow for updating the web-facelettaglibrary and web-facesconfig files in the javaee schemas workspace.

1. Use the NetBeans XML validator on the corresponding .xsd file
committed to the Mojarra workspace.

2. In the schema workspace, apply the instructions in doc/HOWTO to add
test content for new elements, and change test content for modified
elements, ensuring the tests are all wired up to execute in the
normal build process.

3. Copy the .xsd from the Mojarra workspace to the .xsds in the schema
workspace.

4. Ensure the tests all run cleanly.

5. Commit the changes in the schema workspace.

Instead, the workflow should be that the output from step 4. is taken to be the source of truth for the corresponding files in the JSF workspace.



 Comments   
Comment by Ed Burns [ 22/May/13 ]

The crux of this task is to modify the .xsds files so that what they produce is identical to what is in glassfish-4.0-b89.zip for the web-facelettaglibrary and web-facesconfig XSD files.

Comment by Ed Burns [ 23/May/13 ]

web-partialresponse also must be fixed.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1178] Remove references to old XML schema and tag library URI Created: 01/Apr/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Arun P. Gupta reported numerous instances of the old namespaces in the PDF. These should be fixed.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1415] Broken link in JSF vdldocs, to "General Notes on Encoding" Created: 27/Mar/16  Updated: 10/Jan/17

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Arend v. Reinersdorff Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I noticed a a broken link in the JSF vdldocs documentation.

On the JSF 2.2 vdldocs documentation page for the h:form element:
http://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/h/form.html

The following link is broken:
Text:
General Notes on Encoding
Wrong link (404):
http://docs.oracle.com/javaee/7/javaserverfaces/2.2/vdldocs/facelets/h/renderkit-summary.html#general_encoding
Should be:
https://docs.oracle.com/javaee/7/javaserver-faces-2-2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_encoding

A quick Google search for
site:https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/ "General Notes on Encoding"
shows that this affects the vdldocs documentation pages for the following elements:
h:button
h:form
h:link
h:outputLink

For h:form and h:outputLink this affects also the vdldocs-jsp documentation:
http://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-jsp/h/form.html

This also affects the JSF 2.1 vdldocs documentation. For the h:form element:
https://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/vdldocs/facelets/h/form.html

Wrong link (404):
https://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/vdldocs/facelets/h/renderkit-summary.html#general_encoding
Should be:
http://docs.oracle.com/javaee/6/javaserverfaces/2.1/docs/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_encoding

The link is OK in the JSF 2.0 vdodocs documentation:
http://docs.oracle.com/javaee/6/javaserverfaces/2.0/docs/pdldocs/facelets/h/form.html



 Comments   
Comment by Arend v. Reinersdorff [ 06/Jan/17 ]

Partially fixed in JSF 2.3.0-m08
https://maven.java.net/service/local/repositories/releases/archive/org/glassfish/javax.faces/2.3.0-m08/javax.faces-2.3.0-m08-documentation.jar/!/doclist.html

  • fixed for links under "TLDDoc"
  • not fixed for links under "JSP Tag Documentation"
Comment by Ed Burns [ 10/Jan/17 ]

I confirmed this is still not fixed in the JSP Tag Documentation. I'm looking into it but it's low priority at this point.

Comment by Ed Burns [ 10/Jan/17 ]

Indeed, the renderkit-summary.html is missing from the jsp/h directory in the generated JSP TLDDoc. Fixing this is a build issue to track down why that file is not ending up in the documentation.jar.

Comment by Ed Burns [ 10/Jan/17 ]

I'll try to get to it before 2.3 goes final, but it can happen during Public Review.





Generated at Thu Jan 19 12:23:06 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.