[jira] [Updated] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Leonardo Uribe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leonardo Uribe updated MYFACES-4042:

   Resolution: Fixed
 Assignee: Leonardo Uribe
Fix Version/s: 2.2.10
   Status: Resolved  (was: Patch Available)

I have committed a modified version of the patch, adding some documentation and 
also including the check for a system property is the one in web.xml is not 
set. Thanks to Bill Lucy for provide this patch.

> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.2.10
>
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Proposed April 2016 MyFaces Board Report

[Mike Kienenberger]

Here's my proposed board report.  Comments welcome.

Report from the Apache MyFaces committee [Mike Kienenberger]

## Description:
The Apache MyFaces project is an umbrella project of the Apache Software
Foundation for projects relating to the JavaServer Faces (JSF) technology.

## Activity and health:
- Apache Myfaces Core is healthy and in maintenance mode.

UI-Component Sets:
- Apache Tobago is healthy and active.
- Apache Trinidad continues to have issues opened and interest expressed by
  end-users.  Leonardo Uribe proposed a release candidate in February, but
  the release has yet to receive any votes.  I'm one of those guilty of not
  finishing my release review yet. Last commit on behalf of a contributor was
  January 2015.
- Myfaces Tomahawk is in maintenance mode and has had very little activity
  this quarter. Last commit on behalf of a contributor was April 2015.

Add-ons and Extensions:
- Apache MyFaces Portlet Bridge is in maintenance mode.  Last developer commit
  was Jan 2014.  Last commit on behalf of a contributor was May 2015.
- Apache MyFaces CODI is in maintenance mode. CODI was replaced by Apache
  DeltaSpike so new development happens there.  Last commit March 2014.
- Apache MyFaces Orchestra is in maintenance mode.  New projects use CDI and
  DeltaSpike instead.  Last commit December 2014.
- Apache MyFaces ExtVal is in maintenance mode. Last commit June 2014.
- Apache MyFaces Commons is in maintenance mode.  Last commit August 2012.
- Apache MyFaces Ext-Scripting is in maintenance mode.  Last commit Dec 2012.
- Apache MyFaces Test is in maintenance mode (Used by Myfaces Core).  Last
  commit June 2014.

## Community changes:

- Currently 76 committers and 42 PMC members.
- Last committer addition was Thomas Andraschko at Thu Jul 02 2015
- Last PMC additions were Bill Lucy and Thomas Andraschko on Fri Jan 15 2016

## Releases:

- Apache Tobago 2.0.9 was released on Sun Jan 31 2016
- Apache Myfaces Core 2.0.24 was released on Wed Mar 30 2016
- Apache Myfaces Core 2.1.18 was released on Wed Mar 30 2016

## Mailing list activity:

 - us...@myfaces.apache.org:
- 744 subscribers (down -3 in the last 3 months):
- 27 emails sent to list (20 in previous quarter)

 - dev@myfaces.apache.org:
- 309 subscribers (down -3 in the last 3 months):
- 356 emails sent to list (316 in previous quarter)

## JIRA activity:

 - 47 JIRA tickets created in the last 3 months
 - 54 JIRA tickets closed/resolved in the last 3 months

[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225102#comment-15225102
 ] 

Leonardo Uribe commented on MYFACES-4042:
-

The problem is there is no place to indicate that "globally". Every config 
param is loaded from the web.xml file. 

For example, in tomcat 7 there is a config option that can be specified in 
catalina.properties :

{code}
# Additional JARs (over and above the default JARs listed above) to skip when
# scanning for Servlet 3.0 pluggability features. These features include web
# fragments, annotations, SCIs and classes that match @HandlesTypes. The list
# must be a comma separated list of JAR file names.
org.apache.catalina.startup.ContextConfig.jarsToSkip=
{code}

This file adds a system property. What I mean is we could make a system 
property instead a web config param property (or both with the same name takes 
precedence the web config param). It is the same as how org.apache.el.parser. 
COERCE_TO_ZERO works.

> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225078#comment-15225078
 ] 

Bill Lucy commented on MYFACES-4042:


Right, those mapping rules make sense.  My logic here, though, is that 11.4.2 
says that we can essentially skip that automatic mapping for performance, so 
why don't we make it configurable?

> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225059#comment-15225059
 ] 

Leonardo Uribe commented on MYFACES-4042:
-

The javadoc of FacesServlet specifies the conditions that requires to map the 
servlet automatically. See MYFACES-3093 for details.

> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15225008#comment-15225008
 ] 

Thomas Andraschko commented on MYFACES-4042:


I'm really not sure why this is required actually.
Why not just remove the MyFaces dependency if you don't need JSF in this 
project?

ApplicationsServers like TomEE should have a special integration and skip 
faces-config.xml scanning if no FacesServlet is defined in the web.xml.

> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Mike Kienenberger]

We can add non-default spec-breaking behavior by means of
configuration parameters.

If "org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN" is of
value for someone, add it in.


On Mon, Apr 4, 2016 at 4:07 PM, Bill Lucy (JIRA)  wrote:
>
> [ 
> https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224957#comment-15224957
>  ]
>
> Bill Lucy commented on MYFACES-4042:
> 
>
> Based on what the spec says, I think it's valid for us to skip the 
> faces-config.xml scanning if the user doesn't explicitly put the FacesServlet 
> in their web.xml.
>
> There are cases of users depending on MyFaces dynamically adding a 
> FacesServlet for the various faces-config.xml possibilities, though.  I think 
> that if we do make a change leaving this configurable would be a good idea.
>
>> Improve startup time by skipping classpath jar scan for *.faces-config.xml
>> --
>>
>> Key: MYFACES-4042
>> URL: https://issues.apache.org/jira/browse/MYFACES-4042
>> Project: MyFaces Core
>>  Issue Type: Improvement
>>Affects Versions: 2.1.18, 2.2.9
>> Environment: WebSphere
>>Reporter: Bill Lucy
>>Priority: Minor
>> Attachments: MYFACES-4042.patch
>>
>>
>> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was 
>> updated to scan for faces-config.xml resources in applications JARs during 
>> startup, as part of the process to add a FacesConfig in onStartup().  This 
>> is a very expensive scan, since we have to iterate over every file in every 
>> jar on the app classpath.
>> This scan is not completely necessary: in the spec we have:
>> Section 11.4.2 “Application Startup Behavior”
>> Implementations may check for the presence of a servlet-class definition of 
>> class javax.faces.webapp.FacesServlet in the web application deployment 
>> descriptor as a means to abort the configuration process and reduce startup 
>> time for applications that do not use JavaServer Faces Technology.
>> Which I interpret to mean that skipping checking the app jars at init time - 
>> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
>> performance hit for the scan, I think adding a context param to disable the 
>> scan would be worthwhile.  Something like:
>> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
>> Would this be worthwhile for others?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Bill Lucy (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224957#comment-15224957
 ] 

Bill Lucy commented on MYFACES-4042:


Based on what the spec says, I think it's valid for us to skip the 
faces-config.xml scanning if the user doesn't explicitly put the FacesServlet 
in their web.xml.

There are cases of users depending on MyFaces dynamically adding a FacesServlet 
for the various faces-config.xml possibilities, though.  I think that if we do 
make a change leaving this configurable would be a good idea.

> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15224901#comment-15224901
 ] 

Thomas Andraschko commented on MYFACES-4042:


For me it sounds like:
If the user doesn't add the FacesServlet to the web.xml, we can skip 
faces-config.xml scanning.

Is there any case that users may add MyFaces as dependency and don't use it?



> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Bill Lucy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Lucy updated MYFACES-4042:
---
Status: Patch Available  (was: Open)

> Improve startup time by skipping classpath jar scan for *.faces-config.xml
> --
>
> Key: MYFACES-4042
> URL: https://issues.apache.org/jira/browse/MYFACES-4042
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.1.18, 2.2.9
> Environment: WebSphere
>Reporter: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4042.patch
>
>
> In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
> to scan for faces-config.xml resources in applications JARs during startup, 
> as part of the process to add a FacesConfig in onStartup().  This is a very 
> expensive scan, since we have to iterate over every file in every jar on the 
> app classpath.  
> This scan is not completely necessary: in the spec we have:
> Section 11.4.2 “Application Startup Behavior”
> Implementations may check for the presence of a servlet-class definition of 
> class javax.faces.webapp.FacesServlet in the web application deployment 
> descriptor as a means to abort the configuration process and reduce startup 
> time for applications that do not use JavaServer Faces Technology.
> Which I interpret to mean that skipping checking the app jars at init time - 
> for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
> performance hit for the scan, I think adding a context param to disable the 
> scan would be worthwhile.  Something like:
> org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN
> Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYFACES-4042) Improve startup time by skipping classpath jar scan for *.faces-config.xml

[Bill Lucy (JIRA)]

Bill Lucy created MYFACES-4042:
--

 Summary: Improve startup time by skipping classpath jar scan for 
*.faces-config.xml
 Key: MYFACES-4042
 URL: https://issues.apache.org/jira/browse/MYFACES-4042
 Project: MyFaces Core
  Issue Type: Improvement
Affects Versions: 2.2.9, 2.1.18
 Environment: WebSphere
Reporter: Bill Lucy
Priority: Minor


In version 2.1 org.apache.myfaces.ee6.MyFacesContainerInitializer was updated 
to scan for faces-config.xml resources in applications JARs during startup, as 
part of the process to add a FacesConfig in onStartup().  This is a very 
expensive scan, since we have to iterate over every file in every jar on the 
app classpath.  

This scan is not completely necessary: in the spec we have:
Section 11.4.2 “Application Startup Behavior”
Implementations may check for the presence of a servlet-class definition of 
class javax.faces.webapp.FacesServlet in the web application deployment 
descriptor as a means to abort the configuration process and reduce startup 
time for applications that do not use JavaServer Faces Technology.

Which I interpret to mean that skipping checking the app jars at init time - 
for the purpose of adding a dynamic FacesServlet - is valid.  Given the 
performance hit for the scan, I think adding a context param to disable the 
scan would be worthwhile.  Something like:
org.apache.myfaces.INITIALIZE_SKIP_JAR_FACES_CONFIG_SCAN

Would this be worthwhile for others?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MYFACES-4041) EL evaluation fails when state is saved because FaceletState object is not present

[Leonardo Uribe (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Leonardo Uribe updated MYFACES-4041:

Status: Patch Available  (was: Open)

> EL evaluation fails when state is saved because FaceletState object is not 
> present
> --
>
> Key: MYFACES-4041
> URL: https://issues.apache.org/jira/browse/MYFACES-4041
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344
>Affects Versions: 2.2.9
>Reporter: Martin Marinschek
>Assignee: Leonardo Uribe
>Priority: Blocker
> Fix For: 2.2.10
>
>
> DefaultFaceletsStateManagementStrategy.saveView(...) contains some lines of 
> code that do this:
> {code:java}
> states = new HashMap();
> faceletViewState = 
> view.getAttributes().get(ComponentSupport.FACELET_STATE_INSTANCE);
> if (faceletViewState != null)
> {
> ((Map Object>)states).put(ComponentSupport.FACELET_STATE_INSTANCE,
> UIComponentBase.saveAttachedState(context, 
> faceletViewState));
> //Do not save on UIViewRoot
> 
> view.getAttributes().remove(ComponentSupport.FACELET_STATE_INSTANCE);
> }
> {code}
> The problem is FaceletState is removed to be serialized, but FaceletState is 
> also used for EL expressions (see FaceletStateValueExpression), so every EL 
> expression that is evaluated when the state is being saved that depends on 
> this map throws NullPointerException.
> The problem has been experienced by other users before (see MYFACES-4023 for 
> details), but in the case reported here (treeTable component and dynamic 
> columns) there is no other possible workaround than to preserve FaceletState 
> object so the EL can be properly evaluated.
> The solution is use the transient state helper map to hold FaceletState and 
> change FaceletStateValueExpression to scan for this condition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] release of MyFaces Core 2.2.10

[Leonardo Uribe]

Hi

I was about to close this vote, but recently a new bug has been reported.
See:

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

This issue is important, and deserves to be included in the next release.
I'll apply the patch, rollback the release and resend a vote over the new
artifacts. Thanks for your patience.

regards,

Leonardo Uribe



This
email is safe. www.avast.com

<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2016-03-30 16:19 GMT-05:00 Bill Lucy :

> +1
>
>
> On Wed, Mar 30, 2016 at 12:42 PM, Grant Smith 
> wrote:
>
>> +1
>>
>> Grant Smith - V.P. Information Technology
>> Marathon Computer Systems, LLC.
>>
>> On Wed, Mar 30, 2016 at 8:07 AM, Dennis Kieselhorst 
>> wrote:
>>
>>> +1
>>>
>>
>>
>

[jira] [Created] (MYFACES-4041) EL evaluation fails when state is saved because FaceletState object is not present

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4041:
---

 Summary: EL evaluation fails when state is saved because 
FaceletState object is not present
 Key: MYFACES-4041
 URL: https://issues.apache.org/jira/browse/MYFACES-4041
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.9
Reporter: Martin Marinschek
Assignee: Leonardo Uribe
Priority: Blocker


DefaultFaceletsStateManagementStrategy.saveView(...) contains some lines of 
code that do this:

{code:java}
states = new HashMap();

faceletViewState = 
view.getAttributes().get(ComponentSupport.FACELET_STATE_INSTANCE);
if (faceletViewState != null)
{
((Map)states).put(ComponentSupport.FACELET_STATE_INSTANCE,
UIComponentBase.saveAttachedState(context, 
faceletViewState));
//Do not save on UIViewRoot

view.getAttributes().remove(ComponentSupport.FACELET_STATE_INSTANCE);
}
{code}

The problem is FaceletState is removed to be serialized, but FaceletState is 
also used for EL expressions (see FaceletStateValueExpression), so every EL 
expression that is evaluated when the state is being saved that depends on this 
map throws NullPointerException.

The problem has been experienced by other users before (see MYFACES-4023 for 
details), but in the case reported here (treeTable component and dynamic 
columns) there is no other possible workaround than to preserve FaceletState 
object so the EL can be properly evaluated.

The solution is use the transient state helper map to hold FaceletState and 
change FaceletStateValueExpression to scan for this condition.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)