[
https://issues.apache.org/jira/browse/WICKET-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675733#action_12675733
]
Willis Blackburn commented on WICKET-2118:
------------------------------------------
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
> 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.
