Hi Tobias,

I haven't tested it with two .war files yet but I can see how to break this
approach too: add two Wicket applications in the same .war, i.e. two
<filter>s for two different applications.
The env-entry is shared for all servlets/filters in the .war.

I'll try to rework it to use the ServletContext now.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Mon, Mar 28, 2016 at 7:51 AM, Tobias Soloschenko <
[email protected]> wrote:

> Update:
>
> I finally got it working for me:
>
>
> https://github.com/klopfdreh/wicket/commit/dda71c9e5ce5135993df0ea85450d232f14e53c5
>
> @Martin: Would be able to also test it with two or more applications
> running on the same server?
>
> In your MetricsServlet.ContextListener you could easily write
> WicketMetrics.getMetricsRegistry() - The detection which application should
> be shipped is handled if you set up environment entries in each project.
> (see commit)
>
> https://dropwizard.github.io/metrics/3.1.0/manual/servlets/#manual-servlets
>
> kind regards
>
> Tobias
>
> Am 27.03.16 um 13:12 schrieb Martin Grigorov:
>
> Hi,
>>
>> The problem with -Dwicket.metrics.applicationName and the static variables
>> approach is that both cannot be used if you have two Wicket applications
>> in
>> the web server.
>>
>> There is no need to implement a custom Servlet. metrics-servlet already
>> provides it. We just have to make the MetricsRegistry available in the
>> ServletContext (attribute
>> "com.codahale.metrics.servlets.MetricsServlet.registry")
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sat, Mar 26, 2016 at 2:34 AM, Tobias Soloschenko <
>> [email protected]> wrote:
>>
>> Hi,
>>>
>>> I would prefer to stay by the Application.get(String) / Application.get()
>>> / static because it is more Independent and not bound to the webapp
>>> lifecycle. Currently we only rely on the servlet stuff in one metric -
>>> which is at least not required. Even in Wicket itself you should not
>>> access
>>> the HttpSession itself.
>>>
>>> But this is only my opinion - let us hear other suggestions.
>>>
>>> Maybe it is a good idea to implement a defaul servlet which can be
>>> configured and exposes the metrics / registry via http get - which uses
>>> the
>>> dropwizard metric servlet.
>>>
>>> kind regards
>>>
>>> Tobias
>>>
>>> Am 25.03.2016 um 22:51 schrieb Martin Grigorov <[email protected]>:
>>>>
>>>> Just moments after sending the mail I recalled that DropWizard provides
>>>> something similar:
>>>> https://dropwizard.github.io/metrics/3.1.0/manual/servlets/
>>>> So there is no need of a custom IResource.
>>>> We just have to make it easier to lookup the MetricsRegistry from
>>>> MetricsServlet - via the ServletContext.
>>>>
>>>> I wonder whether the ServletContext solution could be used instead of
>>>> the
>>>> Application#get(String) and static variable fallbacks. I.e. somehow to
>>>>
>>> get
>>>
>>>> a reference to ServletContext in Session#onInvalidate().
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Fri, Mar 25, 2016 at 10:48 PM, Martin Grigorov <[email protected]
>>>> >
>>>> wrote:
>>>>
>>>> Hi Tobias,
>>>>>
>>>>> Inspired by
>>>>> https://github.com/jooby-project/jooby/tree/master/jooby-metrics I
>>>>>
>>>> think
>>>
>>>> it would be nice if wicket-metrics provides a IResource that renders
>>>>>
>>>> JSON
>>>
>>>> with the current metrics per type/aspect.
>>>>> I.e. if /wicket/metrics/ is requested then it dumps something like:
>>>>>
>>>>> {
>>>>>   "SomeTimerAspect" : {min:.., max:..., mean:..., ...},
>>>>>   ...
>>>>>    "SomeCounterAspect" : {value:..},
>>>>>    ...
>>>>> }
>>>>>
>>>>> When /wicket/metrics/SomeCounterAspect is requested then :
>>>>> {"value": ...}
>>>>> is rendered.
>>>>>
>>>>> Do you think it is a good idea ?
>>>>>
>>>>> It will be useful for quicker checks of the current state.
>>>>>
>>>>> The application will have to mount it explicitly in MyApp#init().
>>>>>
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>>
>

Reply via email to