[jira] Commented: (WICKET-2118) Application adds a ComponentInstantiationListener that I don't want and can't remove

["Willis Blackburn (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675665#action_12675665 ] 

Willis Blackburn commented on WICKET-2118:
------------------------------------------

Thanks.  I'll try WicketTestCase.

W





> 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.