javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1402

UIViewRoot SystemEventListeners added after PostAddToViewEvent not notified

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.1
    • Fix Version/s: 2.0.3-b01
    • Component/s: event processing
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,402

      Description

      Background:

      See the tail end of issue 1383 [1] for the full history.
      High level details:
      -----------------------------------------

      Ryan,

      Thanks again for your reply. You say 'in the current implementation', but I
      suppose the big question is what is in the spec? The way it works at the moment
      means it cannot support my use case. Specifically:

      1. Custom components that want to 'safely' manipulate the component tree (ie.
      before it gets serialized)
      2. Custom components that want to nest instances of themselves during that
      manipulation

      I was under the impression PostAddToViewEvent was created for the sake of point
      1. It does not seem a stretch to ask it to work for point 2. But if not, is
      there some other way?

      Regards,

      Richard.

      ===========================================

      The spec is silent in this area. That said, as I see it, the problem with
      supporting option two is due to the API itself.

      The Application object is a consumer of the List<SystemEventListener> returned
      by UIViewRoot.getViewListenersFor(Class<? extends SystemEventListener>. I
      think it would have been better to return an Iterator here instead of a List so
      that we could enforce that modifications to the underlying data structure would
      be through the subscription mechanism.

      Since the API calls for a List, that means we have to support all of the
      modification mechanisms supported by that interface. Assume for a moment that
      we switch the List implementation that supports all of the modification methods
      and the Iterators that it returns are not fail-fast. So, for the simple case,
      we could support iterating over listeners that were either added via the event
      subscription methods or if the List was manipulated and the listener was added
      to the end of the List. However, things start to fall apart if the listener was
      added at a specific index. That could mean the listener is never invoked at all
      by the iteration, or another listener could potentially be invoked twice.

      One possible solution to this would be to return an unmodifiable collection when
      getViewListenersFor() is called so that it's only possible to modify the
      underlying collection via subscription, but that goes back to my original point
      about the API exposing the List in the first place. Granted, the javadocs are
      silent as to whether or not the List to be returned is modifiable or not, but
      I'm sure if we changed it to be unmodifiable, we'd get complaints.

      As to an alternative, I'll have to think about it a bit more.

      ===========================================================

      Ryan,

      I completely agree with your reply. It is a complex issue and I don't have a
      good answer.

      I guess my high-level feeling is that Metawidget (http://metawidget.org) is a
      really good example of exactly the kind of highly dynamic component that led to
      the inception of events such as PostAddToViewEvent in JSF2: it was recognised
      JSF needed a 'safe' place to manipulate the component tree. But perhaps what
      was NOT recognised was that if that 'safe' place was via an event model, and
      there was not a safe place to manipulate the event model itself, then you could
      never have dynamic components that generated other dynamic components.

      My option 2 in my previous comment was understating the case: it doesn't have
      to be a dynamic component that creates an instance of itself. It will be any
      dynamic component that in turn tries to create another dynamic component.

      I'll think about it some more too...

      -----------------------------------------

      [1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1383

        Activity

        Hide
        Ed Burns added a comment -

        Fix checked in.

        Show
        Ed Burns added a comment - Fix checked in.
        Hide
        kennardconsulting added a comment -

        Hi Ed,

        Thanks for your continuing work on this.

        However I'm unclear why the choice of JSP or Facelets should impact this
        functionality. Shouldn't it work either way? Isn't JSP a legitimate choice
        (albeit deprecated for JSF 2)?

        Are you saying you can't/won't be fixing this for JSP-based pages? Why not?

        If so, can my component detect whether it is being used with JSP or Facelets so
        that it can decide whether it can reliably use this functionality?

        Richard.

        Show
        kennardconsulting added a comment - Hi Ed, Thanks for your continuing work on this. However I'm unclear why the choice of JSP or Facelets should impact this functionality. Shouldn't it work either way? Isn't JSP a legitimate choice (albeit deprecated for JSF 2)? Are you saying you can't/won't be fixing this for JSP-based pages? Why not? If so, can my component detect whether it is being used with JSP or Facelets so that it can decide whether it can reliably use this functionality? Richard.
        Hide
        kennardconsulting added a comment -

        Sorry - I should clarify: I am a component author, so it is unrealistic for me
        to dictate which view technology my users choose (JSP or Facelets). I need my
        component to work reliably in both (as I believe all JSF 2 component libraries
        are expected to do).

        Show
        kennardconsulting added a comment - Sorry - I should clarify: I am a component author, so it is unrealistic for me to dictate which view technology my users choose (JSP or Facelets). I need my component to work reliably in both (as I believe all JSF 2 component libraries are expected to do).
        Hide
        kennardconsulting added a comment -

        Original issue resolved. Resolving the 'JSP vs Facelets functionality' issue
        now part of https://javaserverfaces-spec-
        public.dev.java.net/issues/show_bug.cgi?id=636

        Show
        kennardconsulting added a comment - Original issue resolved. Resolving the 'JSP vs Facelets functionality' issue now part of https://javaserverfaces-spec- public.dev.java.net/issues/show_bug.cgi?id=636
        Hide
        Manfred Riem added a comment -

        Closing out resolved issue

        Show
        Manfred Riem added a comment - Closing out resolved issue

          People

          • Assignee:
            Ed Burns
            Reporter:
            Ryan Lubke
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: