Wicket
  1. Wicket
  2. WICKET-2118

Application adds a ComponentInstantiationListener that I don't want and can't remove

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4-M3
    • Fix Version/s: 1.4-RC3
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      OS X 10.5.6, Java 1.5.0_16

      Description

      I am writing a unit test that requires that I instantiate a Component. When I instantiated the Component, I discovered that it requires an Application attached to the current thread. No problem: I instantiated the Application and set it in the thread using Application.set.

      However, at this point I saw the following error: "java.lang.IllegalStateException: you can only locate or create sessions in the context of a request cycle."

      The problem is that Application, in its constructor, adds a component instantiation listener that delegates the discovery of the authorization strategy to the session, and if the session isn't present, it wants to create one. I tried setting up a session, but that requires a request cycle, which requires a request and response, etc.

      I see two issues here:

      1. Application creates a component instantiation listener that cannot be removed. The only way to remove it is to have a reference to the listener and pass it to removeComponentInstantiationListener, but the listener is created anonymously inside the Application constructor.

      This could be solved by creating a method called something like initializeDefaultComponentInstantiationListeners that a subclass could override with a no-op.

      2. The listener that Application creates always creates a Session, even though Session's default implementation of the method that Application calls just delegates back to Application.

      This issue could be resolved by the solution to #1, since applications that know that they're not going to override the authorization strategy on a per-session basis could add an authorization listener that didn't create a session.

        Activity

        Hide
        Juergen Donnerstag added a comment -

        WicketTester and WicketTestCase does all that for you and makes testing Wicket apps fairly simple. I still refactored the code to provide a initializeComponentInstantiationListener().

        Show
        Juergen Donnerstag added a comment - WicketTester and WicketTestCase does all that for you and makes testing Wicket apps fairly simple. I still refactored the code to provide a initializeComponentInstantiationListener().
        Hide
        Willis Blackburn added a comment -

        Thanks. I'll try WicketTestCase.

        W

        Show
        Willis Blackburn added a comment - Thanks. I'll try WicketTestCase. W
        Hide
        Igor Vaynberg added a comment -

        Juegen, i have reverted the change to Application.

        it is very unsafe because a: it allows someone to bypass authorization strategy entirely and b: easy to make the mistake of not calling super and not having auth strategy installed.

        like you mentioned, we provide everything needed to easily setup a mock environment, so there is no need to make wicket itself more fragile.

        Show
        Igor Vaynberg added a comment - Juegen, i have reverted the change to Application. it is very unsafe because a: it allows someone to bypass authorization strategy entirely and b: easy to make the mistake of not calling super and not having auth strategy installed. like you mentioned, we provide everything needed to easily setup a mock environment, so there is no need to make wicket itself more fragile.
        Hide
        Willis Blackburn added a comment -

        Igor,

        Are you concerned that someone would maliciously bypass the
        authorization strategy, or accidentally? If accidentally, then the
        same person could just as easily forget to set the authorization
        strategy (leaving the default of "allow all") or write an
        authorization strategy that doesn't work very well.

        Anyway, the point isn't that there's no hook but simply that there's
        no way to avoid having Application create a session every time.

        W

        Show
        Willis Blackburn added a comment - Igor, Are you concerned that someone would maliciously bypass the authorization strategy, or accidentally ? If accidentally, then the same person could just as easily forget to set the authorization strategy (leaving the default of "allow all") or write an authorization strategy that doesn't work very well. Anyway, the point isn't that there's no hook but simply that there's no way to avoid having Application create a session every time. W
        Hide
        Igor Vaynberg added a comment -

        i am more worried about someone overriding the method in an application that already has an auth strategy setup, forgetting to call super, and effectively disabling it by doing something completely unrelated.

        components are tightly coupled to applcatio, session, and request cycle. there are more then a few methods on components that will not work without these in place - that is why we provide wickettester which makes installing all these dependencies trivial.

        Show
        Igor Vaynberg added a comment - i am more worried about someone overriding the method in an application that already has an auth strategy setup, forgetting to call super, and effectively disabling it by doing something completely unrelated. components are tightly coupled to applcatio, session, and request cycle. there are more then a few methods on components that will not work without these in place - that is why we provide wickettester which makes installing all these dependencies trivial.

          People

          • Assignee:
            Juergen Donnerstag
            Reporter:
            Willis Blackburn
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development