[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(

Re: MYFACES-4244 Discussion

[Leonardo Uribe]

Hi

The consideration behind SharedStringBuilder is to keep a low memory
footprint, avoiding unnecessary object creation in situations where there
are lines of code that are called many times. It is not something to use
everywhere, only in very specific locations. The best garbage collector is
the one that is not called.

regards,

Leonardo Uribe

2018-07-12 8:27 GMT-05:00 Paul Nicolucci :

> I'll work to get that additional information.
>
> Also will look into using SharedStringBuilder.
>
> Thanks for the feedback.
>
> Regards,
>
> Paul
>
> [image: Inactive hide details for Thomas Andraschko ---07/12/2018 03:35:11
> AM---The SharedStringBuilder is only shared in the current r]Thomas
> Andraschko ---07/12/2018 03:35:11 AM---The SharedStringBuilder is only
> shared in the current request, so thats not a poblem.
>
> From: Thomas Andraschko 
> To: MyFaces Development 
> Date: 07/12/2018 03:35 AM
> Subject: Re: MYFACES-4244 Discussion
> --
>
>
>
> The SharedStringBuilder is only shared in the current request, so thats
> not a poblem.
> Take for example the #writeAttribute or #encodeAndWriteAttribute. I added
> a counter in #writeAttribute and even for a very small few, it's called
> about 2000 times.
> If you would also count the other instances, i'm sure there will be over
> 20.000 StringBuilder instances on normal views.
>
> See: *https://issues.apache.org/jira/browse/MYFACES-3130*
> <https://issues.apache.org/jira/browse/MYFACES-3130>
>
>
> I think we should check the "writer chain", whats exactly slow.
> The response should actually be buffered (javax.faces.FACELETS_BUFFER_SIZE
> ) and there should NOT be a big difference.
>
>
> For me a -1 without SharedStringBuilder and a -0.5 with
> SharedStringBuilder for now.
> We need to check the exact reason whats slow and also check the
> performance difference. Could you provide some numbers before and after
> this change only?
>
> I would also like to wait for other input from Leo or Gerhard.
>
>
>
> 2018-07-11 21:42 GMT+02:00 Paul Nicolucci <*pnico...@us.ibm.com*
> >:
>
>Hello all,
>
>I've made some performance improvements to MyFaces here:
>*https://issues.apache.org/jira/browse/MYFACES-4244*
><https://issues.apache.org/jira/browse/MYFACES-4244>
>
>I've put together a Pull Request here with the changes:
>*https://github.com/apache/myfaces/pull/10*
><https://github.com/apache/myfaces/pull/10>
>
>I know that Thomas had some concerns with using a StringBuilder here
>and I think I've addressed those concerns in the description of the JIRA
>issue.
>
>Doing some profiling of an application with some JSF in it we saw
>performance improvements with these changes and as a result I wanted to
>commit them.
>
>Please let me know if you have any questions or concerns.
>
>Thanks,
>
>Paul
>
>
>
>

[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)

Re: broken CDI handling in MyFacesContainerInitializer

[Leonardo Uribe]

Hi

It looks like a chicken-egg problem. But if CDI is present, it should run
before MyFaces, so BeanManager should be available on MyFaces startup,
never the opposite. After all, it is the bean container and the code was
not designed for the opposite. I don't know if something changed.

As far as I can remember there is no CDI initialization in the startup, but
the BeanManager reference is required at that point since after that part,
other features are enabled/disabled based on the reference.

But in 2.3.0 MyFaces is no longer able to run without CDI (deprecation of
Managed Beans).

In my opinion the container should set the ordering: first CDI then
MyFaces, not the opposite. It doesn't look like something to be solved in
MyFaces side.

regards,

Leonardo Uribe

2018-04-13 3:04 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Puh, stupid problem
>
> I think we must move the "CDI-init stuff" into a extension, but the leave
> everything else as it is as MF can still be used without CDI.
> As the ServletContextInitializer runs before the CDI Extensions, the
> StartupFacesContext could be available, also in the extension?
>
>
>
> 2018-04-13 9:54 GMT+02:00 Mark Struberg <strub...@yahoo.de>:
>
>> Hi folks!
>>
>> I've figured that we blow up pretty nasty when using latest MyFaces on
>> Tomcat with any CDI container (OWB or Weld).
>> That's because you must not use BeanManager#getBeans before
>> AfterDeplyomentValidation gets fired.
>>
>> I think the whole handling should ONLY be done via a CDI Extension!
>> In which way it will automatically get picked up and will initialise
>> Flows perfectly fine.
>>
>> The only problem to solve is how to make the FacesContext available from
>> within the CDI Extension.
>> The ticket is tracked as MYFACES-4224.
>> Feedback welcome.
>>
>>
>> LieGrue,
>> strub
>
>
>

Re: javax.faces.WEBSOCKET_PORT discussion

[Leonardo Uribe]

+1 for 2



2018-04-02 15:13 GMT-05:00 Thomas Andraschko :

> +1 for 2
>
> 2.3.0 is very new and everyone knows that a x.0 release isnt stable for
> 100%.
>
>
> Am Montag, 2. April 2018 schrieb Paul Nicolucci :
>
>> Hi,
>>
>> I've been doing some reviews of our implementation and I noticed that we
>> have the following context parameter: javax.faces.WEBSOCKET_PORT which is
>> used by the ServletExternalContextImpl.encodeWebsocketURL().
>>
>> However, looking over the JSF 2.3 spec documentation I see the following
>> parameter specified on page 10-25:
>>
>> In case your server is configured to run a WebSocket container on a
>> different TCP port than the HTTP
>> container, then you can use the optional *javax.faces.WEBSOCKET_ENDPOINT_PORT
>> *integer context
>> parameter in web.xml to explicitly specify the port.
>>
>> *We need to decide the following:*
>>
>> 1) Allow either parameter and add support for the missing
>> javax.faces.WEBSOCKET_ENDPOINT_PORT in MyFaces
>> 2) Rename our parameter to the spec defined one ( could potentially break
>> any apps that are already using the non spec defined parameter in 2.3.0).
>>
>> I think #1 is our safest bet but wanted to get some additional input if
>> anyone had it.
>>
>> Thanks,
>>
>> Paul Nicolucci
>>
>

Re: Questions about MyFaces 2.3.0 release

[Leonardo Uribe]

Hi

That's automatic. Once you have released the repo in nexus, you don't need
to do anything else.

regards,

Leonardo Uribe

2018-03-09 15:21 GMT-05:00 Eduardo B <ebre...@gmail.com>:

> Thanks again guys, I've been able to update the MyFaces website with JSF
> 2.3: https://myfaces.apache.org/
>
> I still have one more/final question hopefully.
>
> How do we get the jars into maven central?
>
> For example: https://mvnrepository.com/artifact/org.apache.myfaces.
> core/myfaces-api
>   https://mvnrepository.com/
> artifact/org.apache.myfaces.core/myfaces-impl
>
> I only see the beta jars.
>
> Thanks,
> Eduardo
>
> On Wed, Mar 7, 2018 at 1:58 PM, Leonardo Uribe <lu4...@gmail.com> wrote:
>
>> Hi
>>
>> It is the same process as in Tobago. Please take a look at myfaces-site
>> pom.xml there are some predefined paths:
>>
>>   
>> ${user.home}/myfaces-site/checkout> .mainDirectory>
>> ${user.home}/myfaces-site/site
>> 
>> \${site.mainDirectory}
>> file://${user.home}/myfaces-site/site> eploy.url>
>>   
>>
>> In my case there was a folder called /home/lu4242/myfaces-site/checkout
>> and other /home/lu4242/myfaces-site/site. site:stage create some files
>> in "site" folder, then I just override in checkout and commit.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2018-03-07 12:40 GMT-05:00 Udo Schnurpfeil <lof...@apache.org>:
>>
>>> Hi Eduardo,
>>>
>>> I've never done this for the core (only Tobago), so I'm not sure about
>>> that...
>>>
>>> The site you can see here: https://myfaces.apache.org/ is synced by
>>> some automatic job from this repo:
>>>
>>>  https://svn.apache.org/repos/asf/myfaces/site/publish/
>>>
>>> So, you need to
>>>
>>> 1. checkout the relevant parts from that URL
>>>
>>> 2. building the site (it seems that you have done it already)
>>>
>>> 3. syncing this site (from 2.) locally to the checkout (from 1.) using
>>> "mvn site:stage"
>>>
>>> 4. commit it
>>>
>>> It seems, there is no many entry and no subfolder for 2.3 currently. I
>>> assume this must be created.
>>>
>>>
>>> For Tobago these steps are described here:
>>>
>>> https://myfaces.apache.org/tobago/release-checklist.html (look for
>>> "Building the site")
>>>
>>>
>>> Hope that helps
>>>
>>> Udo
>>> Am 06.03.18 um 22:33 schrieb Eduardo B:
>>>
>>> I went ahead and checked out src from https://svn.apache.org/re
>>> pos/asf/myfaces/site/trunk/
>>>
>>> I have modified some files with new download links, reference to MyFaces
>>> 2.3.0, etc. When I tried to do mvn site:deploy I'm getting a connection
>>> refused error.
>>>
>>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error
>>> uploading site
>>>
>>> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.push
>>> (AbstractDeployMojo.java:478)
>>>
>>> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.depl
>>> oy(AbstractDeployMojo.java:332)
>>>
>>> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.depl
>>> oyTo(AbstractDeployMojo.java:293)
>>>
>>> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.exec
>>> ute(AbstractDeployMojo.java:172)
>>>
>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMoj
>>> o(DefaultBuildPluginManager.java:134)
>>>
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>>> oExecutor.java:207)
>>>
>>> ... 20 more
>>>
>>> Caused by: org.apache.maven.wagon.authentication.AuthenticationException:
>>> Cannot connect. Reason: java.net.ConnectException: Connection refused
>>> (Connection refused)
>>>
>>> at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.
>>> openConnectionInternal(AbstractJschWagon.java:264)
>>>
>>> at org.apache.maven.wagon.AbstractWagon.openConnection(Abstract
>>> Wagon.java:115)
>>>
>>> at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:216)
>>>
>>> at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:152)
>>>
>>> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.push
>>> (AbstractDeployMojo.java:428)
>>>
&

Re: Questions about MyFaces 2.3.0 release

[Leonardo Uribe]

Hi

It is the same process as in Tobago. Please take a look at myfaces-site
pom.xml there are some predefined paths:

  

${user.home}/myfaces-site/checkout
${user.home}/myfaces-site/site

\${site.mainDirectory}
file://${user.home}/myfaces-site/site
  

In my case there was a folder called /home/lu4242/myfaces-site/checkout and
other /home/lu4242/myfaces-site/site. site:stage create some files in
"site" folder, then I just override in checkout and commit.

regards,

Leonardo Uribe

2018-03-07 12:40 GMT-05:00 Udo Schnurpfeil <lof...@apache.org>:

> Hi Eduardo,
>
> I've never done this for the core (only Tobago), so I'm not sure about
> that...
>
> The site you can see here: https://myfaces.apache.org/ is synced by some
> automatic job from this repo:
>
>  https://svn.apache.org/repos/asf/myfaces/site/publish/
>
> So, you need to
>
> 1. checkout the relevant parts from that URL
>
> 2. building the site (it seems that you have done it already)
>
> 3. syncing this site (from 2.) locally to the checkout (from 1.) using
> "mvn site:stage"
>
> 4. commit it
>
> It seems, there is no many entry and no subfolder for 2.3 currently. I
> assume this must be created.
>
>
> For Tobago these steps are described here:
>
> https://myfaces.apache.org/tobago/release-checklist.html (look for
> "Building the site")
>
>
> Hope that helps
>
> Udo
> Am 06.03.18 um 22:33 schrieb Eduardo B:
>
> I went ahead and checked out src from https://svn.apache.org/
> repos/asf/myfaces/site/trunk/
>
> I have modified some files with new download links, reference to MyFaces
> 2.3.0, etc. When I tried to do mvn site:deploy I'm getting a connection
> refused error.
>
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error
> uploading site
>
> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.
> push(AbstractDeployMojo.java:478)
>
> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.
> deploy(AbstractDeployMojo.java:332)
>
> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.
> deployTo(AbstractDeployMojo.java:293)
>
> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.
> execute(AbstractDeployMojo.java:172)
>
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> DefaultBuildPluginManager.java:134)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:207)
>
> ... 20 more
>
> Caused by: org.apache.maven.wagon.authentication.AuthenticationException:
> Cannot connect. Reason: java.net.ConnectException: Connection refused
> (Connection refused)
>
> at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.
> openConnectionInternal(AbstractJschWagon.java:264)
>
> at org.apache.maven.wagon.AbstractWagon.openConnection(
> AbstractWagon.java:115)
>
> at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:216)
>
> at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:152)
>
> at org.apache.maven.plugins.site.deploy.AbstractDeployMojo.
> push(AbstractDeployMojo.java:428)
>
> ... 25 more
>
>
> Maybe I'm missing some kind of permission in the server?
>
> Regards,
> Eduardo
>
> On Tue, Mar 6, 2018 at 2:23 PM, Eduardo B <ebre...@gmail.com> wrote:
>
>> Thanks a lot for all the help so far.
>>
>> I have distributed the assembly files already. I'm in the final step
>> which is the site deployment.
>>
>> I know I have to run mvn site:site and mvn site:deploy but where do I run
>> those commands from?
>>
>> Is it from
>> 1) https://svn.apache.org/repos/asf/myfaces/site/trunk/
>>
>> or
>> 2) https://svn.apache.org/repos/asf/myfaces/core/tags/myface
>> s-core-module-2.3.0/
>>
>> Also I know I have to do some modifications like the download links, etc.
>> But how do I create de core23 site? Is it automatically created when the
>> commands mentioned about are executed?
>>
>> Thanks again,
>> Eduardo
>>
>> On Mon, Mar 5, 2018 at 5:50 PM, Udo Schnurpfeil <lof...@apache.org>
>> wrote:
>>
>>> Hi Eduardo,
>>>
>>> I'm using this description for the releases of Tobago, which might be
>>> quite similar:
>>>
>>> http://myfaces.apache.org/tobago/release-checklist.html
>>>
>>> For the distribution I use this Script (which is linked on the page
>>> obove). It loads the artefacts from the maven repo (you may also want to
>>> use your local artifacts, alliteratively. Than it checks the hashes and
>>> load the stuff up to SVN.
>>>
>>> http://myfaces.apache.org/toba

Re: Questions about MyFaces 2.3.0 release

[Leonardo Uribe]

Hi

Use a svn client to add the release artifacts in the svn repo in:

https://dist.apache.org/repos/dist/release/myfaces/

See:

http://www.apache.org/dev/release-publishing.html#distribution_dist

regards,

Leonardo Uribe



2018-03-05 17:21 GMT-05:00 Eduardo B <ebre...@gmail.com>:

> I found this link with good information: http://www.
> apache.org/legal/release-policy.html#upload-ci
>
> I think we need to upload the assembly files via SVN to
> https://dist.apache.org/repos/dist/release/myfaces/
>
> Please correct me if I'm wrong.
>
> Eduardo
>
> On Mon, Mar 5, 2018 at 5:04 PM, Eduardo B <ebre...@gmail.com> wrote:
>
>> Does anyone know how to upload the assembly files to any of these pages
>> to start distributing MyFaces Core 2.3.0?
>>
>> https://www.apache.org/dist/myfaces/
>> https://dist.apache.org/repos/dist/release/myfaces/
>>
>>
>> I tried via sftp but I was not able to connect. Once I figure that, I
>> should be able to also distribute it to maven central repository and also
>> deploy the myfaces core23 site.
>>
>> Regards,
>> Eduardo M. Breijo
>>
>> On Sat, Feb 24, 2018 at 8:33 PM, Leonardo Uribe <lu4...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> Forget to say, you should  "close repo" in nexus. If the artifacts has
>>> some bug you can click "drop" on nexus, if the artifacts are approved you
>>> can click on "release".
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2018-02-24 20:31 GMT-05:00 Leonardo Uribe <lu4...@gmail.com>:
>>>
>>>> Hi
>>>>
>>>> I can see the artifacts in nexus.
>>>>
>>>> Please log in
>>>>
>>>> https://repository.apache.org
>>>>
>>>> Click on staging repositories
>>>>
>>>> The path of the artifacts is there:
>>>>
>>>> https://repository.apache.org/content/repositories/orgapache
>>>> myfaces-1130/org/apache/myfaces/core/myfaces-core-assembly/
>>>>
>>>> But you need to close the repo so the artifacts can be downloaded.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2018-02-24 20:13 GMT-05:00 Thomas Andraschko <
>>>> andraschko.tho...@gmail.com>:
>>>>
>>>>> I thougt there are available in the root but cant find it:
>>>>> https://repository.apache.org/content/repositories/
>>>>>
>>>>> Am Freitag, 23. Februar 2018 schrieb Eduardo B :
>>>>>
>>>>>> Can you send me the link to that orgapachemyfaces-1130 repo? I tried
>>>>>> looking https://repository.apache.org/content/repositories/s
>>>>>> taging/org/apache/myfaces/   but I could not find it.
>>>>>>
>>>>>> On Fri, Feb 23, 2018 at 12:21 PM, Dennis Kieselhorst <d...@apache.org
>>>>>> > wrote:
>>>>>>
>>>>>>> > On nexus repository I only see the snapshot of 2.3.1-SNAPSHOT:
>>>>>>> > https://repository.apache.org/content/repositories/snapshots
>>>>>>> /org/apache/myfaces/core/myfaces-core-module/2.3.1-SNAPSHOT/
>>>>>>>
>>>>>>> As far as I can see a staging repo on nexus has been created:
>>>>>>> Repository  orgapachemyfaces-1130 (org.apache.myfaces)
>>>>>>> Created Thursday, February 22, 2018 20:42:43 GMT (GMT+0100)
>>>>>>> Updated Thursday, February 22, 2018 20:42:43 GMT (GMT+0100)
>>>>>>> Activity
>>>>>>> Last operation completed successfully
>>>>>>> Owner   embreijo (129.42.208.179)
>>>>>>> User-Agent  Apache-Maven/3.3.9 (Java 1.8.0_121; Mac OS X 10.13.3)
>>>>>>>
>>>>>>> So looks like you can continue with it...
>>>>>>>
>>>>>>> Regards
>>>>>>> Dennis
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>

Re: Questions about MyFaces 2.3.0 release

[Leonardo Uribe]

Hi

Forget to say, you should  "close repo" in nexus. If the artifacts has some
bug you can click "drop" on nexus, if the artifacts are approved you can
click on "release".

regards,

Leonardo Uribe

2018-02-24 20:31 GMT-05:00 Leonardo Uribe <lu4...@gmail.com>:

> Hi
>
> I can see the artifacts in nexus.
>
> Please log in
>
> https://repository.apache.org
>
> Click on staging repositories
>
> The path of the artifacts is there:
>
> https://repository.apache.org/content/repositories/
> orgapachemyfaces-1130/org/apache/myfaces/core/myfaces-core-assembly/
>
> But you need to close the repo so the artifacts can be downloaded.
>
> regards,
>
> Leonardo Uribe
>
>
>
>
>
> 2018-02-24 20:13 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>
> :
>
>> I thougt there are available in the root but cant find it:
>> https://repository.apache.org/content/repositories/
>>
>> Am Freitag, 23. Februar 2018 schrieb Eduardo B :
>>
>>> Can you send me the link to that orgapachemyfaces-1130 repo? I tried
>>> looking https://repository.apache.org/content/repositories/s
>>> taging/org/apache/myfaces/   but I could not find it.
>>>
>>> On Fri, Feb 23, 2018 at 12:21 PM, Dennis Kieselhorst <d...@apache.org>
>>> wrote:
>>>
>>>> > On nexus repository I only see the snapshot of 2.3.1-SNAPSHOT:
>>>> > https://repository.apache.org/content/repositories/snapshots
>>>> /org/apache/myfaces/core/myfaces-core-module/2.3.1-SNAPSHOT/
>>>>
>>>> As far as I can see a staging repo on nexus has been created:
>>>> Repository  orgapachemyfaces-1130 (org.apache.myfaces)
>>>> Created Thursday, February 22, 2018 20:42:43 GMT (GMT+0100)
>>>> Updated Thursday, February 22, 2018 20:42:43 GMT (GMT+0100)
>>>> Activity
>>>> Last operation completed successfully
>>>> Owner   embreijo (129.42.208.179)
>>>> User-Agent  Apache-Maven/3.3.9 (Java 1.8.0_121; Mac OS X 10.13.3)
>>>>
>>>> So looks like you can continue with it...
>>>>
>>>> Regards
>>>> Dennis
>>>>
>>>
>>>
>

Re: Questions about MyFaces 2.3.0 release

[Leonardo Uribe]

Hi

I can see the artifacts in nexus.

Please log in

https://repository.apache.org

Click on staging repositories

The path of the artifacts is there:

https://repository.apache.org/content/repositories/orgapachemyfaces-1130/org/apache/myfaces/core/myfaces-core-assembly/

But you need to close the repo so the artifacts can be downloaded.

regards,

Leonardo Uribe





2018-02-24 20:13 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> I thougt there are available in the root but cant find it:
> https://repository.apache.org/content/repositories/
>
> Am Freitag, 23. Februar 2018 schrieb Eduardo B :
>
>> Can you send me the link to that orgapachemyfaces-1130 repo? I tried
>> looking https://repository.apache.org/content/repositories/
>> staging/org/apache/myfaces/   but I could not find it.
>>
>> On Fri, Feb 23, 2018 at 12:21 PM, Dennis Kieselhorst <d...@apache.org>
>> wrote:
>>
>>> > On nexus repository I only see the snapshot of 2.3.1-SNAPSHOT:
>>> > https://repository.apache.org/content/repositories/snapshots
>>> /org/apache/myfaces/core/myfaces-core-module/2.3.1-SNAPSHOT/
>>>
>>> As far as I can see a staging repo on nexus has been created:
>>> Repository  orgapachemyfaces-1130 (org.apache.myfaces)
>>> Created Thursday, February 22, 2018 20:42:43 GMT (GMT+0100)
>>> Updated Thursday, February 22, 2018 20:42:43 GMT (GMT+0100)
>>> Activity
>>> Last operation completed successfully
>>> Owner   embreijo (129.42.208.179)
>>> User-Agent  Apache-Maven/3.3.9 (Java 1.8.0_121; Mac OS X 10.13.3)
>>>
>>> So looks like you can continue with it...
>>>
>>> Regards
>>> Dennis
>>>
>>
>>

Re: Questions about MyFaces 2.3.0 release

[Leonardo Uribe]

Hi

2018-02-16 16:17 GMT-05:00 Eduardo B <ebre...@gmail.com>:

> Hi,
>
> I started to perform the MyFaces 2.3.0 release today. I'm following these
> two wikis as reference:
>
> https://wiki.apache.org/myfaces/CoreRelease2212
>
> https://wiki.apache.org/myfaces/CoreRelease230beta
>
> 1) From MyFaces 2.2.12 release wiki, step 1 is trying to perform a release
> on a shared project, do I have to do the same thing for MyFaces 2.3.0
> release? If so what's the repository to checkout from so I can perform the
> release?
>
>
The current structure does not require a "shared project" release, since it
just copy the code inside the shared module in myfaces core. That step is
optional.


>
> 2) I was able to prepare and perform MyFaces Core 2.3.0 release.
>
> https://svn.apache.org/viewvc/myfaces/core/tags/myfaces-core-module-2.3.0/
>
> But there is another step that says TCK passed confirmed by Leonardo
> Uribe. @Leo can you provide more information on what to do there? Can you
> verify if TCK tests are passing?
>
>
I do not know if there is a TCK for JSF 2.3. Apache resigned JCP seat in
2010.


>
> 3) The step to generate assembly on MyFaces 2.2.12 release wiki seems to
> be manually, while on the MyFaces 2.3.0-beta release wiki it says that it
> is generated automatically by maven. Not sure if in my case was auto
> generated, but in any case I see that we need to copy the archives to
> people.apache.org server. Is that part necessary? Do I need to get access
> for that server? If so how do I get it?
>
> Also I see that the assembly archives can be retrieved from nexus maven
> repository? Are they uploaded automatically when preparing and performing
> the build?
>
>
> I'm new on all this, any help will be appreciated. Once I figure those
> steps, the next step would be to send an email to vote.
>
>
Assembly generation is done automatically by nexus, on release:perform
step. I usually grab the artifacts from nexus maven repo to do the final
deploy.

regards,

Leonardo Uribe

Regards,
> Eduardo M. Breijo
>
>
>
>

Re: MyFaces 2.3.0 Release?

[Leonardo Uribe]

Hi

Keep in mind this one:

https://wiki.apache.org/myfaces/CoreRelease2212

It should be very easy to do it, since all required config was already done
in beta release.

regards,

Leonardo Uribe




2018-02-05 9:12 GMT-05:00 Eduardo B <ebre...@gmail.com>:

> I'm also new to this. But I found this link from JSF 2.3.0-beta release
> with some steps that maybe can help?
>
> https://wiki.apache.org/myfaces/CoreRelease230beta
>
> Regards,
> Eduardo
>
>
> On Mon, Feb 5, 2018 at 9:09 AM, Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> Is there a step-by-step tutorial available to do a release as a dummie?
>> Really, i'm totally new to "releases" and don't have to time to work
>> several hours on it.
>>
>> 2018-02-01 21:23 GMT+01:00 Dennis Kieselhorst <d...@apache.org>:
>>
>>> Hi Thomas!
>>>
>>> > Also we probably need to cleanup the branches/trunk a bit?!
>>> > Trunk is actually 2.2.x - we should move it to a 2.2.x branch.
>>> > Then we would need to merge the changes from 2.3.x into trunk and make
>>> > trunk 2.4.x?
>>>
>>> I would leave 2.3.x in trunk for a while as we did with 2.2.x before.
>>>
>>> Leo, do you have time to do the release?
>>>
>>> Cheers
>>> Dennis
>>>
>>
>>
>

Re: MyFaces 2.3.0 last item - MyFaces-4133

[Leonardo Uribe]

Hi

Ok, Before 2.3.0 release is the right time to do it. I do not want to be a
stone on the road, so please do it. I think I have made clear my reasoning
about it, it is not mandatory, it is just an opinion.

regards,

Leonardo Uribe


2018-01-29 3:52 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Hi,
>
> the question is: Why should we use encryption and serialization when it's
> actually >NOT< required for server side state?
> Sure, encryption should be safe actually but instead of using a better
> encryption algorithm like mentioned in the ticket, it's better to just
> removed the encryption.
> Probably it's also better for performance reasons - however i think it's
> not measurable.
>
> IMO the best solution would be the following:
> 1) skip serialization on server-side state
> 2) upgrade to algorithm, like also mentioned in the ticket, for client
> side state
>
> So we are safer for client side state and absolutely safe for server side
> state.
>
> Also the community is interessted in doing the change. The TomEE guys
> already forked MyFaces do to this changes in 2.2.x AFAIR.
>
> Regards,
> Thomas
>
>
>
> 2018-01-29 3:07 GMT+01:00 Leonardo Uribe <lu4...@gmail.com>:
>
>> Hi
>>
>> I think this issue has very low priority. After thinking a lot on it I
>> prefer do not do nothing. Less is more in my opinion.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2018-01-28 20:57 GMT-05:00 Leonardo Uribe <lu4...@gmail.com>:
>>
>>> Hi
>>>
>>> I think MYFACES-4133 does not qualify to be a bug, because encryption
>>> should be always enabled.
>>>
>>> Is it required? No
>>>
>>> Is it an improvement? Not really. I still need a reason why enable this
>>> mode.
>>>
>>> Can we avoid the serialization/deserialization step? yes.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2018-01-28 9:12 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com
>>> >:
>>>
>>>> Hi,
>>>>
>>>> IMO the change is almost mandatory for 2.3.0.
>>>>
>>>> Please also see the discussion in "[myfaces core] don't deserialize
>>>> ViewState-ID if state saving method is server".
>>>>
>>>> @Leo: Do you have time to refactor it?
>>>>
>>>> Otherwise i would reapply my patch but with "random" instead of
>>>> "secureRandom".
>>>> Thats fine for now. We can still refactor or improve the API later in
>>>> 2.3.x or even in JSF.next.
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>>
>>>>
>>>> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> It looks like the only remaining item we have before we can deliver
>>>>> 2.3.0 is : https://issues.apache.org/jira/browse/MYFACES-4133
>>>>>
>>>>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>>>>> 2.3.0 without a fix or is this mandatory?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Paul
>>>>>
>>>>
>>>>
>>>
>>
>

Re: MyFaces 2.3.0 last item - MyFaces-4133

[Leonardo Uribe]

Hi

I think this issue has very low priority. After thinking a lot on it I
prefer do not do nothing. Less is more in my opinion.

regards,

Leonardo Uribe

2018-01-28 20:57 GMT-05:00 Leonardo Uribe <lu4...@gmail.com>:

> Hi
>
> I think MYFACES-4133 does not qualify to be a bug, because encryption
> should be always enabled.
>
> Is it required? No
>
> Is it an improvement? Not really. I still need a reason why enable this
> mode.
>
> Can we avoid the serialization/deserialization step? yes.
>
> regards,
>
> Leonardo Uribe
>
> 2018-01-28 9:12 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:
>
>> Hi,
>>
>> IMO the change is almost mandatory for 2.3.0.
>>
>> Please also see the discussion in "[myfaces core] don't deserialize
>> ViewState-ID if state saving method is server".
>>
>> @Leo: Do you have time to refactor it?
>>
>> Otherwise i would reapply my patch but with "random" instead of
>> "secureRandom".
>> Thats fine for now. We can still refactor or improve the API later in
>> 2.3.x or even in JSF.next.
>>
>> Regards,
>> Thomas
>>
>>
>>
>> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>
>>> Hi,
>>>
>>> It looks like the only remaining item we have before we can deliver
>>> 2.3.0 is : https://issues.apache.org/jira/browse/MYFACES-4133
>>>
>>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>>> 2.3.0 without a fix or is this mandatory?
>>>
>>> Thanks,
>>>
>>> Paul
>>>
>>
>>
>

Re: MyFaces 2.3.0 last item - MyFaces-4133

[Leonardo Uribe]

Hi

I think MYFACES-4133 does not qualify to be a bug, because encryption
should be always enabled.

Is it required? No

Is it an improvement? Not really. I still need a reason why enable this
mode.

Can we avoid the serialization/deserialization step? yes.

regards,

Leonardo Uribe

2018-01-28 9:12 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Hi,
>
> IMO the change is almost mandatory for 2.3.0.
>
> Please also see the discussion in "[myfaces core] don't deserialize
> ViewState-ID if state saving method is server".
>
> @Leo: Do you have time to refactor it?
>
> Otherwise i would reapply my patch but with "random" instead of
> "secureRandom".
> Thats fine for now. We can still refactor or improve the API later in
> 2.3.x or even in JSF.next.
>
> Regards,
> Thomas
>
>
>
> 2018-01-28 0:17 GMT+01:00 Paul Nicolucci <pnico...@us.ibm.com>:
>
>> Hi,
>>
>> It looks like the only remaining item we have before we can deliver 2.3.0
>> is : https://issues.apache.org/jira/browse/MYFACES-4133
>>
>> @Leonardo/Thomas, has an acceptable fix been created? Can we deliver
>> 2.3.0 without a fix or is this mandatory?
>>
>> Thanks,
>>
>> Paul
>>
>
>

Re: [myfaces core] don't deserialize ViewState-ID if state saving method is server

[Leonardo Uribe]

Hi

My mistake to suggest secureRandom as default. After doing the whole review
it
becomes clear.

In this moment with the methods moved to StateCache there is a conflict,
because through
the SPI interface (StateCacheFactory) in MYFACES-4078 you could override
the token
processing/generation, and that's not wanted by security reasons. I need to
change my
mind about instantiate StateTokenProcessor by StateCache, it doesn't work
by that reason.

I'll refactor the code to see what we can do.

regards,

Leonardo Uribe

2017-12-20 2:54 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Hi,
>
> you suggested to make secureRandom as default, independent if we do this
> change or not.
> IMO "random" is enough - just sequence isn't safe enough anymore and must
> not be used.
>
> +0 for reintroduce StateTokenProcessor
> I currently don't see any benefit for another layer and i'm unsure if this
> abstraction is ever needed.
> But if you would like to refactor it, please do.
>
>
> Regards,
> Thomas
>
> 2017-12-20 2:18 GMT+01:00 Leonardo Uribe <lu4...@gmail.com>:
>
>> Hi
>>
>> secureRandom is a performance bottleneck. That's a fact. It can't be set
>> as default.
>>
>> See for example this blog:
>>
>> http://www.mattnworb.com/post/the-dangers-of-java-security-securerandom/
>>
>> "... If you don’t read the descriptions carefully enough, you might miss
>> the fact
>> that /dev/random will block when there is not enough entropy data
>> available.
>> This means that in practice, it’s possible for your calls to
>> new SecureRandom() to block for an unknown amount of time"
>>
>> About MYFACES-3779: well, we are not solving that one here, but the
>> current
>> abstraction is strong enough to support it.
>>
>> About delete StateTokenProcessor: The token can include a mac, is
>> encrypted,
>> compressed, serialized. I think each one of these steps is complex enough
>> to
>> be encapsulated in one isolated class. Maybe we need to consider that
>> StateTokenProcessor must be instantiated by StateCache, not by
>> HtmlResponseStateManager. I don't think we are over engineering here,
>> because
>> the big abstraction are the three methods that does not really change,
>> but if
>> I want to create a new StateCache, maybe I don't want to write those three
>> methods over again, right? If I'm writing a new StateCache instance, I
>> want
>> to focus on how to store the state. Please note MYFACES-4078 expose
>> StateCacheFactory/StateCache to the public since 2.3.0, so these 3 methods
>> in StateCache creates a conflict with this issue I have been working for a
>> long time.
>>
>> This issue makes me feel I'm walking in circles.
>>
>> Keep it simple, follow the facts, the old known algorithm that uses mac
>> +encryption
>> works just fine. The algorithm has been designed to keep the token very
>> small
>> (IntIntKey...), so simplify here undo a previous work in that area. This
>> is
>> a problem where we reach a dead end. Just turn back.
>>
>> But move StateTokenProcessor inside StateCache is a good idea, but a
>> default implementation that behaves like we already know is important.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>
>> 2017-12-19 16:23 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com
>> >:
>>
>>> Yep, it's a viewstate-id or token, not view-id of course!
>>> If the current secureRandom is not perfect, we can still improve it.
>>> Also without this change discussed here, we would have set secureRandom
>>> as our default (we discussed this in the other topic), so i don't think see
>>> a problem here.
>>>
>>>
>>> I understand your point about https://issues.apache.org/jira
>>> /browse/MYFACES-3779 but quite a lot work must be done to get this
>>> working and is unsure if we will ever work on something.
>>> Also if we would work on it, i'm sure we would have to refactor much
>>> more things.
>>>
>>> Also your statement
>>> "The key point is maybe the state saving mode has something to say about
>>> how the token is processed."
>>> says that its actually one unit.
>>>
>>> We should not over-engineer something which is maybe never required.
>>> maintainability > abstraction - as it's already quite hard the follow
>>> our code in some places.
>>>
>>>
>>>
>>>
>>> 2017-12-19 21:57 GMT+01:00 Leonardo Uribe <lu4...@

Re: [myfaces core] don't deserialize ViewState-ID if state saving method is server

[Leonardo Uribe]

Hi

secureRandom is a performance bottleneck. That's a fact. It can't be set as
default.

See for example this blog:

http://www.mattnworb.com/post/the-dangers-of-java-security-securerandom/

"... If you don’t read the descriptions carefully enough, you might miss
the fact
that /dev/random will block when there is not enough entropy data
available.
This means that in practice, it’s possible for your calls to
new SecureRandom() to block for an unknown amount of time"

About MYFACES-3779: well, we are not solving that one here, but the current
abstraction is strong enough to support it.

About delete StateTokenProcessor: The token can include a mac, is
encrypted,
compressed, serialized. I think each one of these steps is complex enough to
be encapsulated in one isolated class. Maybe we need to consider that
StateTokenProcessor must be instantiated by StateCache, not by
HtmlResponseStateManager. I don't think we are over engineering here,
because
the big abstraction are the three methods that does not really change, but
if
I want to create a new StateCache, maybe I don't want to write those three
methods over again, right? If I'm writing a new StateCache instance, I want
to focus on how to store the state. Please note MYFACES-4078 expose
StateCacheFactory/StateCache to the public since 2.3.0, so these 3 methods
in StateCache creates a conflict with this issue I have been working for a
long time.

This issue makes me feel I'm walking in circles.

Keep it simple, follow the facts, the old known algorithm that uses mac
+encryption
works just fine. The algorithm has been designed to keep the token very
small
(IntIntKey...), so simplify here undo a previous work in that area. This is
a problem where we reach a dead end. Just turn back.

But move StateTokenProcessor inside StateCache is a good idea, but a
default implementation that behaves like we already know is important.

regards,

Leonardo Uribe



2017-12-19 16:23 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Yep, it's a viewstate-id or token, not view-id of course!
> If the current secureRandom is not perfect, we can still improve it.
> Also without this change discussed here, we would have set secureRandom as
> our default (we discussed this in the other topic), so i don't think see a
> problem here.
>
>
> I understand your point about https://issues.apache.org/jira
> /browse/MYFACES-3779 but quite a lot work must be done to get this
> working and is unsure if we will ever work on something.
> Also if we would work on it, i'm sure we would have to refactor much more
> things.
>
> Also your statement
> "The key point is maybe the state saving mode has something to say about
> how the token is processed."
> says that its actually one unit.
>
> We should not over-engineer something which is maybe never required.
> maintainability > abstraction - as it's already quite hard the follow our
> code in some places.
>
>
>
>
> 2017-12-19 21:57 GMT+01:00 Leonardo Uribe <lu4...@gmail.com>:
>
>> Hi
>>
>> TA>> Yep, it's not a bug but a good improvement. Personally i would only
>> do
>> TA>> it in 2.3.
>>
>> I agree, only 2.3.
>>
>> TA>> As i already explained, i removed those classes as "sequence"
>> view-id
>> TA>> generator must not be used anymore.
>>
>> I'm confused about this term "view-id". It is similar to JSF viewId,
>> which
>> is the path of the view. Let's do some recap.
>>
>> In server side state saving we use a token. This token is composed of:
>>
>> - A session counter.
>> - viewId or related hashCode.
>> - (optional) a random number.
>>
>> In JSF 1.1 the full viewId path was saved with a sequence to be able to
>> identify the right view state in the collection. Later the viewId was
>> changed with a hash code, because the viewId was too large, and we needed
>> a smaller token.
>>
>> The idea behind a random number was the token should not be easily
>> guessed.
>> Well, it is not a requirement, since the token is mac-encoded and
>> encrypted.
>> But generate a random number is slow in some systems and JDK versions
>> (linux,
>> Sun-Oracle JDKs). That's the reason why the random number is not by
>> default,
>> because it is not possible.
>>
>> There are fast random number generators but remember, to make it safe it
>> should not be possible to guess it, well if you have plans to disable
>> encryption. So, there is an option to use a "secureRandom" number
>> generator.
>>
>> TA>> My reasons to merge both classes are that we already have a artifact
>> TA>> which handles client side state, and we alr

Re: [myfaces core] don't deserialize ViewState-ID if state saving method is server

[Leonardo Uribe]

Hi

TA>> Yep, it's not a bug but a good improvement. Personally i would only do
TA>> it in 2.3.

I agree, only 2.3.

TA>> As i already explained, i removed those classes as "sequence" view-id
TA>> generator must not be used anymore.

I'm confused about this term "view-id". It is similar to JSF viewId, which
is the path of the view. Let's do some recap.

In server side state saving we use a token. This token is composed of:

- A session counter.
- viewId or related hashCode.
- (optional) a random number.

In JSF 1.1 the full viewId path was saved with a sequence to be able to
identify the right view state in the collection. Later the viewId was
changed with a hash code, because the viewId was too large, and we needed
a smaller token.

The idea behind a random number was the token should not be easily guessed.
Well, it is not a requirement, since the token is mac-encoded and encrypted.
But generate a random number is slow in some systems and JDK versions
(linux,
Sun-Oracle JDKs). That's the reason why the random number is not by default,
because it is not possible.

There are fast random number generators but remember, to make it safe it
should not be possible to guess it, well if you have plans to disable
encryption. So, there is an option to use a "secureRandom" number generator.

TA>> My reasons to merge both classes are that we already have a artifact
TA>> which handles client side state, and we already have a artifact which
TA>> handles server side state.

TA>> Maybe "Cache" is not a 100% perfect name but it's ok IMO. We could
TA>> still search for another name, which would be a very very small
TA>> improvement. There is no reason to e.g. use a
TA>> ClientSide-StateTokenProcessor with a ServerSide-StateCache.
TA>> Thereis one big mechanism for server-side state and one for
TA>> client-side state. How to render it and how to create/restore it,
TA>> are both sides of the medal.

I can remember this issue:

https://issues.apache.org/jira/browse/MYFACES-3779
Mixed mode(Server+client) for state saving

It is a long discussion, but the point is that a mixed mode is possible.
The work done in the API was meant to go towards that goal. The state
saving algorithm is something really hard to customize. I strongly feel
StateTokenProcessor has a lot of sense. The key point is maybe the
state saving mode has something to say about how the token is processed.
In this case, the key info is tell the processor that the token must
not be serialized.

regards,

Leonardo Uribe

2017-12-19 15:21 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Yep, it's not a bug but a good improvement. Personally i would only do it
> in 2.3.
>
> As i already explained, i removed those classes as "sequence" view-id
> generator must not be used anymore.
>
> My reasons to merge both classes are that we already have a artifact which
> handles client side state, and we already have a artifact which handles
> server side state.
> Maybe "Cache" is not a 100% perfect name but it's ok IMO. We could still
> search for another name, which would be a very very small improvement.
> There is no reason to e.g. use a ClientSide-StateTokenProcessor with a
> ServerSide-StateCache.
> Thereis one big mechanism for server-side state and one for client-side
> state. How to render it and how to create/restore it, are both sides of the
> medal.
>
>
>
> 2017-12-19 21:09 GMT+01:00 Leonardo Uribe <lu4...@gmail.com>:
>
>> Hi
>>
>> There are some changes in MYFACES-4133 (2.3.x branch) that is required to
>> be
>> discussed on dev list and not on jira.
>>
>> MYFACES-4133 is all about refactor the existing state API to avoid the
>> java
>> token serialization. I have already stated this is an improvement, not a
>> bug,
>> but since there is a lot of interest in this point I would like to expose
>> the
>> ideas behind the existing API.
>>
>> The change proposed removes these classes:
>>
>> StateTokenProcessor
>> IntIntSerializedViewKey
>> CounterSessionViewStorageFactory
>> IntByteArraySerializedViewKey
>> CounterKeyFactory
>>
>> And the addition of some methods in StateCache:
>>
>> public abstract Object decodeStateToken(FacesContext facesContext, String
>> token);
>> public abstract String encodeStateToken(FacesContext facesContext, Object
>> savedStateObject);
>> public boolean isStatelessToken(FacesContext facesContext, String token)
>>
>> The first problem here is StateCache abstraction.
>>
>> "... provides an interface to separate the state caching operations
>> (saving/restoring) from the renderkit specific stuff that
>

[myfaces core] don't deserialize ViewState-ID if state saving method is server

[Leonardo Uribe]

Hi

There are some changes in MYFACES-4133 (2.3.x branch) that is required to
be
discussed on dev list and not on jira.

MYFACES-4133 is all about refactor the existing state API to avoid the java
token serialization. I have already stated this is an improvement, not a
bug,
but since there is a lot of interest in this point I would like to expose
the
ideas behind the existing API.

The change proposed removes these classes:

StateTokenProcessor
IntIntSerializedViewKey
CounterSessionViewStorageFactory
IntByteArraySerializedViewKey
CounterKeyFactory

And the addition of some methods in StateCache:

public abstract Object decodeStateToken(FacesContext facesContext, String
token);
public abstract String encodeStateToken(FacesContext facesContext, Object
savedStateObject);
public boolean isStatelessToken(FacesContext facesContext, String token)

The first problem here is StateCache abstraction.

"... provides an interface to separate the state caching operations
(saving/restoring) from the renderkit specific stuff that
HtmlResponseStateManager should do. ..."

Token serialization is HtmlResponseStateManager stuff, specifically related
to
the render step.

StateTokenProcessor was deleted but this interface had the following
methods:

public abstract Object decode(FacesContext facesContext, String token);
public abstract String encode(FacesContext facesContext, Object
savedStateObject);
public abstract boolean isStateless(FacesContext facesContext, String
token);

My first question is what's the reason of merge StateTokenProcessor and
StateCache? What's the advantage?

Well, I can see one, StateCache has a logic related to client-server state
saving.
Server side state saving uses a counter as token, client side state saving
encodes the view state inside the token.

But still I think StateTokenProcessor has life on its own. Am I missing
something?

regards,

Leonardo Uribe

[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)

Re: Dev Discussion - JSF 2.3 ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY different between MyFaces and Mojarra

[Leonardo Uribe]

Hi

I think MyFaces behavior is correct here. The reason is you will never add
views inside META-INF or WEB-INF folders, but you could add templates
there. But a template is not a view. That is what I understand with "top
level views".

regards,

Leonardo Uribe

2017-11-23 19:41 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> I think we should align myfaces here. A issue + patch would be great.
>
>
> Am Samstag, 18. November 2017 schrieb Paul Nicolucci :
>
>> The javadoc for ResourceVisitOption.html says the following:
>> https://javaee.github.io/javaee-spec/javadocs/javax/faces/
>> application/ResourceVisitOption.html
>>
>> public static final *ResourceVisitOption*
>> <https://javaee.github.io/javaee-spec/javadocs/javax/faces/application/ResourceVisitOption.html>
>>  TOP_LEVEL_VIEWS_ONLY
>> Only visit resources that are top level views, i.e. views that can be
>> used to serve a request as opposed to those that can only be used for
>> includes.
>>
>> Thanks,
>>
>> Paul Nicolucci
>>
>>
>> [image: Inactive hide details for Thomas Andraschko ---11/18/2017
>> 07:22:32 AM---Did you checked the spec texts? 2017-11-17 19:56 GMT+01]Thomas
>> Andraschko ---11/18/2017 07:22:32 AM---Did you checked the spec texts?
>> 2017-11-17 19:56 GMT+01:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>
>> From: Thomas Andraschko <andraschko.tho...@gmail.com>
>> To: MyFaces Development <dev@myfaces.apache.org>
>> Date: 11/18/2017 07:22 AM
>> Subject: Re: Dev Discussion - JSF 2.3 
>> ResourceVisitOption.TOP_LEVEL_VIEWS_ONLY
>> different between MyFaces and Mojarra
>> --
>>
>>
>>
>> Did you checked the spec texts?
>>
>> 2017-11-17 19:56 GMT+01:00 Paul Nicolucci <*pnico...@us.ibm.com*>:
>>
>>Hello,
>>
>>I was testing out the ResourceHandler.getViewResources() today and I
>>noticed that we have quite a behavior different between the two
>>implementations.
>>
>>Take the following application for example:
>>
>>testApplication
>>- /depth2/index.xhtml
>>-META-INF/index.xhtml
>>-WEB-INF/index.xhtml
>>- index.xhtml
>>- test
>>
>>Mojarra getViewResources( call with ResourceVisitOptions )
>>/index.xhtml /depth2/index.xhtml
>>
>>Mojarra getViewResources ( call without ResourceVisitOptions )
>>/index.xhtml /depth2/index.xhtml META-INF/index.xhtml
>>WEB-INF/index.xhtml
>>
>>MyFaces getViewResources( call with ResourceVisitOptions )
>>/index.xhtml /depth2/index.xhtml
>>
>>MyFaces getViewResources( call without ResourceVisitOptions )
>>/index.xhtml /test /depth2/index.xhtml
>>
>>In MyFaces if we use the ResourceVisitOptions then we filter out any
>>views that don't contain a valid suffix ( in the above case /test ). In
>>addition MyFaces never returns any views in WEB-INF and META-INF
>>
>>In Mojarra if we use the ResourceVisitOptions then anything in
>>WEB-INF and META-INF is not included. In addition Mojarra never returns 
>> any
>>views without a valid suffix.
>>
>>I think we need a dev discussion to determine if we want to stick
>>with our current behavior or change it.
>>
>>Thanks,
>>
>>Paul Nicolucci
>>
>>
>>
>>

[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<Object, Object>] 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)

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

[Leonardo Uribe]

+1 for ignore. @ResolveComponent is still the closest solution we could
have. That is MyFaces Core specific feature, at least in my mind.

2017-09-01 14:08 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> +1 for ignoring it for now and open a spec issue
>
>
> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>
>> @leo:
>>
>> as i said: "...we have a spec. issue here..."
>> if we have to follow it, we need to use @Dependent.
>>
>> if there isn't a tck-test for it, we could even ignore the written spec.
>> (that isn't nice, but mojarra is also doing it in some cases...).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:
>>
>>> Hi
>>>
>>> Use producers won't work. The reason? it is necessary to create a proper
>>> proxy for that injection. It is a bug in the spec, the intention was never
>>> that, and the suggestion proposed for inject components was not included.
>>>
>>> Keep it simple, use el-resolver for that always.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2017-09-01 12:41 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:
>>>
>>>> hi paul,
>>>>
>>>> yes - imo it's the only useful alternative since the spec. prohibits
>>>> the implementation via el-resolver (for whatever reason...).
>>>> (at least there isn't an approach without issues.)
>>>>
>>>> + imo we should consider a config-parameter to activate the el-resolver
>>>> in any case...
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>>>
>>>>> Hi Gerhard,
>>>>>
>>>>> Thanks for the clarification. So you think MyFaces should use
>>>>> @Dependent instead of @FacesScoped and then document to ensure users are
>>>>> aware of the pitfalls of it?
>>>>>
>>>>> This seems to allow us to abide by the specification as well as
>>>>> educate our users.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Paul Nicolucci
>>>>>
>>>>> [image: Inactive hide details for Gerhard Petracek ---09/01/2017
>>>>> 11:43:28 AM---hi paul, in this (unfortunate) case the only (simple) 
>>>>> op]Gerhard
>>>>> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case
>>>>> the only (simple) option is a producer-method
>>>>>
>>>>> From: Gerhard Petracek <gpetra...@apache.org>
>>>>> To: MyFaces Development <dev@myfaces.apache.org>
>>>>> Date: 09/01/2017 11:43 AM
>>>>>
>>>>> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>>>>> FacesScopeObjectProducer
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>> hi paul,
>>>>>
>>>>> in this (unfortunate) case the only (simple) option is a
>>>>> producer-method with @Dependent instead of @FacesScoped (which doesn't 
>>>>> make
>>>>> sense at all).
>>>>> + we have to document that users have to be careful (if they believe
>>>>> that they need to use it).
>>>>> i still don't really see the use-case outside the context of the
>>>>> component itself and artifacts like validators have access to the current
>>>>> component anyway.
>>>>>
>>>>> regards,
>>>>> gerhard
>>>>>
>>>>>
>>>>>
>>>>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnico...@us.ibm.com*>:
>>>>>
>>>>>It looks like the JSF 2.3 spec says the following about this:
>>>>>
>>>>>5.6.3 CDI for EL Resolution
>>>>>If the any of the managed beans in the application have the
>>>>>@javax.faces.annotation.FacesConfig
>>>>>annotation, the ImplicitObjectELResolver from Section 5.6.2.1
>>>>>“Implicit Object ELResolver for Facelets and
>>>>>Programmatic Access” is not present in the chain. Instead, CDI is
>>>>>used to perform EL resolution in the same manner is
>>>>>in Section TABLE 5-11 “Implici

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

[Leonardo Uribe]

Hi Gerhard

It was a point discussed in the EG mailing list. @Dependent doesn't work
because it means there is no proper proxy, and you need one that isolates
the bean from the component.

regards,

Leonardo Uribe

2017-09-01 13:37 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:

> @leo:
>
> as i said: "...we have a spec. issue here..."
> if we have to follow it, we need to use @Dependent.
>
> if there isn't a tck-test for it, we could even ignore the written spec.
> (that isn't nice, but mojarra is also doing it in some cases...).
>
> regards,
> gerhard
>
>
>
> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:
>
>> Hi
>>
>> Use producers won't work. The reason? it is necessary to create a proper
>> proxy for that injection. It is a bug in the spec, the intention was never
>> that, and the suggestion proposed for inject components was not included.
>>
>> Keep it simple, use el-resolver for that always.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2017-09-01 12:41 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:
>>
>>> hi paul,
>>>
>>> yes - imo it's the only useful alternative since the spec. prohibits the
>>> implementation via el-resolver (for whatever reason...).
>>> (at least there isn't an approach without issues.)
>>>
>>> + imo we should consider a config-parameter to activate the el-resolver
>>> in any case...
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>>
>>>> Hi Gerhard,
>>>>
>>>> Thanks for the clarification. So you think MyFaces should use
>>>> @Dependent instead of @FacesScoped and then document to ensure users are
>>>> aware of the pitfalls of it?
>>>>
>>>> This seems to allow us to abide by the specification as well as educate
>>>> our users.
>>>>
>>>> Regards,
>>>>
>>>> Paul Nicolucci
>>>>
>>>> [image: Inactive hide details for Gerhard Petracek ---09/01/2017
>>>> 11:43:28 AM---hi paul, in this (unfortunate) case the only (simple) 
>>>> op]Gerhard
>>>> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case
>>>> the only (simple) option is a producer-method
>>>>
>>>> From: Gerhard Petracek <gpetra...@apache.org>
>>>> To: MyFaces Development <dev@myfaces.apache.org>
>>>> Date: 09/01/2017 11:43 AM
>>>>
>>>> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>>>> FacesScopeObjectProducer
>>>> --
>>>>
>>>>
>>>>
>>>> hi paul,
>>>>
>>>> in this (unfortunate) case the only (simple) option is a
>>>> producer-method with @Dependent instead of @FacesScoped (which doesn't make
>>>> sense at all).
>>>> + we have to document that users have to be careful (if they believe
>>>> that they need to use it).
>>>> i still don't really see the use-case outside the context of the
>>>> component itself and artifacts like validators have access to the current
>>>> component anyway.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnico...@us.ibm.com*
>>>> <pnico...@us.ibm.com>>:
>>>>
>>>>It looks like the JSF 2.3 spec says the following about this:
>>>>
>>>>5.6.3 CDI for EL Resolution
>>>>If the any of the managed beans in the application have the
>>>>@javax.faces.annotation.FacesConfig
>>>>annotation, the ImplicitObjectELResolver from Section 5.6.2.1
>>>>“Implicit Object ELResolver for Facelets and
>>>>Programmatic Access” is not present in the chain. Instead, CDI is
>>>>used to perform EL resolution in the same manner is
>>>>in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>>Access” with the following additional implicit
>>>>objects:
>>>>? externalContext
>>>>? the current ExternalContext from the current FacesContext
>>>>
>>>>This to me means that if you have the @FacesConfig annotation in
>>>>your app the Implicit ELResolver is not available and we need to use 
>>>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

[Leonardo Uribe]

Hi

Use producers won't work. The reason? it is necessary to create a proper
proxy for that injection. It is a bug in the spec, the intention was never
that, and the suggestion proposed for inject components was not included.

Keep it simple, use el-resolver for that always.

regards,

Leonardo Uribe

2017-09-01 12:41 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:

> hi paul,
>
> yes - imo it's the only useful alternative since the spec. prohibits the
> implementation via el-resolver (for whatever reason...).
> (at least there isn't an approach without issues.)
>
> + imo we should consider a config-parameter to activate the el-resolver in
> any case...
>
> regards,
> gerhard
>
>
>
> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:
>
>> Hi Gerhard,
>>
>> Thanks for the clarification. So you think MyFaces should use @Dependent
>> instead of @FacesScoped and then document to ensure users are aware of the
>> pitfalls of it?
>>
>> This seems to allow us to abide by the specification as well as educate
>> our users.
>>
>> Regards,
>>
>> Paul Nicolucci
>>
>> [image: Inactive hide details for Gerhard Petracek ---09/01/2017 11:43:28
>> AM---hi paul, in this (unfortunate) case the only (simple) op]Gerhard
>> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case
>> the only (simple) option is a producer-method
>>
>> From: Gerhard Petracek <gpetra...@apache.org>
>> To: MyFaces Development <dev@myfaces.apache.org>
>> Date: 09/01/2017 11:43 AM
>>
>> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>> FacesScopeObjectProducer
>> --
>>
>>
>>
>> hi paul,
>>
>> in this (unfortunate) case the only (simple) option is a producer-method
>> with @Dependent instead of @FacesScoped (which doesn't make sense at all).
>> + we have to document that users have to be careful (if they believe that
>> they need to use it).
>> i still don't really see the use-case outside the context of the
>> component itself and artifacts like validators have access to the current
>> component anyway.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnico...@us.ibm.com*
>> <pnico...@us.ibm.com>>:
>>
>>It looks like the JSF 2.3 spec says the following about this:
>>
>>5.6.3 CDI for EL Resolution
>>If the any of the managed beans in the application have the
>>@javax.faces.annotation.FacesConfig
>>annotation, the ImplicitObjectELResolver from Section 5.6.2.1
>>“Implicit Object ELResolver for Facelets and
>>Programmatic Access” is not present in the chain. Instead, CDI is
>>used to perform EL resolution in the same manner is
>>in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>Access” with the following additional implicit
>>objects:
>>? externalContext
>>? the current ExternalContext from the current FacesContext
>>
>>This to me means that if you have the @FacesConfig annotation in your
>>app the Implicit ELResolver is not available and we need to use CDI to
>>perform the implicit object lookup. So I don't think we can depend on the
>>ELResolver in this instance.
>>
>>Regards,
>>
>>Paul Nicolucci
>>
>>
>>[image: Inactive hide details for Gerhard Petracek ---09/01/2017
>>09:17:05 AM---yes - there are some cases which would break with 
>> interf]Gerhard
>>Petracek ---09/01/2017 09:17:05 AM---yes - there are some cases which 
>> would
>>break with interface-proxies and some with subclass-proxies.
>>
>>From: Gerhard Petracek <*gpetra...@apache.org* <gpetra...@apache.org>>
>>To: MyFaces Development <*dev@myfaces.apache.org*
>><dev@myfaces.apache.org>>
>>Date: 09/01/2017 09:17 AM
>>Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>>FacesScopeObjectProducer
>>--
>>
>>
>>
>>
>>yes - there are some cases which would break with interface-proxies
>>and some with subclass-proxies. subclass-proxies would just support the
>>instanceof checks used by some component-libraries, but would only work if
>>just the resolved instance but not the type of the resolved instance would
>>change (per dependent-scoped subclass-proxy instance).
>>
>>-> therefore i (still) prefer the el-resolver (if possible).
>

[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)

Re: JDK requirements for Tobago 4

[Leonardo Uribe]

Hi

No objections from my side. JSF 2.3 is already Java 8, and there are no
known issues running 2.2 or earlier versions in Java 8.

regards,

Leonardo Uribe

2017-06-29 3:59 GMT-05:00 Udo Schnurpfeil <lof...@apache.org>:

> Hi,
>
> I would like to set the JDK requirements to Java 8 or higher for Tobago
> 4 (next major release). Any objections?
>
> Regards
>
> Udo
>

[ANNOUNCE] MyFaces Core v2.3.0-beta Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.3.0-beta.

MyFaces Core is a JavaServer(tm) Faces 2.3 implementation as specified by
JSR-372.

MyFaces Core 2.3.0-beta is available in both binary and source
distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.3.0-beta

Sub-task

[MYFACES-4092] - Implement CDI extension for @FacesDataModel
[MYFACES-4093] - Implement CDI extension for @FacesConverter
[MYFACES-4094] - Implement CDI extension for @FacesValidator
[MYFACES-4095] - Implement CDI extension for @FacesBehavior
[MYFACES-4096] - Implement CDI extension for @ManagedProperty
[MYFACES-4097] - Implement CDI changes for @FacesConfig

Bug

[MYFACES-3644] - cleanup ViewState handling
[MYFACES-4104] - Update plugins to compile java 8 code in JSF 2.3 branch
[MYFACES-4105] - Implement extensionless mapping of views
[MYFACES-4107] - StringIndexOutOfBoundsException in getResourceVersion
[MYFACES-4117] - No default name for @FacesComponent with
createTag=true and no tagName
[MYFACES-4119] - Disposal method from PushContextFactoryBean is missing
@Push annotation

Improvement

[MYFACES-4099] - Allow resolve #{cc} inside templates called from a
composite component
[MYFACES-4102] - Check improvements in FlowHandler for JSF 2.3

New Feature

[MYFACES-4069] - Implement f:websocket and related api
[MYFACES-4070] - Implement h:commandScript and related api
[MYFACES-4071] - Implement dynamic resource loading in ajax requests
[MYFACES-4075] - SearchExpression API
[MYFACES-4078] - Expose StateCacheFactory/StateCache as a SPI service
[MYFACES-4079] - Implement CDI changes for JSF 2.3
[MYFACES-4083] - Add copy constructor to wrappers
[MYFACES-4084] - Implement f:importConstants
[MYFACES-4085] - Constants for "jsf.js", "javax.faces" and postback
parameters
[MYFACES-4086] - Deprecate native managed beans annotations
[MYFACES-4087] - Add PostRenderViewEvent
[MYFACES-4088] - Add constructor with facesContext to event classes
[MYFACES-4089] - Add Iterable support in UIData and UIRepeat
[MYFACES-4090] - Add Map support in UIData and UIRepeat
[MYFACES-4091] - Add custom type support in UIData and UIRepeat
[MYFACES-4098] - Implement ResourceHandler.getViewResources(...)
[MYFACES-4101] - Implement f:importConstants
[MYFACES-4103] - Implement ViewHandler.getViews(...)
[MYFACES-4106] - Implement ResourceHandler.markResourceRendered(...)
and ResourceHandler.isResourceRendered(...)
[MYFACES-4108] - Implement FaceletCache.setCacheFactories(...)
[MYFACES-4109] - Implement f:validateWholeBean
[MYFACES-4110] - Implement javax.faces.model.IterableDataModel
[MYFACES-4111] - Implement h:column styleClass property
[MYFACES-4112] - Implement h:dataTable rowClass
[MYFACES-4113] - Implement h:panelGrid rowClass
[MYFACES-4115] - Implement h:selectOneRadio "group" (distributed radio
button)
[MYFACES-4116] - Implement JDK 8 time support in f:convertDateTime
[MYFACES-4118] - Implement new changes of javax.faces.ViewState update
on ajax for multiple forms

Task

[MYFACES-4121] - Fix javadoc for 2.3 branch and update
maven-javadoc-plugin

regards,

Leonardo Uribe

Re: Missing announce mails

[Leonardo Uribe]

Hi

In myfaces core 2.3.0-beta the artifacts are ready, so they were deployed
to maven repo and dist, but we need to update the site before the announce
email. It will take some time.

regards,

Leonardo Uribe

2017-06-26 7:56 GMT-05:00 Bernd Bohmann <bernd.bohm...@atanion.com>:

> :-) it's on my long list for trinidad
>
> Regards
>
> Bernd
>
> On Mon, Jun 26, 2017 at 2:51 PM, Dennis Kieselhorst <d...@apache.org>
> wrote:
>
>> Hi,
>>
>> are we no longer sending announce mails?
>>
>> The last releases for Trinidad, Tobago and MyFaces Core (beta) are
>> available on central but no announcement was send :-(
>>
>> Regards
>> Dennis
>>
>
>

Re: [VOTE] Checkstyle Rules version 8 (2nd try)

[Leonardo Uribe]

+1

2017-06-18 14:44 GMT-05:00 Bernd Bohmann :

> Here is my +1
>
> Regards
>
> Bernd
>
> On Sat, Jun 17, 2017 at 5:30 PM, Dennis Kieselhorst 
> wrote:
>
>> +1
>>
>
>

Result (Was: [VOTE] release of MyFaces Core 2.3.0-beta)

[Leonardo Uribe]

Hi

Thanks to all people who vote.

We have 6 +1

Udo Schnurpfeil
Thomas Andraschko
Paul Nicolucci
Bill Lucy
Leonardo Uribe
Mustafa Agâh Öztürk (non binding)

so we can continue with the necessary steps to release MyFaces Core
2.3.0-beta

regards,

Leonardo Uribe

Re: [VOTE] release of MyFaces Core 2.3.0-beta

[Leonardo Uribe]

Hi

We need an extra +1 from a PMC member in order to continue with the beta
release. Someone who likes to review the bits?

regards,

Leonardo Uribe

2017-06-10 6:15 GMT-05:00 Paul Nicolucci <pnico...@us.ibm.com>:

> +1
>
> Regards,
>
> Paul Nicolucci
>
>
> [image: Inactive hide details for Bill Lucy ---06/09/2017 11:25:45 AM---+1
> - the progress looks great! Bill]Bill Lucy ---06/09/2017 11:25:45 AM---+1
> - the progress looks great! Bill
>
> From: Bill Lucy <wtl...@gmail.com>
> To: MyFaces Development <dev@myfaces.apache.org>
> Date: 06/09/2017 11:25 AM
> Subject: Re: [VOTE] release of MyFaces Core 2.3.0-beta
> --
>
>
>
> +1 - the progress looks great!
>
> Bill
>
> On Fri, Jun 9, 2017 at 1:41 AM, Mustafa Agâh Öztürk <*maozt...@msn.com*
> <maozt...@msn.com>> wrote:
>
>+1 from me.
>
>
>On 06/09/2017 04:30 AM, Leonardo Uribe wrote:
>+1
>
>  2017-06-08 20:30 GMT-05:00 Leonardo Uribe <*lu4...@gmail.com*
>  <lu4...@gmail.com>>:
>  Hi,
>
>  I was running the needed tasks to get the 2.3.0-beta release of
>  Apache
>  MyFaces core out.
>
>
>  Please note that this vote concerns all of the following parts:
>   1. Maven artifact group "org.apache.myfaces.core" v2.3.0-beta
>  [1]
>
>  The artifacts were deployed on nexus repo [1] for binary and
>  source packages.
>
>  The release notes could be found at [4].
>
>  Also the clirr test does not show binary incompatibilities with
>  myfaces-api.
>
>  Please take a look at the "2.3.0-beta" artifacts and vote!
>
>  Please note: This vote is "majority approval" with a minimum of
>  three
>  +1 votes (see [3]).
>
>  
>  [ ] +1 for community members who have reviewed the bits
>  [ ] +0
>  [ ] -1 for fatal flaws that should cause these bits not to be
>  released,
>   and why..
>  
>
>  Thanks,
>  Leonardo Uribe
>
>  [1]
>  
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1109/org/apache/myfaces/*
>  
> <https://repository.apache.org/content/repositories/orgapachemyfaces-1109/org/apache/myfaces/>
>  [2] *http://www.apache.org/foundation/voting.html#ReleaseVotes*
>  <http://www.apache.org/foundation/voting.html#ReleaseVotes>
>  [3]
>  
> *https://repository.apache.org/content/repositories/orgapachemyfaces-1109/org/apache/myfaces/core/myfaces-core-assembly/*
>  
> <https://repository.apache.org/content/repositories/orgapachemyfaces-1109/org/apache/myfaces/core/myfaces-core-assembly/>
>  [4]
>  
> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12340857*
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12340857>
>
>
>
>
>
>

Re: [VOTE] release of MyFaces Core 2.3.0-beta

[Leonardo Uribe]

+1

2017-06-08 20:30 GMT-05:00 Leonardo Uribe <lu4...@gmail.com>:

> Hi,
>
> I was running the needed tasks to get the 2.3.0-beta release of Apache
> MyFaces core out.
>
>
> Please note that this vote concerns all of the following parts:
>  1. Maven artifact group "org.apache.myfaces.core" v2.3.0-beta  [1]
>
> The artifacts were deployed on nexus repo [1] for binary and source
> packages.
>
> The release notes could be found at [4].
>
> Also the clirr test does not show binary incompatibilities with
> myfaces-api.
>
> Please take a look at the "2.3.0-beta" artifacts and vote!
>
> Please note: This vote is "majority approval" with a minimum of three
> +1 votes (see [3]).
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released,
>  and why..
> 
>
> Thanks,
> Leonardo Uribe
>
> [1] https://repository.apache.org/content/repositories/
> orgapachemyfaces-1109/org/apache/myfaces/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3] https://repository.apache.org/content/repositories/
> orgapachemyfaces-1109/org/apache/myfaces/core/myfaces-core-assembly/
> [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=10600=12340857
>

[VOTE] release of MyFaces Core 2.3.0-beta

[Leonardo Uribe]

Hi,

I was running the needed tasks to get the 2.3.0-beta release of Apache
MyFaces core out.


Please note that this vote concerns all of the following parts:
 1. Maven artifact group "org.apache.myfaces.core" v2.3.0-beta  [1]

The artifacts were deployed on nexus repo [1] for binary and source
packages.

The release notes could be found at [4].

Also the clirr test does not show binary incompatibilities with myfaces-api.

Please take a look at the "2.3.0-beta" artifacts and vote!

Please note: This vote is "majority approval" with a minimum of three
+1 votes (see [3]).


[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released,
 and why..
----

Thanks,
Leonardo Uribe

[1]
https://repository.apache.org/content/repositories/orgapachemyfaces-1109/org/apache/myfaces/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3]
https://repository.apache.org/content/repositories/orgapachemyfaces-1109/org/apache/myfaces/core/myfaces-core-assembly/
[4]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12340857

[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)

Result (Was: [VOTE] release of MyFaces Test 1.0.8 )

[Leonardo Uribe]

Hi

Thanks to all people who vote.

We have 5 +1

Udo Schnurpfeil
Volker Weber
Thomas Andraschko
Dennis Kieselhorst
Leonardo Uribe

so we can continue with the necessary steps to release MyFaces Test 1.0.8
(and start MyFaces Core 2.3.0-beta release process).

regards,

Leonardo Uribe

Re: [VOTE] release of MyFaces Test 1.0.8

[Leonardo Uribe]

Hi

I checked the assemblies and source-release and they are ok. MyFaces Test
release includes test12, test20, test22 and test23.

regards,

Leonardo Uribe

2017-05-26 16:07 GMT-05:00 Dennis Kieselhorst <d...@apache.org>:

> The artifactId in unpack-sources profile should be myfaces-test23 and not
> myfaces-test22, shouldn't it?
>
> Regards
> Dennis
>

[VOTE] release of MyFaces Test 1.0.8

[Leonardo Uribe]

Hi,

I was running the needed tasks to get the 1.0.8 release of Apache
MyFaces Test out.

Note these artifacts are necessary to start the release of
Myfaces Core 2.3.0-beta.

Please note that this vote concerns all of the following parts:
 1. Maven artifact group "org.apache.myfaces.test" v1.0.8  [1]

The artifacts are deployed to nexus repository [1] for binary
and source packages.

The release notes could be found at [4].

Please take a look at the "1.0.8" artifacts and vote!

Please note: This vote is "majority approval" with a minimum of three
+1 votes (see [3]).


[ ] +1 for community members who have reviewed the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be released,
 and why..
----

Thanks,
Leonardo Uribe

[1] 
https://repository.apache.org/content/repositories/orgapachemyfaces-1108/org/apache/myfaces/test/

https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] 
https://repository.apache.org/content/repositories/orgapachemyfaces-1108/org/apache/myfaces/test/myfaces-test-assembly/
[4] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951=12340630

Re: [VOTE] release of MyFaces Test 1.0.8

[Leonardo Uribe]

+1

2017-05-25 23:37 GMT-05:00 Leonardo Uribe <lu4...@gmail.com>:

> Hi,
>
> I was running the needed tasks to get the 1.0.8 release of Apache
> MyFaces Test out.
>
> Note these artifacts are necessary to start the release of
> Myfaces Core 2.3.0-beta.
>
> Please note that this vote concerns all of the following parts:
>  1. Maven artifact group "org.apache.myfaces.test" v1.0.8  [1]
>
> The artifacts are deployed to nexus repository [1] for binary
> and source packages.
>
> The release notes could be found at [4].
>
> Please take a look at the "1.0.8" artifacts and vote!
>
> Please note: This vote is "majority approval" with a minimum of three
> +1 votes (see [3]).
>
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be released,
>  and why..
> 
>
> Thanks,
> Leonardo Uribe
>
> [1] 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1108/org/apache/myfaces/test/
> 
> https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3] 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1108/org/apache/myfaces/test/myfaces-test-assembly/
> [4] 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951=12340630
>
>

[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)

Re: org.apache.myfaces.shade packages in JSF 2.3

[Leonardo Uribe]

Hi

The code in core/branches/2.3.x is a working prototype of JSF 2.3 spec. It
is ready for a beta release, after a release of MyFaces Test.

We haven't discussed anything about add commons-codec dependency and remove
shade package. But this is a good moment to say something about it.

MYFACES-4005 was something done on the way to fix an issue, but in my
opinion update commons-codec and remove shade package has sense, at least
for 2.3.

regards,

Leonardo Uribe

2017-05-25 13:11 GMT-05:00 Paul Nicolucci <pnico...@us.ibm.com>:

> Hi,
>
> I noticed in the latest JSF 2.3 code base we still have the
> org.apache.myfaces.shade packages that were added here:
> https://issues.apache.org/jira/browse/MYFACES-4005
>
> Do we plan to remove this and update the commons-codec dependency in jsf
> 2.3? I looked quick to see if there was a JIRA for this but I didn't see it
> so wanted to check in
> and see if I should open one or if it was being addressed someplace else.
>
> Thanks,
>
> Paul
>

[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)

Only 3 Issues Left for MyFaces 2.3.0-beta release

[Leonardo Uribe]

Hi

I just wanted to point out that every major feature in JSF 2.3 has already
been implemented and there are only 3 issues left.

MYFACES-4078 Expose StateCacheFactory/StateCache as a SPI service
MYFACES-4102 Check improvements in FlowHandler for JSF 2.3
MYFACES-4097 Implement CDI changes for @FacesConfig

This means a beta release will be done very soon.

regards,

Leonardo Uribe

[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)

Re: [VOTE] Release of MyFaces Trinidad 2.2.0

[Leonardo Uribe]

+1

2017-05-01 13:47 GMT-05:00 Dennis Kieselhorst :

> +1
>
> Just noticed that trinidad-assembly contains duplicated artifacts and
> opened an issue for it: https://issues.apache.org/
> jira/browse/TRINIDAD-2554
>

Re: [VOTE] Release of MyFaces Trinidad 2.1.3

[Leonardo Uribe]

+1

2017-05-01 13:39 GMT-05:00 Dennis Kieselhorst :

> +1
>

[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)