[
https://issues.apache.org/jira/browse/WICKET-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675707#action_12675707
]
Igor Vaynberg commented on WICKET-2118:
---------------------------------------
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.
> Application adds a ComponentInstantiationListener that I don't want and can't
> remove
> ------------------------------------------------------------------------------------
>
> Key: WICKET-2118
> URL: https://issues.apache.org/jira/browse/WICKET-2118
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.4-M3
> Environment: OS X 10.5.6, Java 1.5.0_16
> Reporter: Willis Blackburn
> Assignee: Juergen Donnerstag
> Fix For: 1.4-RC3
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
