[jira] [Commented] (MYFACES-4318) c:forEach problem with client side state saving
[ https://issues.apache.org/jira/browse/MYFACES-4318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > or
Re: MYFACES-4244 Discussion
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
[ 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
[ https://issues.apache.org/jira/browse/MYFACES-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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 : > 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 : > >> 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
+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
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 : > 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 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 : >> >>> 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) >>> >>> ... 25 more >>> >>
Re: Questions about MyFaces 2.3.0 release
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 : > 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 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 >> 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/tobago/scripts/release-artifacts.sh >>
Re: Questions about MyFaces 2.3.0 release
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 : > 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 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 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 : >>> >>>> 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 >>>>> > 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
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 : > 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 > : > >> 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 >>> 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
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 : > 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 >> 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
Hi 2018-02-16 16:17 GMT-05:00 Eduardo B : > 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?
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 : > 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 : >> >>> 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
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 : > 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 : > >> 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 : >> >>> 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 >> >: >>> >>>> 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 : >>>> >>>>> 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
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 : > 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 : > >> 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 : >> >>> 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
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 : > 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 : > >> 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
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 : > 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 : > >> 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 > >: >> >>> 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 : >>> >>>> Hi
Re: [myfaces core] don't deserialize ViewState-ID if state saving method is server
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 : > 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 : > >> 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, an
Re: [myfaces core] don't deserialize ViewState-ID if state saving method is server
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 : > 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 : > >> 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 sh
[myfaces core] don't deserialize ViewState-ID if state saving method is server
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
[ https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/MYFACES-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
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 : > 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 : >> >> From: Thomas Andraschko >> To: MyFaces Development >> 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
[ https://issues.apache.org/jira/browse/MYFACES-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16159495#comment-16159495 ] Leonardo Uribe commented on MYFACES-4127: - It is possible to use a dynamic producer but it requires copy/paste some code that is already in MyFaces codebase. > Unexpected exception thrown when FlowMap is injected on a RequestScoped bean > > > Key: MYFACES-4127 > URL: https://issues.apache.org/jira/browse/MYFACES-4127 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Eduardo Breijo > Assignee: Leonardo Uribe >Priority: Minor > Fix For: 2.3.0 > > Attachments: ConfigItems.java, ELImplicitObjectsViaCDI.war, > ELImplicitObjectsViaCDI.war.zip > > > When @FlowMap is injected on a RequestScoped bean, and you try to use that > object (which should be null since we are not inside of a flow), an > unexpected exception is thrown. This was noted after JIRA issue: > https://issues.apache.org/jira/browse/MYFACES-4126 > Caused by: org.jboss.weld.exceptions.IllegalProductException: WELD-52: > Cannot return null from a non-dependent producer method: Producer for > Producer Method [Map] with qualifiers [@FlowMap @Any] > declared as [[UnbackedAnnotatedMethod] @Produces @FlowMap @ApplicationScoped > public > org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap()] > declared on Managed Bean [class > org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer] with qualifiers > [@Any @Default] > at > org.apache.myfaces.cdi.faces.ApplicationScopeObjectProducer.getFlowMap(ApplicationScopeObjectProducer.java:73) > StackTrace: > at > org.jboss.weld.bean.AbstractProducerBean.checkReturnValue(AbstractProducerBean.java:136) > at [internal classes] > at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) > at > org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100) > at [internal classes] > at java.lang.String.valueOf(String.java:2994) > at java.lang.StringBuilder.append(StringBuilder.java:131) > at > com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163) > On Mojarra 2.3, we get a different exception which looks more appropriate. > org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active > contexts for scope type javax.faces.flow.FlowScoped > > org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:623) > > org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89) > > org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) > > org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87) > > org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) > > org.jboss.weld.util.Map$1302817811$Proxy$_$$_WeldClientProxy.toString(Unknown > Source) > java.lang.String.valueOf(String.java:2994) > java.lang.StringBuilder.append(StringBuilder.java:131) > > com.ibm.ws.jsf23.fat.beans.ELImplicitObjectBean.execute(ELImplicitObjectBean.java:163) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer
+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 : > +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 : >> >>> 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 : >>> >>>> 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 : >>>> >>>>> 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 >>>>> To: MyFaces Development >>>>> 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 “ImplicitObjectELResolver for Programmatic >>>>>Access” with the following additional implicit >>>>>objects:
Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer
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 : > @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 : > >> 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 : >> >>> 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 : >>> >>>> 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 >>>> To: MyFaces Development >>>> 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 “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 >>>>
Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer
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 : > 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 : > >> 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 >> To: MyFaces Development >> 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 “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* > >>To: MyFaces Development <*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). >> >>please notice that even dependent-scoped beans can cause side-effects >>here (depending on the scope of the instance which stores such a >>
[jira] [Commented] (MYFACES-4082) Composite binding don't works ...
[ https://issues.apache.org/jira/browse/MYFACES-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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 : > 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
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
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 : > :-) it's on my long list for trinidad > > Regards > > Bernd > > On Mon, Jun 26, 2017 at 2:51 PM, Dennis Kieselhorst > 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)
+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)
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
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 : > +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 > To: MyFaces Development > 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* > > 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* > >: > 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&version=12340857* > > <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12340857> > > > > > >
Re: [VOTE] release of MyFaces Core 2.3.0-beta
+1 2017-06-08 20:30 GMT-05:00 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&version=12340857 >
[VOTE] release of MyFaces Core 2.3.0-beta
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&version=12340857
[jira] [Commented] (MYFACES-4120) ResourceHandler#markResourceRendered() should be retained during ajax rebuild
[ https://issues.apache.org/jira/browse/MYFACES-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/MYFACES-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 )
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
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 : > 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
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&version=12340630
Re: [VOTE] release of MyFaces Test 1.0.8
+1 2017-05-25 23:37 GMT-05:00 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&version=12340630 > >
[jira] [Updated] (MYFACES-4119) Disposal method from PushContextFactoryBean is missing @Push annotation
[ 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
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 : > 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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 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)
[ https://issues.apache.org/jira/browse/MYFACES-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ 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)
[ https://issues.apache.org/jira/browse/MYFACES-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/MYFACES-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/TOBAGO-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
+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
+1 2017-05-01 13:39 GMT-05:00 Dennis Kieselhorst : > +1 >
[jira] [Created] (MYFACES-4114) Add disabled attribute to h:button
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 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
[ 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 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
[ 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 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
[ https://issues.apache.org/jira/browse/MYFACES-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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)