ICEfaces
  1. ICEfaces
  2. ICE-3425

Seam fileupload tag does not work with IceFaces

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      ICEfaces + Seam

      Description

        Activity

        Hide
        Judy Guglielmin added a comment -

        Not sure why we would integrate this component. Just use <ice:inputFile> without the progress Bar. (pretty much does the same thing as this s component). Most issues arising from <ice:inputFile> are due to progressBar...but they have all been resolved in ICEfaces-1.7.1 (other than for jboss-4.2.3.GA which we are now working on and has just been released).

        Show
        Judy Guglielmin added a comment - Not sure why we would integrate this component. Just use <ice:inputFile> without the progress Bar. (pretty much does the same thing as this s component). Most issues arising from <ice:inputFile> are due to progressBar...but they have all been resolved in ICEfaces-1.7.1 (other than for jboss-4.2.3.GA which we are now working on and has just been released).
        Hide
        Sheng Gu added a comment -

        I don't know whether you have a sample for <ice:inputFile> without progress bar, all my testsresults without progress bar were the same as <ice:inputFile> with progressbar

        Show
        Sheng Gu added a comment - I don't know whether you have a sample for <ice:inputFile> without progress bar, all my testsresults without progress bar were the same as <ice:inputFile> with progressbar
        Hide
        Judy Guglielmin added a comment -

        <ice:panelGroup styleClass="exampleBox inputFileContainer">
        <p> This one has no progressMonitor </p>
        <!-- file upload usage with progress callback. -->
        <ice:inputFile id="inputFileName"
        submitOnUpload="postUpload"
        actionListener="#

        {inputFileController.uploadFile}

        "/>
        <ice:panelGroup>
        <h:messages layout="table"
        globalOnly="false"
        showDetail="true"
        showSummary="false"/>
        </ice:panelGroup>
        </ice:panelGroup>

        This one has no outputProgress component and will do the fileupload as does s:fileupload.

        Show
        Judy Guglielmin added a comment - <ice:panelGroup styleClass="exampleBox inputFileContainer"> <p> This one has no progressMonitor </p> <!-- file upload usage with progress callback. --> <ice:inputFile id="inputFileName" submitOnUpload="postUpload" actionListener="# {inputFileController.uploadFile} "/> <ice:panelGroup> <h:messages layout="table" globalOnly="false" showDetail="true" showSummary="false"/> </ice:panelGroup> </ice:panelGroup> This one has no outputProgress component and will do the fileupload as does s:fileupload.
        Hide
        Sheng Gu added a comment -

        Hi Judy,

        I want to give a help and try to fix this issue, but I need your help. Whether users like to use s:fileUpload or ice:inputFile in their Seam-ICEfaces projects, it totally doesn't influence they like ICEfaces components. I think using ice:inputFile in Seam-ICEfaces is a little tricky, especially in EJB and conversation.

        I tested s:fileUpload, and found some problem in FileUploadRendererBase.java as shown partial codes below. Why the request object is not a instance of MultipartRequest? Maybe, ICEfaces form submitting changes the ServletRequest? Could you give me some analysis on it? Thanks a lot.

        protected void doDecode(FacesContext context, UIComponent component)
        {
        UIFileUpload fileUpload = (UIFileUpload) component;
        ServletRequest request = (ServletRequest) context.getExternalContext().getRequest();

        if (!(request instanceof MultipartRequest))

        { request = unwrapMultipartRequest(request); }

        if (request instanceof MultipartRequest)

        { MultipartRequest multipartRequest = (MultipartRequest) request; ........ }

        }

        /**

        • Finds an instance of MultipartRequest wrapped within a request or its
        • (recursively) wrapped requests.
          */
          private static ServletRequest unwrapMultipartRequest(ServletRequest request)
          {
          while (!(request instanceof MultipartRequest))
          {
          boolean found = false;

        for (Method m : request.getClass().getMethods())
        {
        if (ServletRequest.class.isAssignableFrom(m.getReturnType())
        && m.getParameterTypes().length == 0)
        {
        try

        { request = (ServletRequest) m.invoke(request); found = true; break; }

        catch (Exception ex)

        { /* Ignore, try the next one */ }

        }
        }

        if (!found)
        {
        for (Field f : request.getClass().getDeclaredFields())
        {
        if (ServletRequest.class.isAssignableFrom(f.getType()))
        {
        try

        { request = (ServletRequest) f.get(request); }

        catch (Exception ex)

        { /* Ignore */ }

        }
        }
        }

        if (!found) break;
        }

        return request;
        }

        Show
        Sheng Gu added a comment - Hi Judy, I want to give a help and try to fix this issue, but I need your help. Whether users like to use s:fileUpload or ice:inputFile in their Seam-ICEfaces projects, it totally doesn't influence they like ICEfaces components. I think using ice:inputFile in Seam-ICEfaces is a little tricky, especially in EJB and conversation. I tested s:fileUpload, and found some problem in FileUploadRendererBase.java as shown partial codes below. Why the request object is not a instance of MultipartRequest? Maybe, ICEfaces form submitting changes the ServletRequest? Could you give me some analysis on it? Thanks a lot. protected void doDecode(FacesContext context, UIComponent component) { UIFileUpload fileUpload = (UIFileUpload) component; ServletRequest request = (ServletRequest) context.getExternalContext().getRequest(); if (!(request instanceof MultipartRequest)) { request = unwrapMultipartRequest(request); } if (request instanceof MultipartRequest) { MultipartRequest multipartRequest = (MultipartRequest) request; ........ } } /** Finds an instance of MultipartRequest wrapped within a request or its (recursively) wrapped requests. */ private static ServletRequest unwrapMultipartRequest(ServletRequest request) { while (!(request instanceof MultipartRequest)) { boolean found = false; for (Method m : request.getClass().getMethods()) { if (ServletRequest.class.isAssignableFrom(m.getReturnType()) && m.getParameterTypes().length == 0) { try { request = (ServletRequest) m.invoke(request); found = true; break; } catch (Exception ex) { /* Ignore, try the next one */ } } } if (!found) { for (Field f : request.getClass().getDeclaredFields()) { if (ServletRequest.class.isAssignableFrom(f.getType())) { try { request = (ServletRequest) f.get(request); } catch (Exception ex) { /* Ignore */ } } } } if (!found) break; } return request; }
        Hide
        Ken Fyten added a comment -

        Marking as Closed / Invalid as part of legacy ICEfaces 1.x, 2.x JIRA cleanup.

        Note: This issue may be resolved in a newer ICEfaces release, available here: http://www.icesoft.org/java/downloads/icefaces-downloads.jsf

        If the issue persists with the current ICEfaces release, please create a new JIRA for it.

        Show
        Ken Fyten added a comment - Marking as Closed / Invalid as part of legacy ICEfaces 1.x, 2.x JIRA cleanup. Note: This issue may be resolved in a newer ICEfaces release, available here: http://www.icesoft.org/java/downloads/icefaces-downloads.jsf If the issue persists with the current ICEfaces release, please create a new JIRA for it.

          People

          • Assignee:
            Unassigned
            Reporter:
            Sheng Gu
          • Votes:
            12 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: