[jira] [Commented] (MYFACES-4318) c:forEach problem with client side state saving

[Leonardo Uribe (Jira)]

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

Leonardo Uribe commented on MYFACES-4318:
-

The example provided will never work, because c:forEach is a tag that only 
works on build view time. The value inside "current" var is lost on render 
response time, because c:forEach does not have a counterpart at that time.

In other words, c:forEach just does not play well with JSF lifecycle. So, this 
is not a bug, the example provided is not correct, and there is no valid 
workaround for it.

Don't waste time trying to fix it, it is pointless and you will end up chasing 
you own tail. The answer is simple, use other iteration component that has a 
JSF component counterpart.

 

> c:forEach problem with client side state saving
> ---
>
> Key: MYFACES-4318
> URL: https://issues.apache.org/jira/browse/MYFACES-4318
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.6
>Reporter: Bill Lucy
>Priority: Major
> Attachments: jsf_foreach_client_state.war, 
> jsf_foreach_client_state_mvn.zip
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> There appears to be a problem with c:forEach when client side state saving is 
> enabled -  component states are not restored correctly after a submit.  For 
> example, the text entered into this inputText is lost:
> {{{color:#80} {color:#ff}var{color}{color:#00}={color}{color:#ff}"current"{color}
>  
> {color:#ff}items{color}{color:#00}={color}{color:#ff}"#\{list.items}"{color}{color:#80}>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"#\{current.value}"{color}{color:#80}/>{color}}}
> {{{color:#80} {color:#ff}value{color}{color:#00}={color}{color:#ff}"submit"{color}{color:#80}/>{color}}}
> {{{color:#80}{color}}}
>  
> This example works (the inputText is not lost) with server side state saving 
> enabled, and it also works on Mojarra with client side state saving. I 
> haven't figured out what exactly is causing this behavior yet - if anyone 
> else has insight in this area I'd appreciate hints.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MYFACES-4281) tag parsing error

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4281:
-

Facelets compiler cannot process other namespaces like that one. It tries to 
check if the namespace is used for facelets tags and just fail.

The compiler was not designed to process that, so it is not a bug by itself. 
The only way to fix it is create a tag that can handle mathml or something like 
that, or teach the compiler how to detect and process these kind of namespaces. 

 

> tag parsing error
> -
>
> Key: MYFACES-4281
> URL: https://issues.apache.org/jira/browse/MYFACES-4281
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: maurel
>Priority: Major
> Attachments: Bildschirmfoto 2019-02-06 um 17.08.30.png
>
>
> see: [mailing 
> list|http://mail-archives.apache.org/mod_mbox/myfaces-users/201901.mbox/%3C371d7273-62ee-0279-2866-5614d72b0460%40gmail.com%3E]
> Using Tobago 4.3.0, I see the below error when I use the following xhtml 
> page. I tried to make this page as small as possible to reproduce the error.
> If I remove one of the  group the error is removed.
> I work on windows 10 and both firefox or opera have the same behaviour.
> Could you please advice or correct me ?
> Regards
> xhtml page:
> ---
> 
> http://java.sun.com/jsf/facelets; 
> xmlns:xs="http://www.w3.org/2001/XMLSchema; 
> xmlns:f="http://java.sun.com/jsf/core; xmlns="http://www.w3.org/1999/xhtml;
>   xmlns:tc="http://myfaces.apache.org/tobago/component; 
> xmlns:xhtml="http://www.w3.org/1999/xhtml;
>  >
>   
>
> 
>  http://www.w3.org/1998/Math/MathML; >
>N
> 
> 
> nombre
> 
>  http://www.w3.org/1998/Math/MathML;>
>C
> 
> 
> constante
> 
>  http://www.w3.org/1998/Math/MathML;>
>   σ
> 
> 
> étendue
>
>   
> 
> ERROR:
> -
> janv. 25, 2019 5:50:57 PM 
> org.apache.myfaces.tobago.internal.webapp.DebugResponseWriterWrapper 
> endElement
> GRAVE: Element end with name='HTML' doesn't match with top element on 
> the stack='BODY'.
> java.lang.IllegalArgumentException
>  at 
> org.apache.myfaces.tobago.internal.webapp.DebugResponseWriterWrapper.endElement(DebugResponseWriterWrapper.java:226)
>  at 
> org.apache.myfaces.tobago.internal.renderkit.renderer.PageRenderer.encodeEnd(PageRenderer.java:366)
>  at 
> javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:675)
>  at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:555)
>  at 
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:551)
>  at 
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1897)
>  at 
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:315)
>  at 
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:73)
>  at 
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:117)
>  at 
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:266)
>  at javax.faces.webapp.FacesServlet.service(FacesServlet.java:206)
>  at 
> org.apache.tomee.myfaces.TomEEWorkaroundFacesServlet.service(TomEEWorkaroundFacesServlet.java:47)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>  at 
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>  at org.apache.openejb.server.httpd.EEFilter.doFilter(EEFilter.java:65)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>  at 
> org.apache.myfaces.tobago.facelets.FixCharacterEncodingFilter.doFilter(FixCharacterEncodingFilter.java:54)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>  at 
> org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.java:71)
>  at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
>  at 
> 

[jira] [Deleted] (MFHTML5-21) I'm not sure if I can make it to the meeting tonight but I will be there in the morning to see how you are doing and if you want to come by and see you tomorrow at lefty

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe deleted MFHTML5-21:
--


> I'm not sure if I can make it to the meeting tonight but I will be there in 
> the morning to see how you are doing and if you want to come by and see you 
> tomorrow at lefty from perths pad and
> -
>
> Key: MFHTML5-21
> URL: https://issues.apache.org/jira/browse/MFHTML5-21
> Project: MyFaces HTML5 Component Library
>  Issue Type: New Feature
>Reporter: Andrew andalon
>Priority: Critical
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4225) [perf] Cache whether a library exists in ExternalContextResourceLoader

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4225:
-

There is already a cache for that in place.

org.apache.myfaces.RESOURCE_HANDLER_CACHE_ENABLED

org.apache.myfaces.shared.resource.ResourceHandlerCache

It is enabled by default. 

> [perf] Cache whether a library exists in ExternalContextResourceLoader
> --
>
> Key: MYFACES-4225
> URL: https://issues.apache.org/jira/browse/MYFACES-4225
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.11
>Reporter: Christian Beikov
>Priority: Major
>
> I'm seeing many {{sun.nio.fs.UnixException}} being thrown in the underlying 
> code because {{ExternalContextResourceLoader.libraryExists}} calls 
> {{ExternalContext.getResource}} which in the end checks if a file exists on 
> the FS. I'd suggest when the project stage is PRODUCTION, this should be 
> cached. Maybe this could be done by installing an {{ExternalContextWrapper}} 
> that caches all resource lookups? I just see that parsing a XHTML causes many 
> exceptions to be thrown internally which negatively affects performance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MYFACES-4175) template XHTML file fails to load when in /resources dir

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4175:
-

I'm sure of it. The problem here is without "top-level-views" concept, things 
like EL caching, view caching, stateless views and others will not work. Top 
level views requires some initialization steps that normal templates do not. 

> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4175) template XHTML file fails to load when in /resources dir

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4175:
-

In my opinion the example submitted is invalid. The reason is you can't include 
a view inside another view and hope everything magically works. 

What I mean is a top level view is "special" and everything inside it is a 
"template". 

You can create compositions using templates, but a template cannot be a top 
level view under any circustance, and the API should provide ways to avoid that 
scenario. So, what's invalid is the call from 
resourceHandler.createViewResource(...). It doesn't make sense, that's not the 
way how that API works.

There is a test package in myfaces core impl project called 
org.apache.myfaces.view.facelets.pss.acid that has a lot of examples about how 
you can load a template dynamically to a view. There are two accepted methods: 
use component binding and dynamic subscribe to PreRenderViewEvent. 

> template XHTML file fails to load when in /resources dir
> 
>
> Key: MYFACES-4175
> URL: https://issues.apache.org/jira/browse/MYFACES-4175
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSFTestResources.war, MYFACES-4175.patch
>
>
> Please consider the following scenario, I've attached a sample app. 
> I have a template in the resources/templates directory.  The request to 
> localhost:8080/JSFTestResources/mapViewIdToResource.jsf fails when MyFaces to 
> load the basicTemplate.xhtml  file which is located in the 
> /resources/templates directory for the composite component.  The backing bean 
> uses the ResourceHandler to create the view resources.
> The reason this fails in JSF 2.3 is due to the change in the 
> org.apache.myfaces.resource.RootExternalContextResourceLoader.getResourceURL(String)
>  method.  
> In JSF 2.3, the method added a check to see if the resourceId starts wiht the 
> contractsDirectory or resourcesDirectory.  If it does then the getResourceURL 
> returns null which tells the ResourceLoader that the resource does not exist. 
>  In JSF 2.2, those checks were not there.
> I checked the change history for this class and I see that MYFACES-4105 added 
> this change.  In that JIRA I see the comment made that says:
> "One last review is required to check if xhtml files under forbidden 
> extensions are being loaded (/resources, /contracts and so on)."
> Therefore, this falls in to the JIRA comment mentioned above.  To me, the 
> test I've attached seems to be a valid scenario and MyFaces should be 
> allowing this resource to be found instead of returning null.  I don't see 
> anywhere in the spec that says MyFaces should be behaving in that manner. 
> Please correct me if I'm wrong.
> Also, this app works with MyFaces JSF 2.2 and also with Mojarra JSF 2.3.  
> With MyFaces JSF 2.3 I get a NPE:
> java.lang.NullPointerException
>   
> com.test.MapResourcePathBean.mapViewIdToResource(MapResourcePathBean.java:56)
>   sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
>   
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>   java.lang.reflect.Method.invoke(Method.java:508)
>   javax.el.BeanELResolver.invoke(BeanELResolver.java:158)
>   javax.el.CompositeELResolver.invoke(CompositeELResolver.java:79)
>   org.apache.el.parser.AstValue.getValue(AstValue.java:159)
>   org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:184)
>   
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:93)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe reopened MYFACES-4133:
-

There are some details we need to discuss with the patch.

The following classes were removed:

StateTokenProcessor
IntIntSerializedViewKey
CounterSessionViewStorageFactory
IntByteArraySerializedViewKey
CounterKeyFactory

And some new methods were added to StateCache. This requires a discussion on 
dev list, but I need to review the improvements proposed first. 

> Don't deserialize the ViewState-ID if the state saving method is server
> ---
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>Assignee: Thomas Andraschko
> Fix For: 2.3.0
>
> Attachments: 2.1.x-r1817658-r1817712.patch, MYFACES-4133.patch, 
> trunk-r1817658-r1817806.patch
>
>
> Currently the ViewState-ID provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4176) Search expression fails to resolve component outside of form

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4176.
-
Resolution: Fixed
  Assignee: Leonardo Uribe  (was: Thomas Andraschko)

I implemented an alternate algorithm using findComponent avoiding duplicated 
recursion, it is better than use invokeOnComponent, since it search in backward 
direction

> Search expression fails to resolve component outside of form
> 
>
> Key: MYFACES-4176
> URL: https://issues.apache.org/jira/browse/MYFACES-4176
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSF23AjaxTest.war
>
>
> There seems to be a bug in the 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl class when a 
> client id is specified in the render attribute that is outside of the form 
> that the f:ajax component resides.  
> For example:
> {noformat}
> 
> 
>  action="#{testBean.test()}">
> 
> 
> 
> 
> 
> 
> {noformat}
> You can see that the commandButton and ajax components are within the form 
> but the render attribute specified is outside of it.  
> When the Ajax code is generated for the button, you can see that render 
> section is pointing to the commandButton id instead of the specified 
> 'testOutput1' id that is actually specified in the f:ajax render attribute.  
> {panel:title=JSF 2.3}
> onclick="jsf.util.chain(this, 
> event,'jsf.ajax.request(this,event,{*render:\'form1:testButton1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> When this same scenario is tested on JSF 2.2, the render section is 
> correct...pointing to the testOutput1 id.
> {panel:title=JSF 2.2}
> onclick="jsf.util.chain(document.getElementById('form1:testButton1'), 
> event,'jsf.ajax.request(\'form1:testButton1\',event,{*render:\'testOutput1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> This scenario also works on Mojarra JSF 2.3.
> I debugged the issue and it seems 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.invokeOnComponent
>  method, the "expression" variable has the correct value that we want to 
> render ("testOutput1") but it is unable to find this component because it 
> only searches within the form. My thought is that the code should try to 
> iterate through the parent.getParent to try to find the id it's looking for.  
> The code looks as though it's doing that (around line 163). However, in this 
> scenario the code path never drops in to that block of code.  What ends up 
> happening is the client id of the commandButton is returned.  Therefore, the 
> testOutput1 component is not updated when the button is clicked. 
> I've attached a testcase to easily reproduce the scenario.  This could 
> potentially be a high impact issue since partial request aren't updating 
> components outside of their immediate parent.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4176) Search expression fails to resolve component outside of form

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4176:
-

I have checked the problem and it seems to be a case not covered by the spec.
So, the algorithm works as expected, it makes a relative search from a 
component, but only looks in the surroundings of the component, or the closest 
NamingContainer. The algorithm tries to find a base naming container and start 
the search from that point.

Now, the default implementation of invokeOnComponent always start from 
UIViewRoot, and since we are trying to replace the old behavior the algorithm 
fails to take a look from the component to the top if the passed expression is 
not a keyword.

The algorithm is recursive by nature, but we should avoid call 
UIViewRoot.invokeOnComponent, because that's not what's supposed to do, it is 
brute force and the recursion becomes out of control. Instead, we should use 
UIComponent.findComponent but from the closest NamingContainer to UIViewRoot 
going backwards. This only applies if there is no  ':'  in the expression and 
there is no keywords or the base component has been set. 

I'll try to fix it, let's see what happens.

> Search expression fails to resolve component outside of form
> 
>
> Key: MYFACES-4176
> URL: https://issues.apache.org/jira/browse/MYFACES-4176
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSF23AjaxTest.war
>
>
> There seems to be a bug in the 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl class when a 
> client id is specified in the render attribute that is outside of the form 
> that the f:ajax component resides.  
> For example:
> {noformat}
> 
> 
>  action="#{testBean.test()}">
> 
> 
> 
> 
> 
> 
> {noformat}
> You can see that the commandButton and ajax components are within the form 
> but the render attribute specified is outside of it.  
> When the Ajax code is generated for the button, you can see that render 
> section is pointing to the commandButton id instead of the specified 
> 'testOutput1' id that is actually specified in the f:ajax render attribute.  
> {panel:title=JSF 2.3}
> onclick="jsf.util.chain(this, 
> event,'jsf.ajax.request(this,event,{*render:\'form1:testButton1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> When this same scenario is tested on JSF 2.2, the render section is 
> correct...pointing to the testOutput1 id.
> {panel:title=JSF 2.2}
> onclick="jsf.util.chain(document.getElementById('form1:testButton1'), 
> event,'jsf.ajax.request(\'form1:testButton1\',event,{*render:\'testOutput1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> This scenario also works on Mojarra JSF 2.3.
> I debugged the issue and it seems 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.invokeOnComponent
>  method, the "expression" variable has the correct value that we want to 
> render ("testOutput1") but it is unable to find this component because it 
> only searches within the form. My thought is that the code should try to 
> iterate through the parent.getParent to try to find the id it's looking for.  
> The code looks as though it's doing that (around line 163). However, in this 
> scenario the code path never drops in to that block of code.  What ends up 
> happening is the client id of the commandButton is returned.  Therefore, the 
> testOutput1 component is not updated when the button is clicked. 
> I've attached a testcase to easily reproduce the scenario.  This could 
> potentially be a high impact issue since partial request aren't updating 
> components outside of their immediate parent.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4176) Search expression fails to resolve component outside of form

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4176:
-

Checked h:outputLabel, use SearchExpressionHint.IGNORE_NO_RESULT is correct in 
this case.

Still the solution of the initial bug report worries me, maybe it is a case not 
covered but we need to check if the spec language matches.

> Search expression fails to resolve component outside of form
> 
>
> Key: MYFACES-4176
> URL: https://issues.apache.org/jira/browse/MYFACES-4176
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSF23AjaxTest.war
>
>
> There seems to be a bug in the 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl class when a 
> client id is specified in the render attribute that is outside of the form 
> that the f:ajax component resides.  
> For example:
> {noformat}
> 
> 
>  action="#{testBean.test()}">
> 
> 
> 
> 
> 
> 
> {noformat}
> You can see that the commandButton and ajax components are within the form 
> but the render attribute specified is outside of it.  
> When the Ajax code is generated for the button, you can see that render 
> section is pointing to the commandButton id instead of the specified 
> 'testOutput1' id that is actually specified in the f:ajax render attribute.  
> {panel:title=JSF 2.3}
> onclick="jsf.util.chain(this, 
> event,'jsf.ajax.request(this,event,{*render:\'form1:testButton1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> When this same scenario is tested on JSF 2.2, the render section is 
> correct...pointing to the testOutput1 id.
> {panel:title=JSF 2.2}
> onclick="jsf.util.chain(document.getElementById('form1:testButton1'), 
> event,'jsf.ajax.request(\'form1:testButton1\',event,{*render:\'testOutput1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> This scenario also works on Mojarra JSF 2.3.
> I debugged the issue and it seems 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.invokeOnComponent
>  method, the "expression" variable has the correct value that we want to 
> render ("testOutput1") but it is unable to find this component because it 
> only searches within the form. My thought is that the code should try to 
> iterate through the parent.getParent to try to find the id it's looking for.  
> The code looks as though it's doing that (around line 163). However, in this 
> scenario the code path never drops in to that block of code.  What ends up 
> happening is the client id of the commandButton is returned.  Therefore, the 
> testOutput1 component is not updated when the button is clicked. 
> I've attached a testcase to easily reproduce the scenario.  This could 
> potentially be a high impact issue since partial request aren't updating 
> components outside of their immediate parent.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (MYFACES-4176) Search expression fails to resolve component outside of form

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe reopened MYFACES-4176:
-

About h:outputLabel example: I don't think we should make it backward 
compatible. It is clear there is a syntax error here, because "for" it is 
pointing to a component that does not exists. We need to review search 
expression algorithm here. Please note this algorithm was contributed from 
MyFaces side, so the same algorithm here is in RI (Mojarra). I'll review this 
and give my thoughts.

> Search expression fails to resolve component outside of form
> 
>
> Key: MYFACES-4176
> URL: https://issues.apache.org/jira/browse/MYFACES-4176
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Jay Sartoris
>Assignee: Thomas Andraschko
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: JSF23AjaxTest.war
>
>
> There seems to be a bug in the 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl class when a 
> client id is specified in the render attribute that is outside of the form 
> that the f:ajax component resides.  
> For example:
> {noformat}
> 
> 
>  action="#{testBean.test()}">
> 
> 
> 
> 
> 
> 
> {noformat}
> You can see that the commandButton and ajax components are within the form 
> but the render attribute specified is outside of it.  
> When the Ajax code is generated for the button, you can see that render 
> section is pointing to the commandButton id instead of the specified 
> 'testOutput1' id that is actually specified in the f:ajax render attribute.  
> {panel:title=JSF 2.3}
> onclick="jsf.util.chain(this, 
> event,'jsf.ajax.request(this,event,{*render:\'form1:testButton1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> When this same scenario is tested on JSF 2.2, the render section is 
> correct...pointing to the testOutput1 id.
> {panel:title=JSF 2.2}
> onclick="jsf.util.chain(document.getElementById('form1:testButton1'), 
> event,'jsf.ajax.request(\'form1:testButton1\',event,{*render:\'testOutput1 
> \'*,\'javax.faces.behavior.event\':\'action\'})'); return false;"
> {panel}
> This scenario also works on Mojarra JSF 2.3.
> I debugged the issue and it seems 
> org.apache.myfaces.component.search.SearchExpressionHandlerImpl.invokeOnComponent
>  method, the "expression" variable has the correct value that we want to 
> render ("testOutput1") but it is unable to find this component because it 
> only searches within the form. My thought is that the code should try to 
> iterate through the parent.getParent to try to find the id it's looking for.  
> The code looks as though it's doing that (around line 163). However, in this 
> scenario the code path never drops in to that block of code.  What ends up 
> happening is the client id of the commandButton is returned.  Therefore, the 
> testOutput1 component is not updated when the button is clicked. 
> I've attached a testcase to easily reproduce the scenario.  This could 
> potentially be a high impact issue since partial request aren't updating 
> components outside of their immediate parent.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4058) ProtectedViewException for a protectedview access while checking the OriginHeader for appContextPath

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4058:
-

I think if Origin header should not contain app path, it is ok to do so, 
because the intention was to check the origin header. A context param 
org.apache.myfaces.STRICT_JSF_2_ORIGIN_HEADER_APP_PATH could work.

> ProtectedViewException for a protectedview access while checking the 
> OriginHeader for appContextPath
> 
>
> Key: MYFACES-4058
> URL: https://issues.apache.org/jira/browse/MYFACES-4058
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.6
> Environment: Windows, JSF 2.2
>Reporter: Dinesh Kumar A S
> Attachments: MYFACES-4058.patch
>
>
> Getting ProtectedViewException while accessing a protectedview/xhtml, while 
> checking the OriginHeader for appContextPath..
> SO reference : 
> http://stackoverflow.com/questions/38308431/jsf-2-2-protectedviewexception-due-to-origin-header-and-appcontextpath-mismatch
> Any help is much appreciated.
> Does the "Origin" request-header is supposed to have the appContextPath in 
> the path/urlInfo ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4164) Unexpected behavior when javax.faces.ViewState is set to "stateless" in a State view

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4164:
-

Strange, I remember there was a check in some place for that condition 
(stateful view with stateless view state).

> Unexpected behavior when javax.faces.ViewState is set to "stateless" in a 
> State view
> 
>
> Key: MYFACES-4164
> URL: https://issues.apache.org/jira/browse/MYFACES-4164
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12, 2.3.0-beta
>Reporter: Eduardo Breijo
> Attachments: ProtectedViewStateless.war
>
>
> I have encountered an issue or an unexpected behavior with a stateless value 
> of “javax.faces.ViewState” hidden input.
> Let’s say you navigate to a state view. When the value attribute of 
> “javax.faces.ViewState” is changed manually using browser’s developer tools, 
> the application can prevent CSRF attack by throwing a ViewExpiredException. 
> However, if you modify the value to be “stateless”, then no 
> ViewExpiredException is thrown.
> Even if you add View Protection to the state view, and modify the value to be 
> “stateless”, no exception is thrown. 
> The following JIRA issue said that this should be prevented with View 
> Protections but it seems that’s not working.
> https://issues.apache.org/jira/browse/MYFACES-3714
> Comparing this behavior with Mojarra, if the you modify the value to be 
> “stateless”, then the following exception is thrown:
> javax.faces.FacesException: Unable to restore view /stateView.xhtml
>   
> com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:255)
>   
> com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:157)
>   
> javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:125)
>   
> com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:204)
> com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> I have provided a sample app that demonstrates this behavior.
> Instructions to recreate the behavior on Tomcat:
> 1)Deploy the app on tomcat
> 2)Drive a request to 
> http://localhost:8080/ProtectedViewStateless/index.xhtml
> 3)Click the “Navigate to State View” link
> 4)Open the Browser’s Developer Tools and modify the value of 
> “javax.faces.ViewState” to “stateless”
> 5)Click the “Go to Final View” button. No exception is thrown.
> If you change the MyFaces bundle to a Mojarra bundle and repeat the same 
> steps, you’ll get the exception I mentioned above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4162:
-

I'm still here. Just don't have enough time to contribute these days.

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4141) JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push functionality

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4141:
-

I ignore if this is implemented in Mojarra. I remember the idea was compare the 
list of resources and the difference add it through an extra  section 
in the ajax request. MyFaces uses something different, because we have an 
alternative solution that detect the change instead rely on a list comparison.

The param that was deprecated is 
org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX.

Since f:websocket rely on "channel" concept, that means the view does not 
change on a websocket push. It was an intentional simplification. 

The important thing here is if you add a component resource like an script or a 
stylesheet in the current view, for example an ajaxified button with an 
ActionListener method that adds the resource, the algorithm should pick up the 
change and load the resource on the client side after parse the  
section. 

> JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push 
> functionality
> ---
>
> Key: MYFACES-4141
> URL: https://issues.apache.org/jira/browse/MYFACES-4141
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
>
> The following spec issue does not look to be implemented in the MyFaces 
> 2.3.0-beta: https://github.com/javaee/javaserverfaces-spec/issues/1436
> The following text was added to the JSF 2.3 specification section 2.2.6 
> "Render Response":
> If running on a container that supports Servlet 4.0 or later, after any 
> dynamic component manipulations have been
> completed, any resources that have been added to the UIViewRoot, such as 
> scripts, images, or stylesheets, and any
> inline images, must be pushed to the client using the Servlet Server Push 
> API. All of the pushes must be started
> before any of the HTML of the response is rendered to the client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4141) JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push functionality

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4141:
-

About update scripts/stylesheet resources, the spec says this in the javascript 
documentation of jsf.ajax.response:

If an update element is found in the response with the identifier 
javax.faces.Resource:
{code:xml}

   

{code}
append any element found in the CDATA contents which is absent in the document 
to the document's head section.

That's it. There is no update of the view using websockets.

The code that trigger the update was done before jsf 2.3 spec, and it aims to 
detect added resources in dynamic sections of a view. That's the reason why 
this doesn't seem to be implemented, but it is there. Try a dynamic ui:include 
src="#{...}" with a page with a resource and it will work.

> JSF 2.3 Spec Issue 1436 - MyFaces Implementation requires Server Push 
> functionality
> ---
>
> Key: MYFACES-4141
> URL: https://issues.apache.org/jira/browse/MYFACES-4141
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Fix For: 2.3.0
>
>
> The following spec issue does not look to be implemented in the MyFaces 
> 2.3.0-beta: https://github.com/javaee/javaserverfaces-spec/issues/1436
> The following text was added to the JSF 2.3 specification section 2.2.6 
> "Render Response":
> If running on a container that supports Servlet 4.0 or later, after any 
> dynamic component manipulations have been
> completed, any resources that have been added to the UIViewRoot, such as 
> scripts, images, or stylesheets, and any
> inline images, must be pushed to the client using the Servlet Server Push 
> API. All of the pushes must be started
> before any of the HTML of the response is rendered to the client.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4127) Unexpected exception thrown when FlowMap is injected on a RequestScoped bean

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4127:
-

It is possible to use a dynamic producer but it requires copy/paste some code 
that is already in MyFaces codebase.

> Unexpected exception thrown when FlowMap is injected on a RequestScoped bean
> 
>
> Key: MYFACES-4127
> URL: https://issues.apache.org/jira/browse/MYFACES-4127
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Eduardo Breijo
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: ConfigItems.java, ELImplicitObjectsViaCDI.war, 
> ELImplicitObjectsViaCDI.war.zip
>
>
> When @FlowMap is injected on a RequestScoped bean, and you try to use that 
> object (which should be null since we are not inside of a flow), an 
> unexpected exception is thrown. This was noted after JIRA issue: 
> https://issues.apache.org/jira/browse/MYFACES-4126
> Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: 
> Cannot return null from a non-dependent producer method: Producer for 
> Producer Method [Map] with qualifiers [@FlowMap @Any] 
> declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped 
> public 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] 
> declared on Managed Bean [class 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers 
> [@Any @Default]
>   at 
> org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73)
>   StackTrace:
>   at 
> org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136)
>   at [internal classes]
>   at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
>   at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
>   at [internal classes]
>   at java.lang.String.valueOf(String.java:2994)
>   at java.lang.StringBuilder.append(StringBuilder.java:131)
>   at 
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)
> On Mojarra 2.3, we get a different exception which looks more appropriate.
> org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active 
> contexts for scope type javax.faces.flow.FlowScoped
>   
> org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623)
>   
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
>   
> org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
>   
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
>   
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
>   
> org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown 
> Source)
>   java.lang.String.valueOf(String.java:2994)
>   java.lang.StringBuilder.append(StringBuilder.java:131)
>   
> com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4082) Composite binding don't works ...

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4082:
-

I think use "binding" to reference composite components has never worked, in 
both myfaces and ri implementations. What people usually do is use the 
"binding" of the surrouding panelGroup, which is a normal component or add the 
composite component dynamically using the known trick found inside myfaces test 
files. The code that does the "binding" magic is in ComponentDelegateHandler 
and the one related to restore view (lifecycle)

> Composite binding don't works ...
> -
>
> Key: MYFACES-4082
> URL: https://issues.apache.org/jira/browse/MYFACES-4082
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.3, 2.2.11
> Environment: Debian 8.2
> JDK 1.8
> Netbeans 8.1
>Reporter: NCister
>
> I've just tried to set binding of a simple composite.
> It don't works :-(
> To manage the componentType methods from user page the only way is to use 
> ViewRoot.findComponent .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4133) Don't deserialize the ViewState-ID if the state saving method is server

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4133:
-

Encryption should NEVER be disabled for view state token, because there is no 
safe way to make it work with this disabled, but beyond that, I agree serialize 
the session id is not necessary on server side state saving. 

Please note encryption also adds a Message Authentication Code (MAC) that 
protects the view state token against tampering and other attacks, but this 
works together with the encryption.

It's more, maybe it is a good idea to change the default encryption algorithm 
to AES or something.

> Don't deserialize the ViewState-ID if the state saving method is server
> ---
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState-ID provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3844) move StartupServletContextListener config to web-fragment.xml

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3844:
-

yes it makes sense jsf 2.3 no longer should works in servlet 2.5 or lower 
versions, so this detail can change. In general myfaces try to be aligned with 
the spec in these config/startup details

> move StartupServletContextListener config to web-fragment.xml
> -
>
> Key: MYFACES-3844
> URL: https://issues.apache.org/jira/browse/MYFACES-3844
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-344
>Affects Versions: 2.2.0
>Reporter: Gerhard Petracek
>Assignee: Thomas Andraschko
> Attachments: MYFACES-3844.patch
>
>
> users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
> listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3435:
-

Please check it

> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3435:
-

I remember it is a trade-off between memory and speed/better code. View Pooling 
adds some extra cases to _DeltaList (reset delta), so it is an open case, 
that's the reason why the issue is still open. I would not apply it in 2.2 or 
lower versions but maybe for 2.3

> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3435:
-

I think the current code is ok. The patch is a good idea, but there are not 
enough compelling reasons to include it, the current code works just fine and 
there is no performance improvement here. Please note a lot of things happened 
over years that has made things change, and since a partial patch was already 
applied we can close this one as fixed.

> [perf] _DeltaList: use ArrayList as parent
> --
>
> Key: MYFACES-3435
> URL: https://issues.apache.org/jira/browse/MYFACES-3435
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: General
>Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
>Reporter: Martin Kočí
>Assignee: Martin Kočí
>Priority: Minor
> Attachments: _ComponentChildrenList2.java, MYFACES-3435-2.patch, 
> MYFACES-3435-7.patch, MYFACES-3435.patch
>
>
> Two internal classes _DeltaList in API:
> 1) now use delegation pattern, but are always initialized with an ArrayList 
> instance -> use inheritance and  ArrayList as parent -> improvement in memory 
> area, reduces number of GCed object in one request/response of (_DeltaList 
> instances/2) 
> 2) initialize expected size of _DeltaList (for example, number of validators 
> per one component is perhaps never 10, use: new _DeltaList(5))
> 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) ->  
> improvement in performance



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4120) ResourceHandler#markResourceRendered() should be retained during ajax rebuild

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4120:
-

I'm thinking on the side effect of not render resources inside  tag 
content. Suppose an stylesheet. If the stylesheed is not inside  tag 
after render all, the view will not be rendered properly. What I mean is 
javascript resources are preserved BUT stylesheet resources aren't if they are 
not bound to the DOM tree. 

> ResourceHandler#markResourceRendered() should be retained during ajax rebuild
> -
>
> Key: MYFACES-4120
> URL: https://issues.apache.org/jira/browse/MYFACES-4120
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0
> Environment: TomEE 7.0.3 with MyFaces 2.3.0-SNAPSHOT
>Reporter: Bauke Scholtz
>Assignee: Leonardo Uribe
>
> While running OmniFaces IT suite on today's MyFaces 2.3.0-SNAPSHOT, I noticed 
> a bug in ResourceHandler#isResourceRendered() during an ajax navigation back 
> to the same view (more specifically, when FacesContext#setViewRoot() is 
> invoked with a new UIViewRoot of same viewId during an ajax postback). 
> During restore view phase, all already-rendered resources are correctly 
> marked via markResourceRendered(). However, this is in turn stored as a 
> transient UIViewRoot attribute. As a consequence, when the UIViewRoot gets 
> changed during the very same ajax request, they are all lost, causing 
> isResourceRendered() to incorrectly return false.
> Basically, the markResourceRendered() of the previous view should be 
> remembered for the next view when PartialViewContext#isAjaxRequest() returns 
> true and isRenderAll() returns false.
> In MyFaces 2.2 (and possibly earlier) the behavior of markResourceRendered() 
> and isResourceRendered() was internally correctly implemented via 
> org.apache.myfaces.RENDERED_SCRIPT_RESOURCES_SET context attribute.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4120) ResourceHandler#markResourceRendered() should be retained during ajax rebuild

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4120:
-

I checked the code and how it is handled this case on the javascript side and 
the whole head tag is replaced, so anyway if we keep track of the resources 
added in a facesContext map, it will be pointless, because the partial response 
from the server will be the same. I'll close this issue as not a problem. 
Please reopen it again if you thing there is something I'm missing in the 
resolution. Thanks Bauke for the report.

> ResourceHandler#markResourceRendered() should be retained during ajax rebuild
> -
>
> Key: MYFACES-4120
> URL: https://issues.apache.org/jira/browse/MYFACES-4120
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0
> Environment: TomEE 7.0.3 with MyFaces 2.3.0-SNAPSHOT
>Reporter: Bauke Scholtz
>
> While running OmniFaces IT suite on today's MyFaces 2.3.0-SNAPSHOT, I noticed 
> a bug in ResourceHandler#isResourceRendered() during an ajax navigation back 
> to the same view (more specifically, when FacesContext#setViewRoot() is 
> invoked with a new UIViewRoot of same viewId during an ajax postback). 
> During restore view phase, all already-rendered resources are correctly 
> marked via markResourceRendered(). However, this is in turn stored as a 
> transient UIViewRoot attribute. As a consequence, when the UIViewRoot gets 
> changed during the very same ajax request, they are all lost, causing 
> isResourceRendered() to incorrectly return false.
> Basically, the markResourceRendered() of the previous view should be 
> remembered for the next view when PartialViewContext#isAjaxRequest() returns 
> true and isRenderAll() returns false.
> In MyFaces 2.2 (and possibly earlier) the behavior of markResourceRendered() 
> and isResourceRendered() was internally correctly implemented via 
> org.apache.myfaces.RENDERED_SCRIPT_RESOURCES_SET context attribute.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4121) Fix javadoc for 2.3 branch and update maven-javadoc-plugin

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4121.
-
Resolution: Fixed

> Fix javadoc for 2.3 branch and update maven-javadoc-plugin 
> ---
>
> Key: MYFACES-4121
> URL: https://issues.apache.org/jira/browse/MYFACES-4121
> Project: MyFaces Core
>  Issue Type: Task
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>Priority: Blocker
> Fix For: 2.3.0
>
>
> MyFaces 2.3 branch requires Java 8 and an updated maven-javadoc-plugin. The 
> problem is the new versions are more strict to generate the javadoc, so we 
> need to check the javadoc and fix its generation.
> This is a blocker issue for beta release, since we cannot generate all 
> artifacts without fix this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4120) ResourceHandler#markResourceRendered() should be retained during ajax rebuild

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4120:
-

But if isRenderAll() renders the whole view including replace all content 
inside  tag, right? Even if isResourceRendered() return true, the whole 
view will be replaced. It doesn't sound like a bug to me, or am I missing 
something?

> ResourceHandler#markResourceRendered() should be retained during ajax rebuild
> -
>
> Key: MYFACES-4120
> URL: https://issues.apache.org/jira/browse/MYFACES-4120
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0
> Environment: TomEE 7.0.3 with MyFaces 2.3.0-SNAPSHOT
>Reporter: Bauke Scholtz
>
> While running OmniFaces IT suite on today's MyFaces 2.3.0-SNAPSHOT, I noticed 
> a bug in ResourceHandler#isResourceRendered() during an ajax navigation back 
> to the same view (more specifically, when FacesContext#setViewRoot() is 
> invoked with a new UIViewRoot of same viewId during an ajax postback). 
> During restore view phase, all already-rendered resources are correctly 
> marked via markResourceRendered(). However, this is in turn stored as a 
> transient UIViewRoot attribute. As a consequence, when the UIViewRoot gets 
> changed during the very same ajax request, they are all lost, causing 
> isResourceRendered() to incorrectly return false.
> Basically, the markResourceRendered() of the previous view should be 
> remembered for the next view when PartialViewContext#isAjaxRequest() returns 
> true and isRenderAll() returns false.
> In MyFaces 2.2 (and possibly earlier) the behavior of markResourceRendered() 
> and isResourceRendered() was internally correctly implemented via 
> org.apache.myfaces.RENDERED_SCRIPT_RESOURCES_SET context attribute.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-3525:
-

No problem from my side, if a custom parameter help, please add it. Just let 
the default behavior intact.

> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects 
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>
> Inconsistent behavior for required field validation when 
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true 
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in 
> web.xml
> 2. Create JSF Page:
> 
> 
>  required="true"
> requiredMessage="You must enter a first name"/>
> 
> 
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which 
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL 
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed 
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true 
> or false should not result in inconsistent behavior with required fields)
> 
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank 
> out a value for a required field that had previously been populated by the 
> model, submit the form, you will see the OLD data from the model in the 
> field. However, if that field had had a format validation applied to it and 
> the user submits the form with a format validation error, the OLD data is NOT 
> shown in the field (instead, the submitted/invalid data is shown). The same 
> should happen for required field validation errors. The field should show the 
> "blank" data and not the original model data. In order to get the correct 
> behavior, the developer has to currently set 
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not 
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is 
> true or false, the behavior of showing the blank field that the user 
> submitted should be the same.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4121) Fix javadoc for 2.3 branch and update maven-javadoc-plugin

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4121:
---

 Summary: Fix javadoc for 2.3 branch and update 
maven-javadoc-plugin 
 Key: MYFACES-4121
 URL: https://issues.apache.org/jira/browse/MYFACES-4121
 Project: MyFaces Core
  Issue Type: Task
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Priority: Blocker


MyFaces 2.3 branch requires Java 8 and an updated maven-javadoc-plugin. The 
problem is the new versions are more strict to generate the javadoc, so we need 
to check the javadoc and fix its generation.

This is a blocker issue for beta release, since we cannot generate all 
artifacts without fix this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MYFACES-4119) Disposal method from PushContextFactoryBean is missing @Push annotation

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe updated MYFACES-4119:

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

Thanks to Eduardo Breijo for provide this patch

> Disposal method from PushContextFactoryBean is missing @Push annotation
> ---
>
> Key: MYFACES-4119
> URL: https://issues.apache.org/jira/browse/MYFACES-4119
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0
> Environment: myfaces-2.3.x, WebSphere Liberty
>Reporter: Eduardo Breijo
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.3.0
>
> Attachments: MYFACES-4119.patch
>
>
> Performing integration between JSF MyFaces 2.3 and CDI, I found that the 
> PushContextFactoryBean class is missing the @Push annotation in the disposal 
> method, that is, in the close() method. This results in the following 
> exception:
> The exception message was: 
> com.ibm.ws.container.service.state.StateChangeException: 
> org.jboss.weld.exceptions.DefinitionException: WELD-001424: The following 
> disposal methods were declared but did not resolve to a producer method: 
>   - Disposer method [[UnbackedAnnotatedMethod] public 
> org.apache.myfaces.push.cdi.PushContextFactoryBean.close(@Disposes 
> PushContext)]
> Adding the @Push annotation to the close method should solve this issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACESTEST-69) Add methods in mock objects from servlet 3.0 spec

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACESTEST-69.
---
   Resolution: Fixed
 Assignee: Leonardo Uribe
Fix Version/s: 1.0.8-SNAPSHOT

> Add methods in mock objects from servlet 3.0 spec
> -
>
> Key: MYFACESTEST-69
> URL: https://issues.apache.org/jira/browse/MYFACESTEST-69
> Project: MyFaces Test
>  Issue Type: Bug
>  Components: Mock Objects
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 1.0.8-SNAPSHOT
>
>
> We need to add mock implementations for methods added in servlet 3.0 spec, to 
> avoid problems with libraries that relies on them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACESTEST-71) Create test23 module with servlet 3.0 mocks

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACESTEST-71.
---
   Resolution: Fixed
Fix Version/s: 1.0.8-SNAPSHOT

> Create test23 module with servlet 3.0 mocks
> ---
>
> Key: MYFACESTEST-71
> URL: https://issues.apache.org/jira/browse/MYFACESTEST-71
> Project: MyFaces Test
>  Issue Type: Improvement
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 1.0.8-SNAPSHOT
>
>
> Create test23 module with servlet 3.0 mocks. It appeared because the new 
> mapping in MYFACES-4105 requires some specific servlet 3.0 API (note JSF 2.3 
> is compatible with servlet 4.0, but that hasn't gone out yet).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4097) Implement CDI changes for @FacesConfig

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4097.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement CDI changes for @FacesConfig
> --
>
> Key: MYFACES-4097
> URL: https://issues.apache.org/jira/browse/MYFACES-4097
> Project: MyFaces Core
>  Issue Type: Sub-task
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>Priority: Minor
> Fix For: 2.3.0
>
>
> This is the one that when the annotation is present, just remove implicit 
> object Resolver from EL chain



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4102) Check improvements in FlowHandler for JSF 2.3

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4102.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

It was checked enter to a flow from f:viewAction, FlowScoped requires 
NormalScope(passivating=true). The remaining issues were done in 2.2 branch, so 
everything looks just fine.

> Check improvements in FlowHandler for JSF 2.3
> -
>
> Key: MYFACES-4102
> URL: https://issues.apache.org/jira/browse/MYFACES-4102
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> There are some small changes in FlowHandler we need to check. I guess this 
> was done some time ago, but this requires at least one junit test case.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4078) Expose StateCacheFactory/StateCache as a SPI service

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4078.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

StateCacheFactory was deprecated and replaced as 
org.apache.myfaces.spi.StateCacheProvider

> Expose StateCacheFactory/StateCache as a SPI service
> 
>
> Key: MYFACES-4078
> URL: https://issues.apache.org/jira/browse/MYFACES-4078
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Discussing some stuff in the EG, I have notice that the view state algorithm 
> now is well understood, and it could be useful to expose 
> StateCache/StateCacheFactory as an SPI interface.
> In that way, developers could override the default StateCacheFactory and 
> provide its own view state saving solution.
> No changes in code are required besides expose StateCacheFactory as an SPI 
> service



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4071) Implement dynamic resource loading in ajax requests

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4071.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

Added update javax.faces.Resource and integrated with existing logic 
("org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX" was deprecated).

> Implement dynamic resource loading in ajax requests
> ---
>
> Key: MYFACES-4071
> URL: https://issues.apache.org/jira/browse/MYFACES-4071
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement as described on:
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1423



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4118) Implement new changes of javax.faces.ViewState update on ajax for multiple forms

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4118.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement new changes of javax.faces.ViewState update on ajax for multiple 
> forms
> 
>
> Key: MYFACES-4118
> URL: https://issues.apache.org/jira/browse/MYFACES-4118
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement new changes of javax.faces.ViewState update on ajax for multiple 
> forms.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4118) Implement new changes of javax.faces.ViewState update on ajax for multiple forms

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4118:
---

 Summary: Implement new changes of javax.faces.ViewState update on 
ajax for multiple forms
 Key: MYFACES-4118
 URL: https://issues.apache.org/jira/browse/MYFACES-4118
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Leonardo Uribe


Implement new changes of javax.faces.ViewState update on ajax for multiple 
forms.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4079) Implement CDI changes for JSF 2.3

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4079.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement CDI changes for JSF 2.3
> -
>
> Key: MYFACES-4079
> URL: https://issues.apache.org/jira/browse/MYFACES-4079
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> The idea is implement the following annotations:
> ApplicationMap
> FlowMap
> HeaderMap
> HeaderValuesMap
> InitParameterMap
> RequestCookieMap
> RequestMap
> RequestParameterMap
> RequestParameterValuesMap
> SessionMap
> ViewMap
> The tricky part here is some objects are managed by JSF and others by CDI.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4084) Implement f:importConstants

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4084.
-
   Resolution: Fixed
 Assignee: Leonardo Uribe
Fix Version/s: 2.3.0

> Implement f:importConstants
> ---
>
> Key: MYFACES-4084
> URL: https://issues.apache.org/jira/browse/MYFACES-4084
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1424



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4091) Add custom type support in UIData and UIRepeat

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4091.
-
   Resolution: Fixed
 Assignee: Leonardo Uribe
Fix Version/s: 2.3.0

> Add custom type support in UIData and UIRepeat
> --
>
> Key: MYFACES-4091
> URL: https://issues.apache.org/jira/browse/MYFACES-4091
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4089) Add Iterable support in UIData and UIRepeat

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4089.
-
   Resolution: Fixed
 Assignee: Leonardo Uribe
Fix Version/s: 2.3.0

> Add Iterable support in UIData and UIRepeat
> ---
>
> Key: MYFACES-4089
> URL: https://issues.apache.org/jira/browse/MYFACES-4089
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4090) Add Map support in UIData and UIRepeat

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4090.
-
   Resolution: Fixed
 Assignee: Leonardo Uribe
Fix Version/s: 2.3.0

> Add Map support in UIData and UIRepeat
> --
>
> Key: MYFACES-4090
> URL: https://issues.apache.org/jira/browse/MYFACES-4090
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4117) No default name for @FacesComponent with createTag=true and no tagName

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4117.
-
   Resolution: Fixed
Fix Version/s: 2.3.0
   2.2.13

> No default name for @FacesComponent with createTag=true and no tagName
> --
>
> Key: MYFACES-4117
> URL: https://issues.apache.org/jira/browse/MYFACES-4117
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-344, JSR-372
>Affects Versions: 2.2.12
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.2.13, 2.3.0
>
>
> No default name for @FacesComponent with createTag=true and no tagName



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4117) No default name for @FacesComponent with createTag=true and no tagName

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4117:
---

 Summary: No default name for @FacesComponent with createTag=true 
and no tagName
 Key: MYFACES-4117
 URL: https://issues.apache.org/jira/browse/MYFACES-4117
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344, JSR-372
Affects Versions: 2.2.12
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


No default name for @FacesComponent with createTag=true and no tagName



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4116) Implement JDK 8 time support in f:convertDateTime

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4116.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement JDK 8 time support in f:convertDateTime
> -
>
> Key: MYFACES-4116
> URL: https://issues.apache.org/jira/browse/MYFACES-4116
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement JDK 8 time support in f:convertDateTime.
> See http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1370



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4113) Implement h:panelGrid rowClass

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4113.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement h:panelGrid rowClass
> --
>
> Key: MYFACES-4113
> URL: https://issues.apache.org/jira/browse/MYFACES-4113
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement h:panelGrid rowClass



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4070) Implement h:commandScript and related api

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4070.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement h:commandScript and related api
> -
>
> Key: MYFACES-4070
> URL: https://issues.apache.org/jira/browse/MYFACES-4070
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4116) Implement JDK 8 time support in f:convertDateTime

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4116:
---

 Summary: Implement JDK 8 time support in f:convertDateTime
 Key: MYFACES-4116
 URL: https://issues.apache.org/jira/browse/MYFACES-4116
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement JDK 8 time support in f:convertDateTime.

See http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1370




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4115:
-

In the component there are two use cases:

1. h:selectOneRadio is inside a dataTable or repeat component like this:

{code:xml}









{code}

2. There are more than one h:selectOneRadio, but there is one that holds
the select list. Each one has an id ending with an index that indicates
the value that will be rendered in the current component. For example:

{code:xml}







{code}
I think the best trick to make it work is take a look at "value" 
ValueExpression. When this VE is not present, the component is a placeholder,
when it is present, the component can hold a submitted value.

On h:selectOneRadio renderer decode() if the component has "group" property
set, retrieve the value and if the value starts with the component clientId,
the current component will be the "source component". Now, the algorithm 
should apply a visit tree call starting from the closest UIForm. When it
founds a component than belongs to the group there are two cases:

- If the source component has a "value" ValueExpression, call 
setSubmittedValue(...) and if the target component is the source component
pass the submitted value, otherwise call resetValue().
- If the source component does not have a "value" ValueExpression, find
the first component that belongs to the groupd and with a "value" 
ValueExpression and set the value there, otherwise call resetValue().

This algorithm looks more consistent because:

- It ensures only one visit tree call per group.
- It ensures values from previous requests will be cleared.

Then on render phase, the Renderer will detect the group attribute and if
the attribute is set, it will get the value to use using the same rules
used in decode() phase. This means only a visit tree call is necessary when
option 2 is used. 

I think the algorithm proposed respect the spirit of the spec, and I have
already tested it, so I think it should be the way at least for MyFaces.

> Implement h:selectOneRadio "group" (distributed radio button)
> -
>
> Key: MYFACES-4115
> URL: https://issues.apache.org/jira/browse/MYFACES-4115
> Project: MyFaces Core
>  Issue Type: New Feature
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement h:selectOneRadio "group" (distributed radio button)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4115.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement h:selectOneRadio "group" (distributed radio button)
> -
>
> Key: MYFACES-4115
> URL: https://issues.apache.org/jira/browse/MYFACES-4115
> Project: MyFaces Core
>  Issue Type: New Feature
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement h:selectOneRadio "group" (distributed radio button)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe edited comment on MYFACES-4115 at 5/3/17 6:07 AM:
-

I started this one some days ago, with the expectation that this one could be 
easily solved, but later I found that implement the spec javadoc "as is" does 
not work.

The problem starts in this example:

{code:xml}













{code}

The rendered markup by Mojarra (RI) is this:

{code:xml}


 A A

 B-B

 C_C

{code}

Take a look at the "value" attribute. It appends the clientId and the value. 
This means when decode() happens, only the component with the right clientId 
takes the value. But please note only radio0 has the EL expression pointing to 
the model. Which means at some point setSubmittedValue(...) is called, but if 
is not in decode(), when? 

There is also another problem caused by submitted values not processed by the 
validation step. The spec talks about skip processValidation(...) with some 
conditions, to avoid validation step over components that does not have the 
validators and the EL "value" expression. 

In my opinion this part is unstable. I guess I could find more holes in it, but 
by some reason the implementation in Mojarra works, at least for the basic 
example.




was (Author: lu4242):
I started this one some days ago, with the expectation that this one could be 
easily solved, but later I found that implement the spec javadoc "as is" does 
not work.

The problem starts in this example:

{code:xml}













{code}

The rendered markup by Mojarra (RI) is this:

{code:xml}


 A A

 B-B

 C_C

{code:xml}

Take a look at the "value" attribute. It appends the clientId and the value. 
This means when decode() happens, only the component with the right clientId 
takes the value. But please note only radio0 has the EL expression pointing to 
the model. Which means at some point setSubmittedValue(...) is called, but if 
is not in decode(), when? 

There is also another problem caused by submitted values not processed by the 
validation step. The spec talks about skip processValidation(...) with some 
conditions, to avoid validation step over components that does not have the 
validators and the EL "value" expression. 

In my opinion this part is unstable. I guess I could find more holes in it, but 
by some reason the implementation in Mojarra works, at least for the basic 
example.



> Implement h:selectOneRadio "group" (distributed radio button)
> -
>
> Key: MYFACES-4115
> URL: https://issues.apache.org/jira/browse/MYFACES-4115
> Project: MyFaces Core
>  Issue Type: New Feature
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> Implement h:selectOneRadio "group" (distributed radio button)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4115:
-

I started this one some days ago, with the expectation that this one could be 
easily solved, but later I found that implement the spec javadoc "as is" does 
not work.

The problem starts in this example:

{code:xml}













{code}

The rendered markup by Mojarra (RI) is this:

{code:xml}


 A A

 B-B

 C_C

{code:xml}

Take a look at the "value" attribute. It appends the clientId and the value. 
This means when decode() happens, only the component with the right clientId 
takes the value. But please note only radio0 has the EL expression pointing to 
the model. Which means at some point setSubmittedValue(...) is called, but if 
is not in decode(), when? 

There is also another problem caused by submitted values not processed by the 
validation step. The spec talks about skip processValidation(...) with some 
conditions, to avoid validation step over components that does not have the 
validators and the EL "value" expression. 

In my opinion this part is unstable. I guess I could find more holes in it, but 
by some reason the implementation in Mojarra works, at least for the basic 
example.



> Implement h:selectOneRadio "group" (distributed radio button)
> -
>
> Key: MYFACES-4115
> URL: https://issues.apache.org/jira/browse/MYFACES-4115
> Project: MyFaces Core
>  Issue Type: New Feature
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> Implement h:selectOneRadio "group" (distributed radio button)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4115:
---

 Summary: Implement h:selectOneRadio "group" (distributed radio 
button)
 Key: MYFACES-4115
 URL: https://issues.apache.org/jira/browse/MYFACES-4115
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement h:selectOneRadio "group" (distributed radio button)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TOBAGO-1736) Incorrectly rendered component ID

[Leonardo Uribe (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15992005#comment-15992005
 ] 

Leonardo Uribe commented on TOBAGO-1736:


c:forEach has been a pain for a long time, and the changes involved to fix this 
has been included slowly in MyFaces Core 2.1/2.2 versions. 

The fundamental problem is c:forEach is a build view time tag, that alters the 
component tree structure, but the old algorithm from facelets lacks of the 
necessary logic to do it properly. It is a long story, see MYFACES-3811 for 
details.

I agree with Volker, it is not a Tobago issue.

> Incorrectly rendered component ID
> -
>
> Key: TOBAGO-1736
> URL: https://issues.apache.org/jira/browse/TOBAGO-1736
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Facelets
>Affects Versions: 2.0.10
> Environment: Unix
>Reporter: David Crhonek
> Attachments: uploadBox.xhtml
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> When dynamically creating UI component ID, the rendered ID is often 
> incorrect. This appears to be random, but happens very often, multiple times 
> on a page. When the same value is put in ID and in tip (title), the rendered 
> title is ALWAYS correct, however the rendered ID value is often INCORRECT.
> In the attached example, #{titleVar} is put to ID as well as to tip. This is 
> an example of an incorrect output:
>  id="page:details_upload:CASV3_C_B_TODAY" title="NTC_A_B_TODAY" 
> data-tobago-commands="{click:{partially:page:details_upload:popup-Upload-TODAY-1,popup:{command:open}}}"
>  href="#" 
> data-tobago-style="{width:59px,height:14px,top:52px,left:677px,position:absolute}"
>  class="tobago-button" style="width: 59px; height: 14px; top: 52px; left: 
> 677px; position: absolute;">Upload
> ID and Title should be the same, but they are not. The expected value is 
> NTC_A_B_TODAY



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4114) Add disabled attribute to h:button

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4114:
---

 Summary: Add disabled attribute to h:button
 Key: MYFACES-4114
 URL: https://issues.apache.org/jira/browse/MYFACES-4114
 Project: MyFaces Core
  Issue Type: New Feature
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implemented, but not in HtmlOutcomeTargetButton



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4113) Implement h:panelGrid rowClass

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4113:
---

 Summary: Implement h:panelGrid rowClass
 Key: MYFACES-4113
 URL: https://issues.apache.org/jira/browse/MYFACES-4113
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement h:panelGrid rowClass



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4112) Implement h:dataTable rowClass

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4112.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement h:dataTable rowClass
> --
>
> Key: MYFACES-4112
> URL: https://issues.apache.org/jira/browse/MYFACES-4112
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement h:dataTable rowClass



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4112) Implement h:dataTable rowClass

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4112:
---

 Summary: Implement h:dataTable rowClass
 Key: MYFACES-4112
 URL: https://issues.apache.org/jira/browse/MYFACES-4112
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement h:dataTable rowClass



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4111) Implement h:column styleClass property

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4111.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement h:column styleClass property
> --
>
> Key: MYFACES-4111
> URL: https://issues.apache.org/jira/browse/MYFACES-4111
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement h:column styleClass property. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4111) Implement h:column styleClass property

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4111:
---

 Summary: Implement h:column styleClass property
 Key: MYFACES-4111
 URL: https://issues.apache.org/jira/browse/MYFACES-4111
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement h:column styleClass property. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4109) Implement f:validateWholeBean

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4109:
-

After study how f:validateBean works, it looks like the best solution is use 
the same strategy to get the value reference in each component and then only 
call setValue(...) on the component which has the base specified by 
f:validateWholeBean. The custom ELResolver just detect when the base is 
returned and replace it with the copy. I tested it and it works well, so I have 
finally commited the solution. It should work because the solution reuses the 
logic inside f:validateBean, and that logic has been already tested.

> Implement f:validateWholeBean
> -
>
> Key: MYFACES-4109
> URL: https://issues.apache.org/jira/browse/MYFACES-4109
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement f:validateWholeBean as described in the spec javadoc. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4109) Implement f:validateWholeBean

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4109.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement f:validateWholeBean
> -
>
> Key: MYFACES-4109
> URL: https://issues.apache.org/jira/browse/MYFACES-4109
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement f:validateWholeBean as described in the spec javadoc. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4109) Implement f:validateWholeBean

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4109:
-

I have been trying to fix this one, but it has been proved challenging.

The big problem is there is a part that says this:

"... Class-level bean validation must operate on a sufficiently populated bean 
instance. This differs from JSF field-level validation, which prevents beans 
from being populated with invalid values. To accomodate this difference, the 
candidate bean must be copied, populated with the already-validated candidate 
values, and then subjected to class-level validation ..."

The copy is not a problem. The problem is how to populate the candidate values. 
After reading the spec it was mentioned that f:validateBean should keep track 
of the "candidate values", which I guess it is better to store them in the view 
transient map. But the "bean population" or "update model" step is done in 
update model phase, usually through ValueExpression.setValue(...). The problem 
resides in we need to update only the relevant bean involved in 
f:validateWholeBean and keep all other objects intact, so there is a visitTree 
invocations to apply it in the proper context (remember datatable rows can be 
problematic). So I guess there is some manipulation in the ELResolver chain to 
do this. f:validateBean has some code that helps a bit (get ValueReference), 
but I still don't get the right combination. The documentation in the spec is 
clear, it is just I don't get how make this detail work in a consistent way. 
The rule is how to be sure only the content of the cloned object is updated 
without affect anything from the model (which should be updated in update model 
phase). Of course it could be done parsing each EL expression and applying only 
those with the same "reference", but that is seen as a "last resource" scenario.

> Implement f:validateWholeBean
> -
>
> Key: MYFACES-4109
> URL: https://issues.apache.org/jira/browse/MYFACES-4109
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> Implement f:validateWholeBean as described in the spec javadoc. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4110) Implement javax.faces.model.IterableDataModel

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4110.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement javax.faces.model.IterableDataModel
> -
>
> Key: MYFACES-4110
> URL: https://issues.apache.org/jira/browse/MYFACES-4110
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement javax.faces.model.IterableDataModel as described in the spec



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4110) Implement javax.faces.model.IterableDataModel

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4110:
---

 Summary: Implement javax.faces.model.IterableDataModel
 Key: MYFACES-4110
 URL: https://issues.apache.org/jira/browse/MYFACES-4110
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement javax.faces.model.IterableDataModel as described in the spec



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4109) Implement f:validateWholeBean

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4109:
---

 Summary: Implement f:validateWholeBean
 Key: MYFACES-4109
 URL: https://issues.apache.org/jira/browse/MYFACES-4109
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement f:validateWholeBean as described in the spec javadoc. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4105) Implement extensionless mapping of views

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4105.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement extensionless mapping of views
> 
>
> Key: MYFACES-4105
> URL: https://issues.apache.org/jira/browse/MYFACES-4105
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> See:
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1260
> Now we have already implemented getViews(...),  it is a good time to check 
> how this one works.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4108) Implement FaceletCache.setCacheFactories(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4108.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement FaceletCache.setCacheFactories(...)
> -
>
> Key: MYFACES-4108
> URL: https://issues.apache.org/jira/browse/MYFACES-4108
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement FaceletCache.setCacheFactories(...) and do the necessary changes to 
> ensure it is called.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4108) Implement FaceletCache.setCacheFactories(...)

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4108:
---

 Summary: Implement FaceletCache.setCacheFactories(...)
 Key: MYFACES-4108
 URL: https://issues.apache.org/jira/browse/MYFACES-4108
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement FaceletCache.setCacheFactories(...) and do the necessary changes to 
ensure it is called.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4106) Implement ResourceHandler.markResourceRendered(...) and ResourceHandler.isResourceRendered(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4106.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

After the review, org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX was 
deprecated and refactored include the code and take advange of the new update 
for ajax request "javax.faces.Resource". For example:

{code:xml}

{code}

The previous code update the whole  or  section. Now the component 
resource is added as a element of .

> Implement ResourceHandler.markResourceRendered(...) and 
> ResourceHandler.isResourceRendered(...)
> ---
>
> Key: MYFACES-4106
> URL: https://issues.apache.org/jira/browse/MYFACES-4106
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement ResourceHandler.markResourceRendered(...) and 
> ResourceHandler.isResourceRendered(...) as described in the spec.
> The current implementation is just move the code from ResourceUtils that uses 
> a simple map, but it is relevant to see how this feature works with dynamic 
> resources loaded from ajax requests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4105) Implement extensionless mapping of views

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4105:
-

Added web config parameter org.apache.myfaces.AUTOMATIC_EXTENSIONLESS_MAPPING 
by default false. Some small changes for startup externalcontext were done, to 
avoid UnsuportedOperationException.

One last review is required to check if xhtml files under forbidden extensions 
are being loaded (/resources, /contracts and so on).

> Implement extensionless mapping of views
> 
>
> Key: MYFACES-4105
> URL: https://issues.apache.org/jira/browse/MYFACES-4105
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> See:
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1260
> Now we have already implemented getViews(...),  it is a good time to check 
> how this one works.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4107) StringIndexOutOfBoundsException in getResourceVersion

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4107:
-

+1 the patch looks good

> StringIndexOutOfBoundsException in getResourceVersion
> -
>
> Key: MYFACES-4107
> URL: https://issues.apache.org/jira/browse/MYFACES-4107
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.0.24, 2.1.18, 2.2.12
> Environment: WebSphere Liberty
>Reporter: Bill Lucy
>Assignee: Bill Lucy
>Priority: Minor
> Attachments: MYFACES-4107.patch
>
>
> I've run into a case where, given an incorrect context parameter, a 
> StringIndexOutOfBoundsException is thrown.  This occurs in WebSphere Liberty 
> because the server normalizes the external context resource paths during app 
> initialization.
> For example, this parameter:
> 
>javax.faces.WEBAPP_RESOURCES_DIRECTORY
>/META-INF/resources
> 
> throws:
> java.lang.StringIndexOutOfBoundsException: String index out of  range: 35
> at java.lang.String.substring(String.java:1377)
> at 
> org.apache.myfaces.shared.resource.ExternalContextResourceLoader.getResourceVersion(ExternalContextResourceLoader.java:81)
> That parameter value is not allowed to have a leading slash.  However, the 
> current exception is not very helpful, and can be easily avoided.  
> I'll attach a patch which avoids the StringIndexOutOfBoundsException in 
> getResourceVersion(); we already have this logic in getLibraryVersion().



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4106) Implement ResourceHandler.markResourceRendered(...) and ResourceHandler.isResourceRendered(...)

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4106:
---

 Summary: Implement ResourceHandler.markResourceRendered(...) and 
ResourceHandler.isResourceRendered(...)
 Key: MYFACES-4106
 URL: https://issues.apache.org/jira/browse/MYFACES-4106
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement ResourceHandler.markResourceRendered(...) and 
ResourceHandler.isResourceRendered(...) as described in the spec.

The current implementation is just move the code from ResourceUtils that uses a 
simple map, but it is relevant to see how this feature works with dynamic 
resources loaded from ajax requests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4105) Implement extensionless mapping of views

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4105:
-

Committed a solution for this issue. It is still pending try if we can makes 
all views extensionless automatically using a config parameter.

> Implement extensionless mapping of views
> 
>
> Key: MYFACES-4105
> URL: https://issues.apache.org/jira/browse/MYFACES-4105
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> See:
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1260
> Now we have already implemented getViews(...),  it is a good time to check 
> how this one works.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACESTEST-71) Create test23 module with servlet 3.0 mocks

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACESTEST-71:
-

 Summary: Create test23 module with servlet 3.0 mocks
 Key: MYFACESTEST-71
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-71
 Project: MyFaces Test
  Issue Type: Improvement
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Create test23 module with servlet 3.0 mocks. It appeared because the new 
mapping in MYFACES-4105 requires some specific servlet 3.0 API (note JSF 2.3 is 
compatible with servlet 4.0, but that hasn't gone out yet).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4105) Implement extensionless mapping of views

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4105:
-

There are two parts in this issue:

1. Add .xhtml as a suffix mapping.
2. Allow non wildcard prefix that points to views with default suffix mapping.

After digging about this issue, I found the relevant points in JSF 2.3 pdf 
section 7.6.2.1 and 7.6.2.3

The problem I found is there is an old code that prevents /faces as a mapping 
for example because JSP VDL in this case enters in a redirection loop. The 
reason is JSP VDL in JSF 2.2 and earlier versions does not have a check for 
.jsp views, so the mapping will be recognized as something handled by JSP VDL 
by default. This was changed in JSF 2.3 (see MYFACES-4103), but this is not 
implicit in the spec, and instead this is a deduction done after trying to 
understand getViews(...) logic. Anyway, I'm sure we can change these lines. 

Now, what's left is update calculateActionURL(...) so the outcome or url can be 
properly mapped as a extensionless mapping. The spec does not cover add dynamic 
mappings but with getViews(...) and these changes we have everything we need to 
add automatic extensionless mapping as a implementation specific feature, but 
still the code that calculate prefix/suffix mapping for ResourceHandler could 
be still broken in that case. The old code does not take into account 
ServletContext.getServletRegistration(...) exists (was compatible with Servlet 
2.3-2.5), so we still need to cover those holes and possibly check how 
navigation algorithm is affected. 

> Implement extensionless mapping of views
> 
>
> Key: MYFACES-4105
> URL: https://issues.apache.org/jira/browse/MYFACES-4105
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> See:
> http://arjan-tijms.omnifaces.org/p/jsf-23.html#1260
> Now we have already implemented getViews(...),  it is a good time to check 
> how this one works.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4105) Implement extensionless mapping of views

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4105:
---

 Summary: Implement extensionless mapping of views
 Key: MYFACES-4105
 URL: https://issues.apache.org/jira/browse/MYFACES-4105
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


See:

http://arjan-tijms.omnifaces.org/p/jsf-23.html#1260

Now we have already implemented getViews(...),  it is a good time to check how 
this one works.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4103) Implement ViewHandler.getViews(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4103.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement ViewHandler.getViews(...)
> ---
>
> Key: MYFACES-4103
> URL: https://issues.apache.org/jira/browse/MYFACES-4103
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4103) Implement ViewHandler.getViews(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4103:
-

Finally I enabled this configuration in faces-config.xml as a 
faces-config-extension:

{code:xml}


/site_layout.xhtml


{code}

In this way, it is possible to identify the files that are templates and should 
be excluded from getViews(...) calculation if required. This is useful when 
there is a template inside a resource library contract and you don't want the 
template or composite component file to be included in the calculation.

With these changes, this issue can be closed as fixed. I tried to see if we 
needed the compiler to detect composite components automatically or templates, 
but this requires parse every file. This is time consuming and not very 
precise. The exclusion option defining which files are templates looks better.

> Implement ViewHandler.getViews(...)
> ---
>
> Key: MYFACES-4103
> URL: https://issues.apache.org/jira/browse/MYFACES-4103
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4103) Implement ViewHandler.getViews(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4103:
-

I have committed a solution for this one, it was a long patch, but there are 
still some things to be solved. 

Specifically there is a mention in the javadoc of getViews(...) that says "... 
The elements in the stream are logical view ids. ..." . But right now in 
facelets there is no way to identify "template" files from "view" files. The 
case is problematic with resource library contracts, where composite 
components, views and template live together in the same path.

There is no mechanism defined in the spec for that, so we need something 
custom, problably as a faces-config-extension, and a way to detect composite 
components. 

This is important because if you want to use getViews(...) to create an 
automatically filled menu and a more modular JSF application, we need this 
feature to allow exclusions using patterns.

> Implement ViewHandler.getViews(...)
> ---
>
> Key: MYFACES-4103
> URL: https://issues.apache.org/jira/browse/MYFACES-4103
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4104) Update plugins to compile java 8 code in JSF 2.3 branch

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4104.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Update plugins to compile java 8 code in JSF 2.3 branch
> ---
>
> Key: MYFACES-4104
> URL: https://issues.apache.org/jira/browse/MYFACES-4104
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> It has been detected that the current versions checkstyle, shade and felix 
> plugins does not support java 8 code style. The use of Stream class in JSF 
> 2.3 requires to write some specific code, so an update of these plugins 
> should be done.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4104) Update plugins to compile java 8 code in JSF 2.3 branch

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4104:
---

 Summary: Update plugins to compile java 8 code in JSF 2.3 branch
 Key: MYFACES-4104
 URL: https://issues.apache.org/jira/browse/MYFACES-4104
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


It has been detected that the current versions checkstyle, shade and felix 
plugins does not support java 8 code style. The use of Stream class in JSF 2.3 
requires to write some specific code, so an update of these plugins should be 
done.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4101) Implement f:importConstants

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4101:
-

I forgot to say that use a custom VariableMapper does not work well for EL 
caching, because one template can be used by many views, and the variables in 
VariableMapper are stored inside the EL expression, and since this is a view 
concept it should be handled at view level.

> Implement f:importConstants
> ---
>
> Key: MYFACES-4101
> URL: https://issues.apache.org/jira/browse/MYFACES-4101
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement f:importConstants (See UIImportConstants for details)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4101) Implement f:importConstants

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4101:
-

After thinking about this problem and tried some possible solutions, including 
the one found in Omnifaces (code is ASL 2.0 licensed, so it is compatible with 
our codebase), I found the solution using a custom ELResolver and a transient 
map to view scope is the best one.

There was a possible alternative using a custom VariableMapper, but that 
solution does not work well when EL expressions are created from beans, so it 
will not work well with the new @ManagedProperty for example. The idea is 
constants imported with f:importConstants has view scope, so UIImportConstants 
should be added inside f:metadata, so in that sense it should work as view 
scope. Please note there is no alternative way to add constants in 
faces-config.xml or through annotations.

> Implement f:importConstants
> ---
>
> Key: MYFACES-4101
> URL: https://issues.apache.org/jira/browse/MYFACES-4101
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement f:importConstants (See UIImportConstants for details)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4101) Implement f:importConstants

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4101.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement f:importConstants
> ---
>
> Key: MYFACES-4101
> URL: https://issues.apache.org/jira/browse/MYFACES-4101
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>
> Implement f:importConstants (See UIImportConstants for details)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4103) Implement ViewHandler.getViews(...)

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4103:
---

 Summary: Implement ViewHandler.getViews(...)
 Key: MYFACES-4103
 URL: https://issues.apache.org/jira/browse/MYFACES-4103
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4098) Implement ResourceHandler.getViewResources(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4098.
-
   Resolution: Fixed
Fix Version/s: 2.3.0

> Implement ResourceHandler.getViewResources(...)
> ---
>
> Key: MYFACES-4098
> URL: https://issues.apache.org/jira/browse/MYFACES-4098
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4098) Implement ResourceHandler.getViewResources(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4098:
-

After thinking about it, the SPI can be too much, because the code behind this 
has been already tested before (in libraryVersion / resourceVersion). Better to 
close this issue for now.

> Implement ResourceHandler.getViewResources(...)
> ---
>
> Key: MYFACES-4098
> URL: https://issues.apache.org/jira/browse/MYFACES-4098
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4102) Check improvements in FlowHandler for JSF 2.3

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4102:
---

 Summary: Check improvements in FlowHandler for JSF 2.3
 Key: MYFACES-4102
 URL: https://issues.apache.org/jira/browse/MYFACES-4102
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


There are some small changes in FlowHandler we need to check. I guess this was 
done some time ago, but this requires at least one junit test case.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4101) Implement f:importConstants

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4101:
---

 Summary: Implement f:importConstants
 Key: MYFACES-4101
 URL: https://issues.apache.org/jira/browse/MYFACES-4101
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


Implement f:importConstants (See UIImportConstants for details)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4098) Implement ResourceHandler.getViewResources(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4098:
-

Committed part 2, which is the algorithm body and some tests. There are still 
some things to do, for example review each loader has the proper filters to 
avoid unauthorized access to resources and so on, but the solution proposed is 
good.

There are some methods to implement in ViewHandler ( getViews(...) ). It is 
getting long to solve this point, but there are some considerations with the 
solution. In the past we have had problems with scanning jar files, because 
server applications could do some tricks there. So, we need to study here if it 
is necessary an SPI interface for this kind of tree traversing. The solution 
committed works but solve this point is far from over.

> Implement ResourceHandler.getViewResources(...)
> ---
>
> Key: MYFACES-4098
> URL: https://issues.apache.org/jira/browse/MYFACES-4098
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4098) Implement ResourceHandler.getViewResources(...)

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4098:
-

Committed part 1 iterators for each ResourceLoader instance. Implementing part 
2 which is the Iterator that group all of them together, with the same rules 
createViewResource(...) works. This is the black box test done to check how 
this feature works:

Stream stream = facesContext.getApplication()
.getResourceHandler().getViewResources(facesContext, "/", 2);
stream.forEach(s -> {
System.out.println(s);
});

/helloWorld.xhtml
/home.xhtml
/page2.xhtml
/converter/index.xhtml
/managedproperty/managedproperty1.xhtml
/managedproperty/managedproperty1_1.xhtml
/model/facesdatamodel1.xhtml
/websocket/clockAjax.xhtml
/websocket/testws.xhtml
/websocket/websocket.xhtml



Stream stream = facesContext.getApplication()
.getResourceHandler().getViewResources(facesContext, "/", 1);
stream.forEach(s -> {
System.out.println(s);
});


/helloWorld.xhtml
/home.xhtml
/page2.xhtml


Stream stream = 
facesContext.getApplication().getResourceHandler().getViewResources(
facesContext, "/websocket", 2, 
ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY);
stream.forEach(s -> {
System.out.println(s);
});

/websocket/clockAjax.xhtml
/websocket/testws.xhtml
/websocket/websocket.xhtml

Stream stream = 
facesContext.getApplication().getResourceHandler().getViewResources(
facesContext, "/websocket/", 2, 
ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY);
stream.forEach(s -> {
System.out.println(s);
});

/websocket/clockAjax.xhtml
/websocket/testws.xhtml
/websocket/websocket.xhtml

> Implement ResourceHandler.getViewResources(...)
> ---
>
> Key: MYFACES-4098
> URL: https://issues.apache.org/jira/browse/MYFACES-4098
> Project: MyFaces Core
>  Issue Type: New Feature
>  Components: JSR-372
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MYFACES-4099) Allow resolve #{cc} inside templates called from a composite component

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe updated MYFACES-4099:

   Resolution: Fixed
Fix Version/s: 2.3.0
   2.2.13
   2.1.19
   Status: Resolved  (was: Patch Available)

I finally committed a variant of the solution proposed, after check inline EL 
is working well without changes. Fixed on 2.1.x, 2.2.x and 2.3.x

> Allow resolve #{cc} inside templates called from a composite component
> --
>
> Key: MYFACES-4099
> URL: https://issues.apache.org/jira/browse/MYFACES-4099
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.12
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
> Fix For: 2.1.19, 2.2.13, 2.3.0
>
> Attachments: TagAttributeImpl.java.patch
>
>
> It has been reported this scenario:
> {code:xml}
> 
>  
> 
> {code}
> In the included page:
> {code:xml}
> 
>  
> 
> {code}
> The problem right now is such kind of indirection has not been taken into 
> account for #{cc} EL resolution algorithm. It is supposed that any resolution 
> of #{cc} happens inside the composite component .xhtml and not indirectly 
> through a template like is happening in the previous example.
> This code leads to an StackOverflowException, because the algorithm cannot 
> find the right composite component and by default it takes the closest one.
> In MyFaces it is possible to pass the values as parameters of ui:include, but 
> the point is it is better if we allow these example to work.
> Please note this is not a bug. This looks like an improvement. The challenge 
> here is expressions using #{cc} outside a composite component xhtml are not 
> cacheable, so we need to study if this improvement can be done or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (MYFACES-4100) Default view pool is enabled for all views by default when cache mode is alwaysRecompile only

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe resolved MYFACES-4100.
-
   Resolution: Fixed
Fix Version/s: 2.2.13

> Default view pool is enabled for all views by default when cache mode is 
> alwaysRecompile only
> -
>
> Key: MYFACES-4100
> URL: https://issues.apache.org/jira/browse/MYFACES-4100
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.2.12
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Fix For: 2.2.13
>
>
> There is an small bug in the activation of the default view pool in 
> ViewPoolFactory class.
> When org.apache.myfaces.CACHE_EL_EXPRESSIONS is set to "alwaysRecompile". 
> ViewPool feature is enabled, but the default view pool applies to all views 
> that does not have any view pool mapping in faces-config.xml, but only when 
> oamEnableViewPool is set. 
> What's happening right now is view pool is automatically enabled for all 
> views by default, and this should be changed to the opposite.
> The reason is "alwaysRecompile" is a EL caching feature by itself that does 
> not require the view pool to work, but the view pool only works well when 
> "alwaysRecompile" is set.
> This part is quite confusing, but the fix needs to be done. It was discovered 
> looking for a solution for  MYFACES-4099



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4100) Default view pool is enabled for all views by default when cache mode is alwaysRecompile only

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4100:
---

 Summary: Default view pool is enabled for all views by default 
when cache mode is alwaysRecompile only
 Key: MYFACES-4100
 URL: https://issues.apache.org/jira/browse/MYFACES-4100
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.2.12
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe


There is an small bug in the activation of the default view pool in 
ViewPoolFactory class.

When org.apache.myfaces.CACHE_EL_EXPRESSIONS is set to "alwaysRecompile". 
ViewPool feature is enabled, but the default view pool applies to all views 
that does not have any view pool mapping in faces-config.xml, but only when 
oamEnableViewPool is set. 

What's happening right now is view pool is automatically enabled for all views 
by default, and this should be changed to the opposite.

The reason is "alwaysRecompile" is a EL caching feature by itself that does not 
require the view pool to work, but the view pool only works well when 
"alwaysRecompile" is set.

This part is quite confusing, but the fix needs to be done. It was discovered 
looking for a solution for  MYFACES-4099



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (MYFACES-4099) Allow resolve #{cc} inside templates called from a composite component

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4099:
-

Attached potential patch for this issue. I need to study it and create some 
junit tests, to see if it works as expected or not. This is a sensible change, 
so we need to do proper tests check multiple possible situations.

> Allow resolve #{cc} inside templates called from a composite component
> --
>
> Key: MYFACES-4099
> URL: https://issues.apache.org/jira/browse/MYFACES-4099
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.12
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
> Attachments: TagAttributeImpl.java.patch
>
>
> It has been reported this scenario:
> {code:xml}
> 
>  
> 
> {code}
> In the included page:
> {code:xml}
> 
>  
> 
> {code}
> The problem right now is such kind of indirection has not been taken into 
> account for #{cc} EL resolution algorithm. It is supposed that any resolution 
> of #{cc} happens inside the composite component .xhtml and not indirectly 
> through a template like is happening in the previous example.
> This code leads to an StackOverflowException, because the algorithm cannot 
> find the right composite component and by default it takes the closest one.
> In MyFaces it is possible to pass the values as parameters of ui:include, but 
> the point is it is better if we allow these example to work.
> Please note this is not a bug. This looks like an improvement. The challenge 
> here is expressions using #{cc} outside a composite component xhtml are not 
> cacheable, so we need to study if this improvement can be done or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (MYFACES-4099) Allow resolve #{cc} inside templates called from a composite component

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe updated MYFACES-4099:

Status: Patch Available  (was: Open)

> Allow resolve #{cc} inside templates called from a composite component
> --
>
> Key: MYFACES-4099
> URL: https://issues.apache.org/jira/browse/MYFACES-4099
> Project: MyFaces Core
>  Issue Type: Improvement
>Affects Versions: 2.2.12
>Reporter: Thomas Andraschko
>Assignee: Leonardo Uribe
> Attachments: TagAttributeImpl.java.patch
>
>
> It has been reported this scenario:
> {code:xml}
> 
>  
> 
> {code}
> In the included page:
> {code:xml}
> 
>  
> 
> {code}
> The problem right now is such kind of indirection has not been taken into 
> account for #{cc} EL resolution algorithm. It is supposed that any resolution 
> of #{cc} happens inside the composite component .xhtml and not indirectly 
> through a template like is happening in the previous example.
> This code leads to an StackOverflowException, because the algorithm cannot 
> find the right composite component and by default it takes the closest one.
> In MyFaces it is possible to pass the values as parameters of ui:include, but 
> the point is it is better if we allow these example to work.
> Please note this is not a bug. This looks like an improvement. The challenge 
> here is expressions using #{cc} outside a composite component xhtml are not 
> cacheable, so we need to study if this improvement can be done or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4099) Allow resolve #{cc} inside templates called from a composite component

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4099:
---

 Summary: Allow resolve #{cc} inside templates called from a 
composite component
 Key: MYFACES-4099
 URL: https://issues.apache.org/jira/browse/MYFACES-4099
 Project: MyFaces Core
  Issue Type: Improvement
Affects Versions: 2.2.12
Reporter: Thomas Andraschko
Assignee: Leonardo Uribe


It has been reported this scenario:

{code:xml}

 

{code}

In the included page:

{code:xml}

 

{code}

The problem right now is such kind of indirection has not been taken into 
account for #{cc} EL resolution algorithm. It is supposed that any resolution 
of #{cc} happens inside the composite component .xhtml and not indirectly 
through a template like is happening in the previous example.

This code leads to an StackOverflowException, because the algorithm cannot find 
the right composite component and by default it takes the closest one.

In MyFaces it is possible to pass the values as parameters of ui:include, but 
the point is it is better if we allow these example to work.

Please note this is not a bug. This looks like an improvement. The challenge 
here is expressions using #{cc} outside a composite component xhtml are not 
cacheable, so we need to study if this improvement can be done or not.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (MYFACES-4098) Implement ResourceHandler.getViewResources(...)

[Leonardo Uribe (JIRA)]

Leonardo Uribe created MYFACES-4098:
---

 Summary: Implement ResourceHandler.getViewResources(...)
 Key: MYFACES-4098
 URL: https://issues.apache.org/jira/browse/MYFACES-4098
 Project: MyFaces Core
  Issue Type: New Feature
  Components: JSR-372
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)