myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Kildén <karl.kil...@gmail.com>
Subject Re: 2.2 stability
Date Wed, 12 Mar 2014 14:48:07 GMT
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. <smithh032772@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.kilden@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 <lu4242@gmail.com> wrote:
> >
> > > Hi Karl
> > >
> > > 2014-03-10 15:15 GMT-05:00 Karl Kildén <karl.kilden@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 <lu4242@gmail.com> wrote:
> > > >
> > > >> 2014-03-10 14:56 GMT-05:00 Karl Kildén <karl.kilden@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. <
> > smithh032772@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> >> response inline,
> > > >> >>
> > > >> >> On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén <
> > karl.kilden@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. :)
> > > >> >>
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message