[JAVASERVERFACES_SPEC_PUBLIC-1315] Simplify EL resolver chain by using CDI Created: 08/Oct/14  Updated: 20/Aug/15

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

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: arjan tijms
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Blocks
is blocked by JAVASERVERFACES-3478 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1386 Let CDI handle #{flowScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1387 Let CDI handle #{header} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1388 Let CDI handle #{headerValues} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1389 Let CDI handle #{initParam} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1390 Let CDI handle #{param} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1391 Let CDI handle #{paramValues} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1392 Let CDI handle #{request} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1393 Let CDI handle #{requestScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1394 Let CDI handle #{resource} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1311 Let CDI handle #{facesContext} EL res... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1322 Simplify #{externalContext} to use Ex... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1325 Let CDI handle #{applicationScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1328 Let CDI handle #{session} EL resolving Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1331 Let CDI handle #{application} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1332 Let CDI handle #{view} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1334 Let CDI handle #{viewScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1383 Let CDI handle #{cc} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1384 Let CDI handle #{component} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1385 Let CDI handle #{flash} Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open

 Comments   
Comment by Manfred Riem [ 15/Oct/14 ]

Make sure the appropriate spec text is added for:

application - describe that this only does EL resolving
applicationScope
externalContext
facesContext
session - describe that this only does EL resolving (core CDI does the @Inject for session)
view
viewScope

Comment by arjan tijms [ 30/Jul/15 ]

This is the current overview of the EL implicit variables handled by CDI:

* application
*+ applicationScope (applicationMap)
cc
component
+ cookie (requestCookieMap)
*+? externalContext
*+ facesContext
flash
flowScope
header
headerValues
initParam
param
paramValues
request
requestScope
resource
* session
+ sessionScope (sessionMap)
*+ view (view root)
*+ viewScope (viewMap)

* = Implemented via issue 1315 (this issue)
+ = Implemented via issue 1316
? = new implicit EL variable

Preliminary implementation of entries not yet committed in the 2.3 trunk: https://github.com/omnifaces/mojarra/commit/1fa3ad6f0919eedc613cf21d4390a9d20c80e39c

Comment by Manfred Riem [ 20/Aug/15 ]

r=mriem

Comment by arjan tijms [ 20/Aug/15 ]

Applied to 2.3 trunk:

svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1315, moved qualifiers to new annotation package. r=mriem"
Adding jsf-api/src/main/java/javax/faces/annotation
Adding jsf-api/src/main/java/javax/faces/annotation/ApplicationMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/RequestCookieMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/SessionMap.java
Adding jsf-api/src/main/java/javax/faces/annotation/ViewMap.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ApplicationMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/RequestCookieMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/SessionMapAnnotationLiteral.java
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ViewMapAnnotationLiteral.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMapBean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMap2Bean.java
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMapBean.java
Transmitting file data ................
Committed revision 15029.





[JAVASERVERFACES_SPEC_PUBLIC-1357] Make enum constants accessible from EL. Created: 01/Feb/15  Updated: 01/Feb/15

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

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


 Description   

Enum constants shall be accessible

Let me explain this by an example. Given an enum

public enum Page {

  Welcome("/welcome"),
  // many more...
  AdminWelcome("/admin/welcome");
  
  private Page(String url) {
    _url = url;
  }
  private final String _url;

  public String getUrl() {
    return _url + ".xhtml";
  }

  public String getRedirectUrl() {
    return _url + ".xhtml?faces-redirect=true";
  }
}

The goal is to access an URL of a specific member of that enum from an EL.

Declaring the enum as a named CDI bean (@Named) grants access to the methods, but the constants.

By now, there is an ugly workaround by mapping all entries and delegating from another bean to this

{enum Page)

  private static Map<String, String> _pages;

  public static Map<String, String> getPages() {
    if (_pages == null) {
      _pages = new HashMap<>();
      for (Page page : Page.values()) {
        _pages.put(page.name(), page.getUrl());
      }
    }
    return _pages;
  }

(otherBean)

  public Map<String, String> getPages() {
    return Page.getPages();
  }

Now access within EL is possible:

#{otherBean.pages.AdminCategoryEditor}}

--> The goal is to directly access the enum

#{page.AdminCategoryEditor.url}

The enum is used in a method

(otherBean)

  public String navigate(String topic) {
    // perform some useful stuff
    return topic;
  }

This can be used from EL

#{otherBean.navigate(otherBean.pages.AdminWelcome)}

It would be preferred to use an enum in the navigation method:

(otherBean)

  public String navigate(Page page) {
    // perform some useful stuff
    return page.getUrl();
  }

--> The goal is to directly access the enum

#{otherBean.navigate(page.AdminWelcome)}


 Comments   
Comment by muellermi [ 01/Feb/15 ]
{otherBean.navigate(AdminWelcome)}

should be

{otherBean.navigate(page.AdminWelcome)}




[JAVASERVERFACES_SPEC_PUBLIC-1378] Clear the view map on session destroy or when the ACTIVE_VIEW_MAPS_SIZE is reached and a view map is thrown away Created: 04/Jun/15  Updated: 04/Jun/15

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

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


 Description   

The full discussion is at JAVASERVERFACES-3947.
In brief: when the session is destroyed, the beans of all the active view maps are destroyed, however the view maps themselves are not cleared (hence, no PreDestroyViewMapEvent is fired).
The same happens when the eldest view map is thrown away because the ACTIVE_VIEW_MAPS_SIZE is reached.

However, when JSF is integrated with other CDI-like frameworks, like the Spring Framework, for instance through an appropriate EL resolver (org.springframework.web.jsf.el.SpringBeanFacesELResolver in this case) and appropriate hooks on the PostConstructViewMapEvent}}s and {{PreDestroyViewMapEvent}}s, view-scoped beans created by the external framework won't be cleared on the above cases because no {{PreDestroyViewMapEvent is fired (the Mojarra ViewScopeManager takes care of just destroying view-scoped beans managed by JSF BeanManager itself).

Manfred Riem says this is a specification problem, because no strict requirement is stated on this.






[JAVASERVERFACES_SPEC_PUBLIC-1418] CDI replacement for @ManagedProperty Created: 26/May/16  Updated: 01/Jun/16

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: None
Fix Version/s: 2.3

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

Issue Links:
Related
is related to JAVASERVERFACES-4149 Implement CDI replacement for @Manage... In Progress

 Description   

In JAVASERVERFACES_SPEC_PUBLIC-1417 the javax.faces.bean was deprecated. Pretty much everything in that package has a replacement elsewhere, except for @ManagedProperty.

Therefor I'd like to propose providing a CDI based replacement for @ManagedProperty. This should effectively evaluate an EL expression (using the JSF native EL facility) and inject the result into the target injection point.






[JAVASERVERFACES_SPEC_PUBLIC-1368] Static EL Resolution Doesn't Work Created: 28/Apr/15  Updated: 28/Apr/15

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

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


 Description   

EL 3.0 static field resolution on imported classes does not currently work in any JSF implementation, and it seems to come down to a spec issue. For example, the expression

<h:outputText value="#

{Boolean.TRUE}

" />

Prints out nothing, while it should print "true". Since ScopedAttributeELResolver must be the last resolver in the chain, modifying that resolver to resolve classes (via the importhandler, for example) allows these expressions to be resolved properly.

That fix was implemented by the Tomcat project here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57141
Related Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3362
Related UEL issue: https://java.net/jira/browse/UEL-40






[JAVASERVERFACES_SPEC_PUBLIC-946] Provide internal server path of resources from Resource API via EL Created: 20/Feb/11  Updated: 12/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium


 Description   

Currently JSF 2 provides #

{resource['libraryName:resourceName']}

to get the request path of the specified resource for the browser (e.g. /context-root/faces/javax.faces.resource/libraryName/resourceName). Thus #

{resource[...]}

is mostly used for css or js files.

Unfortunately there is no way to use the Resource API directly in EL to get the server path to internal resources, e.g. when using <ui:include src="..."> and referrencing a xhtml (facelet) page.

Of course, as a workaround, you can use this method in a managed bean:

public String getMyResourcePath()
{
FacesContext facesContext = FacesContext.getCurrentInstance();

Resource resource = facesContext.getApplication().getResourceHandler()
.createResource("myresource.xhtml", "mylibrary");
URL url = resource.getURL();

return url.toExternalForm();
}

However, this really only is a workaround.

I'd like to propose using #

{serverresource['...']}

or #

{internalresource['...']}

or #

{resoure['...'].serverPath}

(or something similar) to provide a convenient way for getting the server-path to the resource. This way users can use the facelets templating mechanism in combination with the Resource API, e.g.:

<ui:include src="#

{serverresource['templates:headInclude.xhtml']}

" />
<ui:component template="#

{serverresource['templates:componentTemplate.xhtml']}

">
...

See also the user-discussion from the MyFaces mailing list (showing that users are confused why #

{resource['']}

isn't working for facelets stuff): http://www.mail-archive.com/users@myfaces.apache.org/msg56907.html



 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-875] Add Facelets attribute to limit EL scope to explicitly declared parameters Created: 13/Aug/10  Updated: 01/Aug/14

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 875
Status Whiteboard:

size_medium importance_small


 Description   

>>>>> On Mon, 09 Aug 2010 21:08:00 -0400, Ryan de Laplante said:

R> It would be nice have a new attribute on ui:composition and ui:decorate
R> that tells it to NOT allow the template have access to the global EL
R> context. Instead, only the ui:insert and ui:param values within the
R> ui:composition or ui:decorate would be accessible to the template.
R> This I would enable me to allow my customers to input their own facelet
R> templates from the web UI of the SaaS application.



 Comments   
Comment by rogerk [ 13/Aug/10 ]

eval

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

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.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1313] EL support in faces-config.xml for dynamic contracts Created: 29/Sep/14  Updated: 31/Oct/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping, EL
Affects Version/s: 2.2
Fix Version/s: None

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


 Description   

Motivation
------
Introducing dynamic contracts is a tedious task because one has to change every view (http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/ResourceLibraryContract/resourceLibraryContract.html, "Changing Templates Dynamically") and the introduction of EL support for the faces-config would centralize this behavior in one place.

Proposal
------
Support the use of EL in the faces-config, e.g. to set the value of a "contracts" node of a "contract-mapping" similar to the following:

<faces-config version="2.2" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
    http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd">
    <application>
        <resource-library-contracts>
            <contract-mapping>
                <url-pattern>/*</url-pattern>
                <contracts>#{contracts.contract}</contracts>
            </contract-mapping>
        </resource-library-contracts>

    <!-- ... --->

Where contracts is a bean holding the contract string as contract property.






Generated at Wed Dec 07 21:38:47 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.