[
https://issues.apache.org/jira/browse/WICKET-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juergen Donnerstag resolved WICKET-2118.
----------------------------------------
Resolution: Fixed
Fix Version/s: 1.4-RC3
Assignee: Juergen Donnerstag
WicketTester and WicketTestCase does all that for you and makes testing Wicket
apps fairly simple. I still refactored the code to provide a
initializeComponentInstantiationListener().
> 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.
