Re: 2.2 stability

[Karl Kildén]

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  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. :
> > On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén 
> 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

[Leonardo Uribe]

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. :
> On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén  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

[Howard W. Smith, Jr.]

On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén  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

[Karl Kildén]

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  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. 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 
>> 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  wrote:
>> >
>> > > 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
>> > >
>> > > 
>> > > 
>> > > 
>> > > 
>> > > > > > validator="#{uploadPage.validateFile}"/>
>> > > 
>> > >
>> > > > > > action="#{uploadPage.uploadFile}"/>
>> > > > > > action="#{uploadPage.uploadFile}">
>> > > 
>> > > 
>> > >
>> > > 
>> > > 
>> > > > > > value="#{uploadPage.fileContent}"
>> > > rows="10" cols="100"/>
>> > > 
>> > > 
>> > >
>> > > 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:
>> > >
>> > > 
>> > > 
>> > > 
>> > > > > > required="true"/>
>> > > 
>> > > > > > action="#{helloWorld.send}"/>
>> > > 
>> > > 
>> > >
>> > > 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, Leona

Re: 2.2 stability

[Karl Kildén]

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.  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 
> 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  wrote:
> >
> > > 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
> > >
> > > 
> > > 
> > > 
> > > 
> > >  > > validator="#{uploadPage.validateFile}"/>
> > > 
> > >
> > >  > > action="#{uploadPage.uploadFile}"/>
> > >  > > action="#{uploadPage.uploadFile}">
> > > 
> > > 
> > >
> > > 
> > > 
> > >  > > value="#{uploadPage.fileContent}"
> > > rows="10" cols="100"/>
> > > 
> > > 
> > >
> > > 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:
> > >
> > > 
> > > 
> > > 
> > >  > > required="true"/>
> > > 
> > >  > > action="#{helloWorld.send}"/>
> > > 
> > > 
> > >
> > > 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
> > > >> 

Re: 2.2 stability

[Howard W. Smith, Jr.]

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  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  wrote:
>
> > 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
> >
> > 
> > 
> > 
> > 
> >  > validator="#{uploadPage.validateFile}"/>
> > 
> >
> >  > action="#{uploadPage.uploadFile}"/>
> >  > action="#{uploadPage.uploadFile}">
> > 
> > 
> >
> > 
> > 
> >  > value="#{uploadPage.fileContent}"
> > rows="10" cols="100"/>
> > 
> > 
> >
> > 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:
> >
> > 
> > 
> > 
> >  > required="true"/>
> > 
> >  > action="#{helloWorld.send}"/>
> > 
> > 
> >
> > 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. <
> 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,
> > >> >> >
> > >> >> > I

Re: 2.2 stability

[Karl Kildén]

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  wrote:

> 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
>
> 
> 
> 
> 
>  validator="#{uploadPage.validateFile}"/>
> 
>
>  action="#{uploadPage.uploadFile}"/>
>  action="#{uploadPage.uploadFile}">
> 
> 
>
> 
> 
>  value="#{uploadPage.fileContent}"
> rows="10" cols="100"/>
> 
> 
>
> 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:
>
> 
> 
> 
>  required="true"/>
> 
>  action="#{helloWorld.send}"/>
> 
> 
>
> 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

Re: 2.2 stability

[Leonardo Uribe]

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 stability

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

[Leonardo Uribe]

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

[Karl Kildén]

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

[Leonardo Uribe]

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

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


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

[Karl Kildén]

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

[Howard W. Smith, Jr.]

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

[Leonardo Uribe]

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

[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

[Ludovic Pénet]

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

[Karl Kildén]

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  for a
while. As a fix I used the new parameter:


org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY

true


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-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-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  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
> ww.enterprisejavanews.com
> *
> * JSFCentral Interviews Podcast:
> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> * Sign up for the JSFCentral Newsletter:
> http://oi.vresp.com/?fid=ac048d0e17
>