Re: 2.2 stability
Hi Karl 2014-03-10 15:15 GMT-05:00 Karl Kildén : > Hi Leo, > > Upgraded to 2.2.1 today (or was it yesterday?) and had problems. Removed > org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY and many problems > went away. Much later discovered more problems but it's just me and my > silly app until I have proof :-) > > I totally agree that c:forEach was more broken before! Thanks a lot for > fixing it. > I have found the problem related to MYFACES-3867, so I have already fixed the code in trunk. I think this bug deserves a quick-fix release. > I would be very interested in some more input / clarifications about my > other problem actually. Are you saying that forms may not > use enctype="multipart/form-data"? How are you supposed to > fileUpload? Perhaps you must have a fileUpload component present if the > form has enctype="multipart/form-data"? Sounds like a weird limitation. My > functional requirement is of course a form with a fileupload component, it > is not working though and it's because the form will not post. I ended up > removing all markup until I had a single button in a form and it still did > not work, that's when I created a jira. But at one point that form did have > a fileupload too with no difference in the result. > > The example provided by Michael Kurz in: https://github.com/jsflive/jsf22-examples/blob/master/jsf22-input-file/src/main/webapp/upload.xhtml Look the enctype="multipart/form-data" is there, but the code also needs the h:inputFile. I don't see how it can work with just the button. I can see the example in the rar file: but the same, it requires the h:inputFile so the file is uploaded. Servlet 3.0 implementation handles the request, and JSF uses the spec, so if the servlet spec works JSF should work. regards, Leonardo Uribe > > > > > On 10 March 2014 21:01, Leonardo Uribe wrote: > >> 2014-03-10 14:56 GMT-05:00 Karl Kildén : >> > Ah the new release, yes I tried it asap it did not fix my issue. >> > >> >> Which one? #1 or #2 ? >> >> > Regarding the duplicated id issue that I think could be related to >> > c:forEach, No idea what the problem is but it works fine with mojarra and >> > just as fine with myfaces 2.1.x. The construct in that app is special so >> it >> > is up to me to reproduce it and I don't have time until next week. And >> yes, >> > c:forEach works with ajax but it's important that the items are unchanged >> > during postback. >> > >> >> Ok. If we have an example we will be able to fix it more quickly. For now >> I'll take a look at MYFACES-3867 >> >> > I am considering mojarra because enctype="multipart/form-data" is not >> > working for me with any myfaces 2 version. It's common knowledge that >> > Mojarra is skimping on some validation here and there. >> > >> > >> > On 10 March 2014 20:13, Howard W. Smith, Jr. >> wrote: >> > >> >> response inline, >> >> >> >> On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén >> >> wrote: >> >> >> >> > Hi Howard, >> >> > >> >> > If someone proposed a fix for me I must have missed it, so no my >> issues >> >> are >> >> > still not resolved unfortunately. I don't think it's possible to >> write it >> >> > in another fashion. >> >> > >> >> >> >> Leonardo's response, asking you to try MyFaces 2.2.1, which was released >> >> within the last 12 to 24 hours. :) >> >> >> >> >> >> > >> >> > Problem #1: enctype="multipart/form-data" not working. Not sure if >> anyone >> >> > tried the demo app I linked in the jira but for now I can't >> investigate >> >> it >> >> > any further on my own. >> >> > >> >> >> >> i don't think Leonardo's response was targeting this issue. >> >> maybe/hopefully, Leonardo will respond at his earliest convenience. >> >> earlier, did you say that this issue is resolved via Mojarra 2.2.x (and >> >> some other container... glassfish, jboss, ...) ??? >> >> >> >> >> >> > >> >> > Problem #2 I also have a problem with duplicated id's but it would >> take >> >> > some time to reproduce it in a demo app so I'm hesitant to bring it >> up. >> >> > Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some >> >> > bindings :-) >> >> > >> >> >> >> did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is >> >> fixed in your app/project? >> >> >> >> is it best to assume that c:forEach is supposed to work with/via AJAX >> PPR? >> >> just because Mojarra 'works', should we assume that Mojarra's >> >> implementation is correct? >> >> >> >> MyFaces and TomEE committers know that there MyFaces may be a bit more >> >> 'strict' than Mojarra (I can agree with that as well, as per my >> experience >> >> when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think >> MyFaces >> >> (and TomEE) committers question the fact that Mojarra is
Re: 2.2.0 and multipart
Howard, No that sample does not work for me. The details are in the jira. On 10 March 2014 21:47, Howard W. Smith, Jr. wrote: > Karl, did you see the email below, and did you try that sample, and did > that work for you? > > > > On Tue, Mar 4, 2014 at 10:30 AM, Howard W. Smith, Jr. < > smithh032...@gmail.com> wrote: > > > wow, okay. :) > > > > Earlier, Leonardo Uribe mentioned the following: > > > > I can confirm a simple example using MyFaces 2.2.0 works. See: > > > > http://jsflive.wordpress.com/2013/04/23/jsf22-file-upload/ > > > > Looking forward to hearing why your/Karl's test case does not work. > > > > > > > > On Tue, Mar 4, 2014 at 10:26 AM, Karl Kildén >wrote: > > > >> Removing deltaspike has no effect. / Karl > >> > >> > >> On 4 March 2014 16:23, Howard W. Smith, Jr. > >> wrote: > >> > >> > Have you reported this to Deltaspike? I wonder what happens when you > >> > 'remove' delta spike from the equation/mix, and see if stuff/stack > >> starts > >> > working. :) > >> > > >> > > >> > > >> > On Tue, Mar 4, 2014 at 9:55 AM, Karl Kildén > >> wrote: > >> > > >> > > It made no difference for me / Karl > >> > > > >> > > > >> > > On 4 March 2014 15:52, Karl Kildén wrote: > >> > > > >> > > > Nice spot, In my production environment I changed it but I will > test > >> > that > >> > > > aspect in the template project > >> > > > > >> > > > > >> > > > On 4 March 2014 15:50, Howard W. Smith, Jr. < > smithh032...@gmail.com > >> > > >wrote: > >> > > > > >> > > >> On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén < > karl.kil...@gmail.com > >> > > >> > > >> wrote: > >> > > >> > >> > > >> > Everyone, this is how I reproduced it in a test project: > >> > > >> > > >> > > >> > > >> > > >> >- Cloned Gerhards template > >> > > >> > project: > https://github.com/os890/javaweb-cdi-ds-project-template > >> > > >> > > >> > > >> > >> > > >> h, > >> > > >> > >> > > >> examining the faces-config.xml, i see 2.0 specified instead of > 2.1 > >> (or > >> > > >> 2.2). > >> > > >> > >> > > >> >> > > >> xmlns="http://java.sun.com/xml/ns/javaee"; > >> > > >> xmlns:xi="http://www.w3.org/2001/XInclude"; > >> > > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >> > > >> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee > >> > > >> http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd";> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> When MyFaces 2.2 was released, i don't think I saw any mention > of a > >> > > >> 'requirement' to update faces-config, accordingly, but it would > be > >> > nice > >> > > to > >> > > >> know if faces-config.xml has to be updated with '2.2' or 2.1. > >> > > >> > >> > > > > >> > > > > >> > > > >> > > >> > > > > >
Re: 2.2.0 and multipart
Karl, did you see the email below, and did you try that sample, and did that work for you? On Tue, Mar 4, 2014 at 10:30 AM, Howard W. Smith, Jr. < smithh032...@gmail.com> wrote: > wow, okay. :) > > Earlier, Leonardo Uribe mentioned the following: > > I can confirm a simple example using MyFaces 2.2.0 works. See: > > http://jsflive.wordpress.com/2013/04/23/jsf22-file-upload/ > > Looking forward to hearing why your/Karl's test case does not work. > > > > On Tue, Mar 4, 2014 at 10:26 AM, Karl Kildén wrote: > >> Removing deltaspike has no effect. / Karl >> >> >> On 4 March 2014 16:23, Howard W. Smith, Jr. >> wrote: >> >> > Have you reported this to Deltaspike? I wonder what happens when you >> > 'remove' delta spike from the equation/mix, and see if stuff/stack >> starts >> > working. :) >> > >> > >> > >> > On Tue, Mar 4, 2014 at 9:55 AM, Karl Kildén >> wrote: >> > >> > > It made no difference for me / Karl >> > > >> > > >> > > On 4 March 2014 15:52, Karl Kildén wrote: >> > > >> > > > Nice spot, In my production environment I changed it but I will test >> > that >> > > > aspect in the template project >> > > > >> > > > >> > > > On 4 March 2014 15:50, Howard W. Smith, Jr. > > > >wrote: >> > > > >> > > >> On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén > > >> > > >> wrote: >> > > >> >> > > >> > Everyone, this is how I reproduced it in a test project: >> > > >> > >> > > >> > >> > > >> >- Cloned Gerhards template >> > > >> > project:https://github.com/os890/javaweb-cdi-ds-project-template >> > > >> > >> > > >> >> > > >> h, >> > > >> >> > > >> examining the faces-config.xml, i see 2.0 specified instead of 2.1 >> (or >> > > >> 2.2). >> > > >> >> > > >> > > > >> xmlns="http://java.sun.com/xml/ns/javaee"; >> > > >> xmlns:xi="http://www.w3.org/2001/XInclude"; >> > > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> > > >> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee >> > > >> http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd";> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> When MyFaces 2.2 was released, i don't think I saw any mention of a >> > > >> 'requirement' to update faces-config, accordingly, but it would be >> > nice >> > > to >> > > >> know if faces-config.xml has to be updated with '2.2' or 2.1. >> > > >> >> > > > >> > > > >> > > >> > >> > >
Re: 2.2.0 and multipart
Yes, Also https://issues.apache.org/jira/browse/MYFACES-3865 On 10 March 2014 21:35, Howard W. Smith, Jr. wrote: > Leonardo Uribe, see below. I think this is the thread where Karl discussed > his fileUpload issue, and shared a test case (below), too. > > > > > On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén wrote: > > > Leonardo Uribe, Thanks for doing a test with this already. > > > > Everyone, this is how I reproduced it in a test project: > > > > > >- Cloned Gerhards template > > project:https://github.com/os890/javaweb-cdi-ds-project-template > >- Ran with mvn clean install jetty:run -> > > > http://localhost:8080/javaweb-cdi-ds-project-template/helloWorld.xhtml- > > > > > Wrote my name and pressed "Press Me" and it successfully navigated. > >- Changed helloWorld.xhtml and added enctype="multipart/form-data" to > >the form. > >- Ran project with mvn clean install jetty:run -> it does not work > >- Ran project with mvn clean install jetty:run -Pmojarra -> works > (Note > >that mojarra profile is used) > > > > > > To conclude with a normal form Gerhards project template works just fine. > > It works fine with mojarra in either case. With Myfaces and > > enctype="multipart/form-data" it does not work. > > > > I tried this several times with the same result. > > > > Deltaspike and Myfaces is what's in common with my normal stack. No > > Primefaces needed for reproduce > > > > cheers > > > > > > > > > > > > > > > > On 4 March 2014 14:58, Karl Kildén wrote: > > > > > Well for me it breaks the form completely. Even if I have only a single > > > component it's broke. Adding the primefaces > parameter > > > has no effect. I will try to put a test application together > > > > > > > > > On 4 March 2014 14:17, Leonardo K. Shikida wrote: > > > > > >> Karl > > >> > > >> I haven't tested it, but Howard figured out that it may be a > primefaces > > >> problem in their autodetection algorithm > > >> > > >> I haven't tested myself yet, but it seems it's just a matter of adding > > >> this > > >> parameter explicitly > > >> > > >> > > >> primefaces.UPLOADER > > >> commons > > >> > > >> > > >> best regards > > >> > > >> Leo > > >> > > >> > > >> [] > > >> > > >> Leo > > >> > > >> > > >> On Tue, Mar 4, 2014 at 4:37 AM, Karl Kildén > > >> wrote: > > >> > > >> > Leo, > > >> > > > >> > I have the same problem, What's your status? > > >> > > > >> > cheers > > >> > > > >> > > > >> > On 22 February 2014 02:58, Leonardo K. Shikida > > >> wrote: > > >> > > > >> > > Hi > > >> > > > > >> > > Just noticed this thread about tomee, myfacs 2.2.0 and multipart > > >> request > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > stackoverflow.com/questions/21948228/how-to-get-jsf-file-upload-to-work-on-tomee-1-6 > > >> > > > > >> > > does anyone know if between 2.1.13 and 2.2.0, multipart request > has > > >> got > > >> > any > > >> > > new bug? could not find anything in JIRA > > >> > > > > >> > > the guy who posted the stackoverflow question tested with > > >> > > > > >> > > h:commandButton while I've reproduced the problem just switching > > >> > > myfaces jars from vanilla tomee 1.6.0 from 2.1.13 to 2.2.0 and > using > > >> > > p:fileUpload > > >> > > > > >> > > [] > > >> > > > > >> > > Leo > > >> > > > > >> > > > >> > > > > > > > > >
Re: 2.2.0 and multipart
Leonardo Uribe, see below. I think this is the thread where Karl discussed his fileUpload issue, and shared a test case (below), too. On Tue, Mar 4, 2014 at 9:18 AM, Karl Kildén wrote: > Leonardo Uribe, Thanks for doing a test with this already. > > Everyone, this is how I reproduced it in a test project: > > >- Cloned Gerhards template > project:https://github.com/os890/javaweb-cdi-ds-project-template >- Ran with mvn clean install jetty:run -> >http://localhost:8080/javaweb-cdi-ds-project-template/helloWorld.xhtml- > > > Wrote my name and pressed "Press Me" and it successfully navigated. >- Changed helloWorld.xhtml and added enctype="multipart/form-data" to >the form. >- Ran project with mvn clean install jetty:run -> it does not work >- Ran project with mvn clean install jetty:run -Pmojarra -> works (Note >that mojarra profile is used) > > > To conclude with a normal form Gerhards project template works just fine. > It works fine with mojarra in either case. With Myfaces and > enctype="multipart/form-data" it does not work. > > I tried this several times with the same result. > > Deltaspike and Myfaces is what's in common with my normal stack. No > Primefaces needed for reproduce > > cheers > > > > > > > > On 4 March 2014 14:58, Karl Kildén wrote: > > > Well for me it breaks the form completely. Even if I have only a single > > component it's broke. Adding the primefaces parameter > > has no effect. I will try to put a test application together > > > > > > On 4 March 2014 14:17, Leonardo K. Shikida wrote: > > > >> Karl > >> > >> I haven't tested it, but Howard figured out that it may be a primefaces > >> problem in their autodetection algorithm > >> > >> I haven't tested myself yet, but it seems it's just a matter of adding > >> this > >> parameter explicitly > >> > >> > >> primefaces.UPLOADER > >> commons > >> > >> > >> best regards > >> > >> Leo > >> > >> > >> [] > >> > >> Leo > >> > >> > >> On Tue, Mar 4, 2014 at 4:37 AM, Karl Kildén > >> wrote: > >> > >> > Leo, > >> > > >> > I have the same problem, What's your status? > >> > > >> > cheers > >> > > >> > > >> > On 22 February 2014 02:58, Leonardo K. Shikida > >> wrote: > >> > > >> > > Hi > >> > > > >> > > Just noticed this thread about tomee, myfacs 2.2.0 and multipart > >> request > >> > > > >> > > > >> > > > >> > > >> > stackoverflow.com/questions/21948228/how-to-get-jsf-file-upload-to-work-on-tomee-1-6 > >> > > > >> > > does anyone know if between 2.1.13 and 2.2.0, multipart request has > >> got > >> > any > >> > > new bug? could not find anything in JIRA > >> > > > >> > > the guy who posted the stackoverflow question tested with > >> > > > >> > > h:commandButton while I've reproduced the problem just switching > >> > > myfaces jars from vanilla tomee 1.6.0 from 2.1.13 to 2.2.0 and using > >> > > p:fileUpload > >> > > > >> > > [] > >> > > > >> > > Leo > >> > > > >> > > >> > > > > >
Re: 2.2 stability
Hi Leo, Upgraded to 2.2.1 today (or was it yesterday?) and had problems. Removed org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY and many problems went away. Much later discovered more problems but it's just me and my silly app until I have proof :-) I totally agree that c:forEach was more broken before! Thanks a lot for fixing it. I would be very interested in some more input / clarifications about my other problem actually. Are you saying that forms may not use enctype="multipart/form-data"? How are you supposed to fileUpload? Perhaps you must have a fileUpload component present if the form has enctype="multipart/form-data"? Sounds like a weird limitation. My functional requirement is of course a form with a fileupload component, it is not working though and it's because the form will not post. I ended up removing all markup until I had a single button in a form and it still did not work, that's when I created a jira. But at one point that form did have a fileupload too with no difference in the result. On 10 March 2014 21:01, Leonardo Uribe wrote: > 2014-03-10 14:56 GMT-05:00 Karl Kildén : > > Ah the new release, yes I tried it asap it did not fix my issue. > > > > Which one? #1 or #2 ? > > > Regarding the duplicated id issue that I think could be related to > > c:forEach, No idea what the problem is but it works fine with mojarra and > > just as fine with myfaces 2.1.x. The construct in that app is special so > it > > is up to me to reproduce it and I don't have time until next week. And > yes, > > c:forEach works with ajax but it's important that the items are unchanged > > during postback. > > > > Ok. If we have an example we will be able to fix it more quickly. For now > I'll take a look at MYFACES-3867 > > > I am considering mojarra because enctype="multipart/form-data" is not > > working for me with any myfaces 2 version. It's common knowledge that > > Mojarra is skimping on some validation here and there. > > > > > > On 10 March 2014 20:13, Howard W. Smith, Jr. > wrote: > > > >> response inline, > >> > >> On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén > >> wrote: > >> > >> > Hi Howard, > >> > > >> > If someone proposed a fix for me I must have missed it, so no my > issues > >> are > >> > still not resolved unfortunately. I don't think it's possible to > write it > >> > in another fashion. > >> > > >> > >> Leonardo's response, asking you to try MyFaces 2.2.1, which was released > >> within the last 12 to 24 hours. :) > >> > >> > >> > > >> > Problem #1: enctype="multipart/form-data" not working. Not sure if > anyone > >> > tried the demo app I linked in the jira but for now I can't > investigate > >> it > >> > any further on my own. > >> > > >> > >> i don't think Leonardo's response was targeting this issue. > >> maybe/hopefully, Leonardo will respond at his earliest convenience. > >> earlier, did you say that this issue is resolved via Mojarra 2.2.x (and > >> some other container... glassfish, jboss, ...) ??? > >> > >> > >> > > >> > Problem #2 I also have a problem with duplicated id's but it would > take > >> > some time to reproduce it in a demo app so I'm hesitant to bring it > up. > >> > Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some > >> > bindings :-) > >> > > >> > >> did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is > >> fixed in your app/project? > >> > >> is it best to assume that c:forEach is supposed to work with/via AJAX > PPR? > >> just because Mojarra 'works', should we assume that Mojarra's > >> implementation is correct? > >> > >> MyFaces and TomEE committers know that there MyFaces may be a bit more > >> 'strict' than Mojarra (I can agree with that as well, as per my > experience > >> when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think > MyFaces > >> (and TomEE) committers question the fact that Mojarra is really meeting > >> requirements of the spec, or there is a different set of TCKs that > Mojarra > >> is running against. I hope 'they' will confirm, clarify, or correct what > >> I'm stating here. :) > >> >
Re: 2.2 stability
2014-03-10 14:56 GMT-05:00 Karl Kildén : > Ah the new release, yes I tried it asap it did not fix my issue. > Which one? #1 or #2 ? > Regarding the duplicated id issue that I think could be related to > c:forEach, No idea what the problem is but it works fine with mojarra and > just as fine with myfaces 2.1.x. The construct in that app is special so it > is up to me to reproduce it and I don't have time until next week. And yes, > c:forEach works with ajax but it's important that the items are unchanged > during postback. > Ok. If we have an example we will be able to fix it more quickly. For now I'll take a look at MYFACES-3867 > I am considering mojarra because enctype="multipart/form-data" is not > working for me with any myfaces 2 version. It's common knowledge that > Mojarra is skimping on some validation here and there. > > > On 10 March 2014 20:13, Howard W. Smith, Jr. wrote: > >> response inline, >> >> On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén >> wrote: >> >> > Hi Howard, >> > >> > If someone proposed a fix for me I must have missed it, so no my issues >> are >> > still not resolved unfortunately. I don't think it's possible to write it >> > in another fashion. >> > >> >> Leonardo's response, asking you to try MyFaces 2.2.1, which was released >> within the last 12 to 24 hours. :) >> >> >> > >> > Problem #1: enctype="multipart/form-data" not working. Not sure if anyone >> > tried the demo app I linked in the jira but for now I can't investigate >> it >> > any further on my own. >> > >> >> i don't think Leonardo's response was targeting this issue. >> maybe/hopefully, Leonardo will respond at his earliest convenience. >> earlier, did you say that this issue is resolved via Mojarra 2.2.x (and >> some other container... glassfish, jboss, ...) ??? >> >> >> > >> > Problem #2 I also have a problem with duplicated id's but it would take >> > some time to reproduce it in a demo app so I'm hesitant to bring it up. >> > Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some >> > bindings :-) >> > >> >> did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is >> fixed in your app/project? >> >> is it best to assume that c:forEach is supposed to work with/via AJAX PPR? >> just because Mojarra 'works', should we assume that Mojarra's >> implementation is correct? >> >> MyFaces and TomEE committers know that there MyFaces may be a bit more >> 'strict' than Mojarra (I can agree with that as well, as per my experience >> when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think MyFaces >> (and TomEE) committers question the fact that Mojarra is really meeting >> requirements of the spec, or there is a different set of TCKs that Mojarra >> is running against. I hope 'they' will confirm, clarify, or correct what >> I'm stating here. :) >>
Re: 2.2 stability
Ah the new release, yes I tried it asap it did not fix my issue. Regarding the duplicated id issue that I think could be related to c:forEach, No idea what the problem is but it works fine with mojarra and just as fine with myfaces 2.1.x. The construct in that app is special so it is up to me to reproduce it and I don't have time until next week. And yes, c:forEach works with ajax but it's important that the items are unchanged during postback. I am considering mojarra because enctype="multipart/form-data" is not working for me with any myfaces 2 version. It's common knowledge that Mojarra is skimping on some validation here and there. On 10 March 2014 20:13, Howard W. Smith, Jr. wrote: > response inline, > > On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén > wrote: > > > Hi Howard, > > > > If someone proposed a fix for me I must have missed it, so no my issues > are > > still not resolved unfortunately. I don't think it's possible to write it > > in another fashion. > > > > Leonardo's response, asking you to try MyFaces 2.2.1, which was released > within the last 12 to 24 hours. :) > > > > > > Problem #1: enctype="multipart/form-data" not working. Not sure if anyone > > tried the demo app I linked in the jira but for now I can't investigate > it > > any further on my own. > > > > i don't think Leonardo's response was targeting this issue. > maybe/hopefully, Leonardo will respond at his earliest convenience. > earlier, did you say that this issue is resolved via Mojarra 2.2.x (and > some other container... glassfish, jboss, ...) ??? > > > > > > Problem #2 I also have a problem with duplicated id's but it would take > > some time to reproduce it in a demo app so I'm hesitant to bring it up. > > Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some > > bindings :-) > > > > did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is > fixed in your app/project? > > is it best to assume that c:forEach is supposed to work with/via AJAX PPR? > just because Mojarra 'works', should we assume that Mojarra's > implementation is correct? > > MyFaces and TomEE committers know that there MyFaces may be a bit more > 'strict' than Mojarra (I can agree with that as well, as per my experience > when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think MyFaces > (and TomEE) committers question the fact that Mojarra is really meeting > requirements of the spec, or there is a different set of TCKs that Mojarra > is running against. I hope 'they' will confirm, clarify, or correct what > I'm stating here. :) >
Re: 2.2 stability
Hi 2014-03-10 14:13 GMT-05:00 Howard W. Smith, Jr. : > response inline, > > On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén wrote: > >> Hi Howard, >> >> If someone proposed a fix for me I must have missed it, so no my issues are >> still not resolved unfortunately. I don't think it's possible to write it >> in another fashion. >> > > Leonardo's response, asking you to try MyFaces 2.2.1, which was released > within the last 12 to 24 hours. :) > Yes. If there is a bug in 2.2.1 and there is evidence, I'll do my best for fix it. > >> >> Problem #1: enctype="multipart/form-data" not working. Not sure if anyone >> tried the demo app I linked in the jira but for now I can't investigate it >> any further on my own. >> > > i don't think Leonardo's response was targeting this issue. > maybe/hopefully, Leonardo will respond at his earliest convenience. > earlier, did you say that this issue is resolved via Mojarra 2.2.x (and > some other container... glassfish, jboss, ...) ??? > I have read JSF 2.2 spec fully and there is no special part related to multipart encoding. I don't see how it can work, maybe it is something not documented. I'll review the issue and check an example against latest Mojarra. > >> >> Problem #2 I also have a problem with duplicated id's but it would take >> some time to reproduce it in a demo app so I'm hesitant to bring it up. >> Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some >> bindings :-) >> > > did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is > fixed in your app/project? > > is it best to assume that c:forEach is supposed to work with/via AJAX PPR? > just because Mojarra 'works', should we assume that Mojarra's > implementation is correct? > Let's go to clarify this. First of all, c:forEach has been a broken tag for year. Most people has found many bugs, most of them related to its particular behavior. Since facelets was donated to both Mojarra and MyFaces, both share the same code and has the same problems. Mojarra has not done anything to fix the problems, so they still have the old code, but in MyFaces 2.2.x branch we have tried to fix it once for all. The problem is sometimes in some situations the old code (in Mojarra) works, but in others it just doesn't, it fails in the form of duplicate id exceptions or the state get lost, but for the user point of view sometimes it "looks" like things are working but it is not, it is rotten from the inside. So, the old code is not an option, because it is the worst possible option. The new solution is the way to go, because it solves the problem from root. So, Mojarra implementation is not correct, but just by luck it works in some situations. The solution in MyFaces 2.2.1 is the best we have so far, works in most cases and if there is a bug (I'm working on MYFACES-3867, which claims a problem in a very specific complex case) we'll fix it. I know all this has been annoying and painful, that's the reason why we did it in 2.2.x only, but if we can fix it, it will be great because the component tree will use always PSS in those dynamic parts and that means lower state size, lower session size and better overall performance. > MyFaces and TomEE committers know that there MyFaces may be a bit more > 'strict' than Mojarra (I can agree with that as well, as per my experience > when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think MyFaces > (and TomEE) committers question the fact that Mojarra is really meeting > requirements of the spec, or there is a different set of TCKs that Mojarra > is running against. I hope 'they' will confirm, clarify, or correct what > I'm stating here. :) In few words, the vision of MyFaces is comply with the spec. But that does not mean that MyFaces will be bug-compatible with Mojarra. I think the code is very good from spec point of view, and each issue found that it has been solved in a different way has been widely discussed. What's happening here is the TCK does not cover a lot of edge cases, and since MyFaces is widely used and many people gives a lot of good quality feedback, it has been possible to fix a lot of issues that Mojarra has not seen yet, or has not been fixed in the right way. One way to see the quality of the code is take a look at the amount of issues solved in each version. In 2.0.10 we solved 72 issues but in 2.0.21 we solved just 2. In 2.2.1 we solved only 12. regards, Leonardo Uribe
Re: 2.2 stability
response inline, On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén wrote: > Hi Howard, > > If someone proposed a fix for me I must have missed it, so no my issues are > still not resolved unfortunately. I don't think it's possible to write it > in another fashion. > Leonardo's response, asking you to try MyFaces 2.2.1, which was released within the last 12 to 24 hours. :) > > Problem #1: enctype="multipart/form-data" not working. Not sure if anyone > tried the demo app I linked in the jira but for now I can't investigate it > any further on my own. > i don't think Leonardo's response was targeting this issue. maybe/hopefully, Leonardo will respond at his earliest convenience. earlier, did you say that this issue is resolved via Mojarra 2.2.x (and some other container... glassfish, jboss, ...) ??? > > Problem #2 I also have a problem with duplicated id's but it would take > some time to reproduce it in a demo app so I'm hesitant to bring it up. > Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some > bindings :-) > did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is fixed in your app/project? is it best to assume that c:forEach is supposed to work with/via AJAX PPR? just because Mojarra 'works', should we assume that Mojarra's implementation is correct? MyFaces and TomEE committers know that there MyFaces may be a bit more 'strict' than Mojarra (I can agree with that as well, as per my experience when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think MyFaces (and TomEE) committers question the fact that Mojarra is really meeting requirements of the spec, or there is a different set of TCKs that Mojarra is running against. I hope 'they' will confirm, clarify, or correct what I'm stating here. :)
Re: 2.2 stability
Hi Howard, If someone proposed a fix for me I must have missed it, so no my issues are still not resolved unfortunately. I don't think it's possible to write it in another fashion. Problem #1: enctype="multipart/form-data" not working. Not sure if anyone tried the demo app I linked in the jira but for now I can't investigate it any further on my own. Problem #2 I also have a problem with duplicated id's but it would take some time to reproduce it in a demo app so I'm hesitant to bring it up. Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some bindings :-) On 10 March 2014 18:24, Howard W. Smith, Jr. wrote: > Karl, does this fix your issue and or meet your requirements? Looking > forward to your response. I'm sure others are, too. :-) > > Can you refactor your code, so it is not dependent on c:forEach? Maybe > Leonardo can advise on that, too. > On Mar 9, 2014 9:24 PM, "Leonardo Uribe" wrote: > > > Hi > > > > @MYFACES-3865 It was fixed in 2.2.1, and the artifacts will be released > > in no time. The fix for c:forEach was really complex and painful, but it > > was finally done and the result is the best option we will have. Finally > > we have a proper solution that will work in complex cases and will > > allow all facelets dinamic tags to work well together. > > > > The hack done for: > > > > org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY > > > > Is meant for people that requires the old (and buggy) logic from facelets > > 1.1.x, so it is expected to do not work in some cases. > > > > My personal perception is 2.2.1 will be very stable, it is obvious to > have > > some small bugs, but in this release we created a lot of junit tests, so > > the probability of find bugs has become small. Anyway, we will be eager > > to check and fix all new issues as soon as possible. > > > > regards, > > > > Leonardo Uribe > > > > 2014-03-09 18:26 GMT-05:00 Howard W. Smith, Jr. >: > > > On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet > wrote: > > > > > >> I found 2.2 to be very stable, almost a drop in replacement for 2.1. > > > > > > > > > +1 > > > > > > I was using MyFaces 2.1.13 prior using MyFaces 2.2.0 (final), and > MyFaces > > > 2.2.0 seems just as stable as 2.1.13 is/was. I'm very pleased/satisfied > > > with myFaces 2.2.0, and i have had 'no' issues at all. :) > > >
Re: 2.2 stability
Karl, does this fix your issue and or meet your requirements? Looking forward to your response. I'm sure others are, too. :-) Can you refactor your code, so it is not dependent on c:forEach? Maybe Leonardo can advise on that, too. On Mar 9, 2014 9:24 PM, "Leonardo Uribe" wrote: > Hi > > @MYFACES-3865 It was fixed in 2.2.1, and the artifacts will be released > in no time. The fix for c:forEach was really complex and painful, but it > was finally done and the result is the best option we will have. Finally > we have a proper solution that will work in complex cases and will > allow all facelets dinamic tags to work well together. > > The hack done for: > > org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY > > Is meant for people that requires the old (and buggy) logic from facelets > 1.1.x, so it is expected to do not work in some cases. > > My personal perception is 2.2.1 will be very stable, it is obvious to have > some small bugs, but in this release we created a lot of junit tests, so > the probability of find bugs has become small. Anyway, we will be eager > to check and fix all new issues as soon as possible. > > regards, > > Leonardo Uribe > > 2014-03-09 18:26 GMT-05:00 Howard W. Smith, Jr. : > > On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet wrote: > > > >> I found 2.2 to be very stable, almost a drop in replacement for 2.1. > > > > > > +1 > > > > I was using MyFaces 2.1.13 prior using MyFaces 2.2.0 (final), and MyFaces > > 2.2.0 seems just as stable as 2.1.13 is/was. I'm very pleased/satisfied > > with myFaces 2.2.0, and i have had 'no' issues at all. :) >
Tobago treeNode markup for state selected
I use tobago-core-2.0.0-beta-1-SNAPSHOT with myfaces-api-2.2.0 . Since 2.0.0: "The tc:treeNode has no longer the attributes: "selected", "expanded", "marked", "treeMarkedListener", "treeExpansionListener" ". I like to mark selected node other than not selected nodes (other foreground-color for example). In my tree I use tc:treeCommand. There is attribut markup. This must evaluate to "org.apache.myfaces.tobago.context.Markup". But there is not possibility to instantiate my own markup ?! Is there another way? snippet from .xhtml: G.punkt - medical services Ihre Wünsche sind unser Konzept Halberstädter Str. 115 A 39112 Magdeburg fon: +49 391 280380 fax: +49 391 2803822 mail: kirstin.ebel...@gmatic.de inet: www.gmatic.de Institutskennzeichen: IK331530332, OID: 1.2.276.0.76.3.1.51; (c) 2013 by G.punkt G.punkt ist Trust center zertifiziert für elektronischen Datenaustausch mit Leistungserbringern GF: Tino Graßhof; ST-ID: DE210661356; Nr.: 101-225-04463; Großhandelserlaubnis nach § 52a Arzneimittelgesetz G.punkt ist Mitglied im smartcareunit Netzwerk: modular, intensiv, human - Intensivstationen der Zukunft Neoscreen, NIQ und gmatic sind eingetragene Warenzeichen
