You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2015/03/27 22:26:53 UTC

[jira] [Assigned] (WICKET-5816) Apps can't use Application.setName instead of WicketFilter for e.g. JMX names

     [ https://issues.apache.org/jira/browse/WICKET-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov reassigned WICKET-5816:
---------------------------------------

    Assignee: Martin Grigorov

> 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
>
> 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/<12...@am-soft.de>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)