ICEfaces
  1. ICEfaces
  2. ICE-7683

ICEpush check fails because Servlet 3.0 async methods are not accessible in the portlet API

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.RC2
    • Fix Version/s: 3.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 3 portal portlet ICEpush
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      <context-param>
          <param-name>org.icepush.useAsyncContext</param-name>
          <param-value>false</param-value>
      </context-param>
      Show
      <context-param>     <param-name>org.icepush.useAsyncContext</param-name>     <param-value>false</param-value> </context-param>

      Description

      In testing our ACE Showcase portlets on Liferay 6.1, I'm finding that an aspect of ICEpush is failing in the following way:

      Caused by: java.lang.UnsupportedOperationException
          at org.icefaces.impl.push.servlet.ProxyHttpServletRequest.(ProxyHttpServletRequest.java:81)
          at org.icepush.servlet.AsyncAdaptingServlet.service(AsyncAdaptingServlet.java:42)
          at org.icepush.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:48)
          at org.icepush.servlet.PathDispatcher.service(PathDispatcher.java:39)
          at org.icepush.servlet.BrowserDispatcher$BrowserEntry.service(BrowserDispatcher.java:105)
          at org.icepush.servlet.BrowserDispatcher.service(BrowserDispatcher.java:44)
          at org.icepush.servlet.PathDispatcher.service(PathDispatcher.java:39)
          at org.icepush.servlet.MainServlet.service(MainServlet.java:90)

      The ProxyHttpServletRequest class is used as a wrapper to protect certain framework calls from having to do portlet-specific handling. Instead, the proxy exposes the full HttpServletRequest API but only implements that stuff we need. Apparently we need the isAsyncSupported() method to return something for portlets. From what I can gather, the Portlet API does not expose any of the various *Async* methods that are part of the Servlet 3.0 spec, so our options are:

      Short-term:

      1) Change the proxies method implementation from:

          public boolean isAsyncSupported(){
              log.severe("ProxyHttpServletRequest unsupported operation");
              if (true) throw new UnsupportedOperationException();
              return false;
          }

      to always return "false" for portlets when checking whether Async is supported.


          public boolean isAsyncSupported(){
              log.info("Asynchronous servlet API not currently supported in portlets");
              return false;
          }

      2) Add an existing context parameter to all portlet examples to prevent the ICEpush from even checking:

      <context-param>
          <param-name>org.icepush.useAsyncContext</param-name>
          <param-value>false</param-value>
      </context-param>

      Long-term:

      I assume somewhere along the way that Async support in portlets would be desirable so we'd need to somehow provide that information in a portal environment in a non-standard way until it's available in a future portlet API.

        Issue Links

          Activity

          Deryk Sinotte created issue -
          Deryk Sinotte made changes -
          Field Original Value New Value
          Assignee Deryk Sinotte [ deryk.sinotte ]
          Hide
          Deryk Sinotte added a comment -

          The reason that this has just surfaced now is that Liferay (and the other portal containers we've tested against) have not typically supported the Servlet 3.0 spec. The checking that we do to see if the Servlet 3 async support is present won't currently work with portals as the portlet API doesn't expose the required methods. So in the short term, the context parameter can be used.

          Show
          Deryk Sinotte added a comment - The reason that this has just surfaced now is that Liferay (and the other portal containers we've tested against) have not typically supported the Servlet 3.0 spec. The checking that we do to see if the Servlet 3 async support is present won't currently work with portals as the portlet API doesn't expose the required methods. So in the short term, the context parameter can be used.
          Deryk Sinotte made changes -
          Salesforce Case []
          Affects [Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration]
          Hide
          Deryk Sinotte added a comment -

          Linking duplicate JIRA ICE-7628

          Show
          Deryk Sinotte added a comment - Linking duplicate JIRA ICE-7628
          Deryk Sinotte made changes -
          Link This issue is duplicated by ICE-7628 [ ICE-7628 ]
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #27333 Mon Jan 23 18:55:05 MST 2012 ken.fyten ICE-7683 - return default of "false" when checking isAsyncSupported in portals
          Files Changed
          Commit graph MODIFY /icefaces3/tags/icefaces-3.0.0/icefaces/core/src/main/java/org/icefaces/impl/push/servlet/ProxyHttpServletRequest.java
          Hide
          Deryk Sinotte added a comment -

          The isAsyncSupported method has been changed to always return false. This class is only used in portlets and the current behaviour is that, when running in portlets, the Servlet 3.0 async mode is note supported as there is no standard way to execute the methods from the Portlet API. This may change in the future or we may do something ourselves to make the information available.

          Show
          Deryk Sinotte added a comment - The isAsyncSupported method has been changed to always return false. This class is only used in portlets and the current behaviour is that, when running in portlets, the Servlet 3.0 async mode is note supported as there is no standard way to execute the methods from the Portlet API. This may change in the future or we may do something ourselves to make the information available.
          Deryk Sinotte made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Deryk Sinotte
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: