Re: 2.2 stability
I can confirm that I used c:forEach erroneously. Myfaces 2.2.3 running great for me now cheers On 13 March 2014 16:27, Leonardo Uribe lu4...@gmail.com wrote: Hi @Karl I think your problem should be something different. I closed MYFACES-3869, since we have positive confirmation that the fix done works, but we need to analyze your problem and check if there is an error in MyFaces or not. We need more information than just the stack trace. MyFaces default error page gives the component tree using ErrorWriter and indicate which component has the duplicate id. There are some tricks involving programmatic component manipulation that can trigger a duplicate id exception, but not because they are correct and myfaces has a bug but because they are just invalid. In JSF 2.2, with vdl.createComponent it is possible to create programmatically added components using facelets in the right way. It is useful to use ui:debug tag to see the component tree and describe the steps involved in the exception, to help us to understand what could possible happen and how to fix it. regards, Leonardo Uribe 2014-03-13 7:19 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com: On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén karl.kil...@gmail.com wrote: Tried 2.2.2-20140313.024403-5 Duplicate id problems are still present. I have tried for a while now to create a simple sample but I am unsuccessful so far. +1 thanks Karl for the report.
Re: 2.2 stability
Hi all,
Tried 2.2.2-20140313.024403-5
Duplicate id problems are still present. I have tried for a while now to
create a simple sample but I am unsuccessful so far.
On 12 March 2014 15:48, Karl Kildén karl.kil...@gmail.com wrote:
Hi Howard,
Leo found and fixed the enctype=multipart/form-data. It's basically up
to the Servlet Container to do the job now when the Faces Servlet is
annotated correctly. Thanks a lot to everyone who helped me with that
issue. Regarding the duplicate id problems, I did not get enough time to
checkout the source and build myself today but tomorrow is looking better.
A snapshot would of course be more convenient but I promise I will test
tomorrow regardless.
If my problem persists I will also attach a sample project or at least
spend the day trying... Yay for meeting free Thursday :-)
Thanks for your interest,
Karl
On 12 March 2014 15:11, Howard W. Smith, Jr. smithh032...@gmail.comwrote:
Following up,
Karl, are you still waiting on Leonardo to trigger a snapshot build? With
all that has been discussed here, is it likely that tomee + myfaces 2.2.x
(snapshot) is a 'go' for you? :)
fingers crossed... :)
On Tue, Mar 11, 2014 at 4:19 AM, Karl Kildén karl.kil...@gmail.com
wrote:
OK, if enctype is not supported for post (except when fileUpload
component
is present) it could be my headache then. If I have a fileupload or not
depends on include logic etc. This is somewhat a legacy so I can
probably
rework it in the future.
I assume any build time logic that could conditionally remove fileupload
will cause this behavior. I think it is awkward and unnecessarily
limiting.
With this information I will make some more attempts.
MYFACES-3867, provided stacktrackes does not match mine but I would
love if
you could perhaps trigger a snapshot?
On 10 March 2014 23:30, Leonardo Uribe lu4...@gmail.com wrote:
Hi Karl
2014-03-10 15:15 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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
h:form id=form enctype=multipart/form-data
h:messages/
h:panelGrid columns=2
h:outputText value=File:/
h:inputFile id=file value=#{uploadPage.uploadedFile}
validator=#{uploadPage.validateFile}/
/h:panelGrid
h:commandButton value=Upload File
action=#{uploadPage.uploadFile}/
h:commandButton value=Upload File (Ajax)
action=#{uploadPage.uploadFile}
f:ajax execute=file render=@all/
/h:commandButton
h:panelGrid id=content columns=1
h:outputText value=Content:/
h:inputTextarea readonly=true
value=#{uploadPage.fileContent}
rows=10 cols=100/
/h:panelGrid
/h:form
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.
h:form id=mainForm enctype=multipart/form-data
h:commandButton value=Press me action=# {bean.test}/br/
/h:form
I can see the example in the rar file:
h:form id=mainForm enctype=multipart/form-data
h:panelGrid columns=2
h:outputLabel for=name value=Please enter your
name/
h:inputText id=name value=#{helloWorld.name}
required=true/
/h:panelGrid
h:commandButton value=Press me
action=#{helloWorld.send}/br/
h:messages showDetail=true showSummary=false/
Re: 2.2 stability
On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén karl.kil...@gmail.com wrote: Tried 2.2.2-20140313.024403-5 Duplicate id problems are still present. I have tried for a while now to create a simple sample but I am unsuccessful so far. +1 thanks Karl for the report.
Re: 2.2 stability
Hi @Karl I think your problem should be something different. I closed MYFACES-3869, since we have positive confirmation that the fix done works, but we need to analyze your problem and check if there is an error in MyFaces or not. We need more information than just the stack trace. MyFaces default error page gives the component tree using ErrorWriter and indicate which component has the duplicate id. There are some tricks involving programmatic component manipulation that can trigger a duplicate id exception, but not because they are correct and myfaces has a bug but because they are just invalid. In JSF 2.2, with vdl.createComponent it is possible to create programmatically added components using facelets in the right way. It is useful to use ui:debug tag to see the component tree and describe the steps involved in the exception, to help us to understand what could possible happen and how to fix it. regards, Leonardo Uribe 2014-03-13 7:19 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com: On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén karl.kil...@gmail.com wrote: Tried 2.2.2-20140313.024403-5 Duplicate id problems are still present. I have tried for a while now to create a simple sample but I am unsuccessful so far. +1 thanks Karl for the report.
Re: 2.2 stability
Following up,
Karl, are you still waiting on Leonardo to trigger a snapshot build? With
all that has been discussed here, is it likely that tomee + myfaces 2.2.x
(snapshot) is a 'go' for you? :)
fingers crossed... :)
On Tue, Mar 11, 2014 at 4:19 AM, Karl Kildén karl.kil...@gmail.com wrote:
OK, if enctype is not supported for post (except when fileUpload component
is present) it could be my headache then. If I have a fileupload or not
depends on include logic etc. This is somewhat a legacy so I can probably
rework it in the future.
I assume any build time logic that could conditionally remove fileupload
will cause this behavior. I think it is awkward and unnecessarily limiting.
With this information I will make some more attempts.
MYFACES-3867, provided stacktrackes does not match mine but I would love if
you could perhaps trigger a snapshot?
On 10 March 2014 23:30, Leonardo Uribe lu4...@gmail.com wrote:
Hi Karl
2014-03-10 15:15 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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
h:form id=form enctype=multipart/form-data
h:messages/
h:panelGrid columns=2
h:outputText value=File:/
h:inputFile id=file value=#{uploadPage.uploadedFile}
validator=#{uploadPage.validateFile}/
/h:panelGrid
h:commandButton value=Upload File
action=#{uploadPage.uploadFile}/
h:commandButton value=Upload File (Ajax)
action=#{uploadPage.uploadFile}
f:ajax execute=file render=@all/
/h:commandButton
h:panelGrid id=content columns=1
h:outputText value=Content:/
h:inputTextarea readonly=true
value=#{uploadPage.fileContent}
rows=10 cols=100/
/h:panelGrid
/h:form
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.
h:form id=mainForm enctype=multipart/form-data
h:commandButton value=Press me action=# {bean.test}/br/
/h:form
I can see the example in the rar file:
h:form id=mainForm enctype=multipart/form-data
h:panelGrid columns=2
h:outputLabel for=name value=Please enter your
name/
h:inputText id=name value=#{helloWorld.name}
required=true/
/h:panelGrid
h:commandButton value=Press me
action=#{helloWorld.send}/br/
h:messages showDetail=true showSummary=false/
/h:form
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 lu4...@gmail.com wrote:
2014-03-10 14:56 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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
Re: 2.2 stability
Hi Howard,
Leo found and fixed the enctype=multipart/form-data. It's basically up
to the Servlet Container to do the job now when the Faces Servlet is
annotated correctly. Thanks a lot to everyone who helped me with that
issue. Regarding the duplicate id problems, I did not get enough time to
checkout the source and build myself today but tomorrow is looking better.
A snapshot would of course be more convenient but I promise I will test
tomorrow regardless.
If my problem persists I will also attach a sample project or at least
spend the day trying... Yay for meeting free Thursday :-)
Thanks for your interest,
Karl
On 12 March 2014 15:11, Howard W. Smith, Jr. smithh032...@gmail.com wrote:
Following up,
Karl, are you still waiting on Leonardo to trigger a snapshot build? With
all that has been discussed here, is it likely that tomee + myfaces 2.2.x
(snapshot) is a 'go' for you? :)
fingers crossed... :)
On Tue, Mar 11, 2014 at 4:19 AM, Karl Kildén karl.kil...@gmail.com
wrote:
OK, if enctype is not supported for post (except when fileUpload
component
is present) it could be my headache then. If I have a fileupload or not
depends on include logic etc. This is somewhat a legacy so I can probably
rework it in the future.
I assume any build time logic that could conditionally remove fileupload
will cause this behavior. I think it is awkward and unnecessarily
limiting.
With this information I will make some more attempts.
MYFACES-3867, provided stacktrackes does not match mine but I would love
if
you could perhaps trigger a snapshot?
On 10 March 2014 23:30, Leonardo Uribe lu4...@gmail.com wrote:
Hi Karl
2014-03-10 15:15 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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
h:form id=form enctype=multipart/form-data
h:messages/
h:panelGrid columns=2
h:outputText value=File:/
h:inputFile id=file value=#{uploadPage.uploadedFile}
validator=#{uploadPage.validateFile}/
/h:panelGrid
h:commandButton value=Upload File
action=#{uploadPage.uploadFile}/
h:commandButton value=Upload File (Ajax)
action=#{uploadPage.uploadFile}
f:ajax execute=file render=@all/
/h:commandButton
h:panelGrid id=content columns=1
h:outputText value=Content:/
h:inputTextarea readonly=true
value=#{uploadPage.fileContent}
rows=10 cols=100/
/h:panelGrid
/h:form
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.
h:form id=mainForm enctype=multipart/form-data
h:commandButton value=Press me action=# {bean.test}/br/
/h:form
I can see the example in the rar file:
h:form id=mainForm enctype=multipart/form-data
h:panelGrid columns=2
h:outputLabel for=name value=Please enter your
name/
h:inputText id=name value=#{helloWorld.name}
required=true/
/h:panelGrid
h:commandButton value=Press me
action=#{helloWorld.send}/br/
h:messages showDetail=true showSummary=false/
/h:form
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
Re: 2.2 stability
OK, if enctype is not supported for post (except when fileUpload component
is present) it could be my headache then. If I have a fileupload or not
depends on include logic etc. This is somewhat a legacy so I can probably
rework it in the future.
I assume any build time logic that could conditionally remove fileupload
will cause this behavior. I think it is awkward and unnecessarily limiting.
With this information I will make some more attempts.
MYFACES-3867, provided stacktrackes does not match mine but I would love if
you could perhaps trigger a snapshot?
On 10 March 2014 23:30, Leonardo Uribe lu4...@gmail.com wrote:
Hi Karl
2014-03-10 15:15 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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
h:form id=form enctype=multipart/form-data
h:messages/
h:panelGrid columns=2
h:outputText value=File:/
h:inputFile id=file value=#{uploadPage.uploadedFile}
validator=#{uploadPage.validateFile}/
/h:panelGrid
h:commandButton value=Upload File
action=#{uploadPage.uploadFile}/
h:commandButton value=Upload File (Ajax)
action=#{uploadPage.uploadFile}
f:ajax execute=file render=@all/
/h:commandButton
h:panelGrid id=content columns=1
h:outputText value=Content:/
h:inputTextarea readonly=true
value=#{uploadPage.fileContent}
rows=10 cols=100/
/h:panelGrid
/h:form
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.
h:form id=mainForm enctype=multipart/form-data
h:commandButton value=Press me action=# {bean.test}/br/
/h:form
I can see the example in the rar file:
h:form id=mainForm enctype=multipart/form-data
h:panelGrid columns=2
h:outputLabel for=name value=Please enter your name/
h:inputText id=name value=#{helloWorld.name}
required=true/
/h:panelGrid
h:commandButton value=Press me
action=#{helloWorld.send}/br/
h:messages showDetail=true showSummary=false/
/h:form
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 lu4...@gmail.com wrote:
2014-03-10 14:56 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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. smithh032...@gmail.com
wrote:
response inline,
On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com
wrote:
Hi Howard,
If someone proposed a fix for me I must have missed it,
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 lu4...@gmail.com 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. smithh032...@gmail.com: On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr 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
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. smithh032...@gmail.com 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 lu4...@gmail.com 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. smithh032...@gmail.com : On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr 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
response inline, On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com 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. smithh032...@gmail.com: response inline, On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com 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
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. smithh032...@gmail.com wrote: response inline, On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com 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 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 lu4...@gmail.com wrote: 2014-03-10 14:56 GMT-05:00 Karl Kildén karl.kil...@gmail.com: 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. smithh032...@gmail.com wrote: response inline, On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com 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 Karl
2014-03-10 15:15 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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
h:form id=form enctype=multipart/form-data
h:messages/
h:panelGrid columns=2
h:outputText value=File:/
h:inputFile id=file value=#{uploadPage.uploadedFile}
validator=#{uploadPage.validateFile}/
/h:panelGrid
h:commandButton value=Upload File action=#{uploadPage.uploadFile}/
h:commandButton value=Upload File (Ajax)
action=#{uploadPage.uploadFile}
f:ajax execute=file render=@all/
/h:commandButton
h:panelGrid id=content columns=1
h:outputText value=Content:/
h:inputTextarea readonly=true value=#{uploadPage.fileContent}
rows=10 cols=100/
/h:panelGrid
/h:form
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.
h:form id=mainForm enctype=multipart/form-data
h:commandButton value=Press me action=# {bean.test}/br/
/h:form
I can see the example in the rar file:
h:form id=mainForm enctype=multipart/form-data
h:panelGrid columns=2
h:outputLabel for=name value=Please enter your name/
h:inputText id=name value=#{helloWorld.name}
required=true/
/h:panelGrid
h:commandButton value=Press me action=#{helloWorld.send}/br/
h:messages showDetail=true showSummary=false/
/h:form
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 lu4...@gmail.com wrote:
2014-03-10 14:56 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
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. smithh032...@gmail.com
wrote:
response inline,
On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com
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
Re: 2.2 stability
Hi, Im sure others know better but here's my story as early adopter. I am -1 against adoption if you use c:forEach because it's been rewritten or greatly improved upon somehow. As a consequence I was blocked by MYFACES-3853 https://issues.apache.org/jira/browse/MYFACES-3853 for a while. As a fix I used the new parameter: context-param param-nameorg.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY /param-name param-valuetrue/param-value /context-param And I upgraded to a snaphot fast. That same snapshot messed up the id generation for me if I kept above parameter, luckily everything worked when I removed it but I still got that card house feeling. To summarize I think above parameter is broken in 2.2.1 but I have not tried to reproduce and ofc could be my setup somehow. Also I am contemplating dropping TomEE as my appserver and use mojarra for now because of MYFACES-3865https://issues.apache.org/jira/browse/MYFACES-3865 ... I have a release in two days and at this point I just need everything to work. Again it might just be me (all though MYFACES-3865https://issues.apache.org/jira/browse/MYFACES-3865 has at least two other reporters as seen in the linked conversation on the list). Getting mojarra to work with TomEE failed for me so something has to give and It seems I will fall back on Tomcat, use Mojarra and then reattempt myfaces and TomEE for at a later release. My other smaller app, my side projects, etc. Are all working fine (they also don't need any enctype=multipart/form-data that I have trouble with). cheers On 9 March 2014 20:27, Kito Mann kito.m...@virtua.com wrote: Hello everyone, For those of you who have had a chance to kick the tires with 2.2, how stable is it so far? For the developers, can you give me a sense of how much of the code base was touched for this release? I'm trying to evaluate whether or not it's ready for one of my clients (it will be hard sale, since it's so new). ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: 2.2 stability
I found 2.2 to be very stable, almost a drop in replacement for 2.1. Using the new file upload feature of JSF 2.2 was straightforward for me. I had a hard time with Faces Flows, but Leonardo and the others kindly helped and fixed a few bugs - I still have to test that it is ok. I expected many more problems to come with this new major release. I would advise anyway anyone who does not have some experience with JSF and is not ready to fire his debugger when encountering a strange behaviour to wait for 2.2.1 or 2.2.2 and for DeltaSpike 0.6. There are very few glitches given the bunch of new features, but these are still glitches. To those persons I would advise latest JSF 2.1 + latest CODI for the time being. Best regards, Ludovic On 9 mars 2014 20:27:31 UTC+01:00, Kito Mann kito.m...@virtua.com wrote: Hello everyone, For those of you who have had a chance to kick the tires with 2.2, how stable is it so far? For the developers, can you give me a sense of how much of the code base was touched for this release? I'm trying to evaluate whether or not it's ready for one of my clients (it will be hard sale, since it's so new). ___ Kito D. Mann | @kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com | @jsfcentral +1 203-998-0403 * Listen to the Enterprise Java Newscast: *http://w http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com http://ww.enterprisejavanews.com* * JSFCentral Interviews Podcast: http://www.jsfcentral.com/resources/jsfcentralpodcasts/ * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17 -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. |
Re: 2.2 stability
On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr 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
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. smithh032...@gmail.com: On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr 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. :)
