[
https://issues.apache.org/jira/browse/WICKET-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Grigorov resolved WICKET-5816.
-------------------------------------
Resolution: Fixed
Fix Version/s: 7.0.0-M6
6.20.0
> Apps can't use Application.setName instead of WicketFilter for e.g. JMX names
> -----------------------------------------------------------------------------
>
> Key: WICKET-5816
> URL: https://issues.apache.org/jira/browse/WICKET-5816
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-jmx
> Affects Versions: 6.18.0
> Reporter: Thorsten Schöning
> Assignee: Martin Grigorov
> Priority: Minor
> Fix For: 6.20.0, 7.0.0-M6
>
>
> I have an application which gets deployed multiple times into a Tomcat under
> different folder names, by only changing the absolute minimum configuration
> needed per application. Especially the web.xml is generic and doesn't change
> normally, which leads to each instance in Tomcat has the same application
> name, corresponding to the filter name for the Wicket filter used in web.xml.
> This becomes a problem if one wants to use wicket-jmx, because
> "org.apache.wicket.jmx.Initializer.init" exposes a gerneric
> "org.apache.wicket.app.[name]" in such and environment and the JMX console
> provided with at least Java 7 doesn't show each node exposed for all the
> hosted applications, but only one of them. This makes one unable to
> distinguish to which application the exposed host ultimately belongs. If I
> change the names of the Wicket filter in web.xml to something unique instead,
> the JMX console shows all exposed applications under their unique name.
> So I thought of setting a unique name using Application.setName automatically
> by creating a ServletContextListener, which will statically set some created
> name using the deployment folder name, which afterwards can be used in the
> ctor of my derivation of Application. The problem with this approach is, that
> currently WicketFilter always issues a call to Application.setName as well
> and that will error out if I already set the name before.
> While I do understand that may approach may be a somewhat hacky workaround
> for my deployment scenario, from my understanding of how WicketFilter behaves
> it shouldn't harm to let applications set their own name for whatever reason.
> Currently it's not just possible because WicketFilter wants to do it as well.
> What I propose is that WicketFilter first checks using Application.getName if
> a name has already been set druing application construction and in that case
> doesn't try to set it on it's own. This way applications could set it on
> their own depending on different criteria and the current behaviour of only
> setting it once, with WicketFilter as fallback, would be preserved.
> The relevant code in WicketFilter is the following:
> {code:java}
> public void init(final boolean isServlet, final FilterConfig filterConfig)
> [...]
> // locate application instance unless it was already specified during
> construction
> if (application == null)
> {
> applicationFactory = getApplicationFactory();
> application =
> applicationFactory.createApplication(this);
> }
> application.setName(filterConfig.getFilterName());
> application.setWicketFilter(this);
> {code}
> This has been discussed on the users list as well:
> http://mail-archives.apache.org/mod_mbox/wicket-users/201501.mbox/<121497384.20150120190...@am-soft.de>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
