ICEfaces
  1. ICEfaces
  2. ICE-7931

ACE:FileEntry Component not functioning on Glassfish 3.1.2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0
    • Fix Version/s: 3.0.1, EE-3.0.0.GA
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Confirmed using:
      ICEfaces3 Maintenance revision# 28410
      Browser: Firefox11
      Server: Glassfish3.1.2

      Description

      Please see the forum post. When trying to upload a file in the showcase demos there is a message displayed: "The file is required to submit this form. " This message is displayed even though a file is selected.

      This can be tested using either showcase sample or the QA test-suite:
      Showcase: http://server.ice:8888/svn/ossrepo/icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/samples/showcase/showcase
      Test Suite: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/fileEntry

        Issue Links

          Activity

          Cruz Miraback created issue -
          Ken Fyten made changes -
          Field Original Value New Value
          Salesforce Case []
          Fix Version/s 3.0.1 [ 10282 ]
          Assignee Priority P1
          Affects Version/s 3.0 [ 10241 ]
          Assignee Mark Collette [ mark.collette ]
          Ken Fyten made changes -
          Salesforce Case []
          Assignee Mark Collette [ mark.collette ] Ted Goddard [ ted.goddard ]
          Ken Fyten made changes -
          Summary ACE:FileEntry Component not functioning on Glassfish3.1.2 ACE:FileEntry Component not functioning on Glassfish 3.1.2
          Salesforce Case []
          Ken Fyten made changes -
          Salesforce Case []
          Affects [Compatibility/Configuration]
          Security Private [ 10001 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #28435 Wed Mar 21 12:07:27 MDT 2012 ted.goddard performing upload decoding in FileEntryResourceHandler.isResourceRequest (ICE-7931)
          Files Changed
          Commit graph ADD /icefaces3/trunk/icefaces/ace/component/src/org/icefaces/ace/component/fileentry/FileEntryResourceHandler.java
          Commit graph MODIFY /icefaces3/trunk/icefaces/ace/component/resources/icefaces.ace/META-INCLUDE/faces-config.xml
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #28436 Wed Mar 21 12:15:40 MDT 2012 ted.goddard performing upload decoding in FileEntryResourceHandler.isResourceRequest (ICE-7931)
          Files Changed
          Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/ace/component/resources/icefaces.ace/META-INCLUDE/faces-config.xml
          Commit graph ADD /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/ace/component/src/org/icefaces/ace/component/fileentry/FileEntryResourceHandler.java
          Hide
          Ted Goddard added a comment -

          Multipart POST decoding via commons-fileupload is now being done in FileEntryResourceHandler.isResourceRequest(). This is an abuse of the isResourceRequest() method, but allows the InputStream to be decoded.

          There is still redundant code in both FileEntryResourceHandler and FileEntryPhaseListener, so both of these classes are badly in need of some refactoring to remove dead and redundant code.

          Show
          Ted Goddard added a comment - Multipart POST decoding via commons-fileupload is now being done in FileEntryResourceHandler.isResourceRequest(). This is an abuse of the isResourceRequest() method, but allows the InputStream to be decoded. There is still redundant code in both FileEntryResourceHandler and FileEntryPhaseListener, so both of these classes are badly in need of some refactoring to remove dead and redundant code.
          Ted Goddard made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Fix Version/s EE-3.0.0.GA [ 10262 ]
          Hide
          Mark Collette added a comment -

          IsResourceRequest() does look like a good hook to handle the multi-part stream, without any side effects of the lifecycle interfering, since it is before the lifecycle:

          Although this does seem like a nice hook for running as soon as possible, since it comes before Lifecycle.execute even happens:

          FacesServlet.service {
          // Acquire the FacesContext instance for this request
          FacesContext context = facesContextFactory.getFacesContext
          (servletConfig.getServletContext(), request, response, lifecycle);

          // Execute the request processing lifecycle for this request
          try {
          ResourceHandler handler =
          context.getApplication().getResourceHandler();
          if (handler.isResourceRequest(context))

          { handler.handleResourceRequest(context); }

          else

          { lifecycle.execute(context); lifecycle.render(context); }

          But in case there is a problem that we're processing things outside/before the lifecycle, there might be a more surgical alteration we could try. If we change AutoUpdateCallbackPartialViewContext and RequestContext so that the DefaultRequestContext instance is lazily set, instead of in AutoUpdateCallbackPartialViewContext's constructor, so that AutoUpdateCallbackPartialViewContext.isAjaxRequest() is not called until later, then maybe that will solve this issue. All the methods in these classes seem to only be needed in ApplyRequestValuesPhase and after. And FileEntryPhaseListener is a little touchy in needing some of this stuff to not be invoked yet in RestoreViewPhase.

          Show
          Mark Collette added a comment - IsResourceRequest() does look like a good hook to handle the multi-part stream, without any side effects of the lifecycle interfering, since it is before the lifecycle: Although this does seem like a nice hook for running as soon as possible, since it comes before Lifecycle.execute even happens: FacesServlet.service { // Acquire the FacesContext instance for this request FacesContext context = facesContextFactory.getFacesContext (servletConfig.getServletContext(), request, response, lifecycle); // Execute the request processing lifecycle for this request try { ResourceHandler handler = context.getApplication().getResourceHandler(); if (handler.isResourceRequest(context)) { handler.handleResourceRequest(context); } else { lifecycle.execute(context); lifecycle.render(context); } But in case there is a problem that we're processing things outside/before the lifecycle, there might be a more surgical alteration we could try. If we change AutoUpdateCallbackPartialViewContext and RequestContext so that the DefaultRequestContext instance is lazily set, instead of in AutoUpdateCallbackPartialViewContext's constructor, so that AutoUpdateCallbackPartialViewContext.isAjaxRequest() is not called until later, then maybe that will solve this issue. All the methods in these classes seem to only be needed in ApplyRequestValuesPhase and after. And FileEntryPhaseListener is a little touchy in needing some of this stuff to not be invoked yet in RestoreViewPhase.
          Mark Collette made changes -
          Link This issue blocks ICE-7953 [ ICE-7953 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Assignee Priority P1

            People

            • Assignee:
              Ted Goddard
              Reporter:
              Cruz Miraback
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: