Hi Tobias,

Good work!

I've added some comments to the PullRequest (
https://github.com/apache/wicket/pull/164).

I am not a big fan of auto-generated code (AOP) but I agree this is the
most unobtrusive way to provide such kind of metrics.

This module doesn't depend on Wicket 8 so it could be used with earlier
versions too. I would suggest to add it to WicketStuff so people can start
using it now and report bugs and ideas for improvements.
Making it possible to enable/disable specific metrics with settings and to
add custom aspects would make it a very good candidate for Apache Wicket
module!

But let's wait for some more opinions!



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

On Fri, Mar 11, 2016 at 10:12 PM, Tobias Soloschenko <
[email protected]> wrote:

> Changes are made - I also add a chapter in the Wicket User Guide! The new
> measure functionalities are great.
>
> So if user now do time expensive operations in constructors of components
> - metrics will show it! :-D
>
> I also managed to get Graphite working with wicket-metrics and had a look
> at measures in the web interface (instructions are also in the guide)
>
> It is awesome!
>
> kind regards
>
> Tobias
>
> > Am 11.03.2016 um 08:41 schrieb Francois Meillet <
> [email protected]>:
> >
> > Thanks Tobias !
> >
> > Very good.
> >
> > François
> >
> >
> >
> >
> >
> >
> >
> >
> >> Le 10 mars 2016 à 21:39, Tobias Soloschenko <
> [email protected]> a écrit :
> >>
> >> Hi all,
> >>
> >> I just want to discuss a new module I would like to see in Wicket. It
> is mentioned in the list of ideas in Confluence for Wicket 8:
> >>
> >> https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> >>
> >> The Module is going to provide metrics to see how often requests have
> been handled from a webapp, how many render calls have been processed and
> other metrics:
> >>
> >> https://github.com/klopfdreh/wicket/tree/wicket_metrics
> >>
> >> I used the framework mentioned in the Confluence article and did a lot
> of research not to create a big performance and code impact because of
> changing every class in Wicket Core.
> >>
> >> As you can see in the commits I used AspectJ. To get the Code working
> for you, you have to do the following steps:
> >>
> >> 1. Fetch the branch
> https://github.com/klopfdreh/wicket/tree/wicket_metrics
> >>
> >> 2. Just drop the jars of aspectjrt and aspectjweaver into the tomcat 8
> lib folder
> >> http://mvnrepository.com/artifact/org.aspectj/aspectjrt/1.8.8
> >> http://mvnrepository.com/artifact/org.aspectj/aspectjweaver/1.8.8
> >>
> >> 4. Add the java agent to the jvm start options:
> -javaagent:/pathToServer/lib/aspectjweaver-1.8.8.jar
> >>
> >> the metrics dependency is shipped with the project
> >>
> >> 5. Add the maven dependency wicket-metrics to your project (and install
> the snapshot locally before) and write WicketMetrics.startJmxReporter(); in
> your applications init();
> >>
> >> 6. Do a request to your project
> >>
> >> 7. Open jvisualvm and the tomcat process and have a look at metrics
> mbeans (mbean plugin has to be installed)
> >>
> >>>>>> So now the reason why I used Aspectj:
> >>
> >> 1. The metrics code does not pull down the performance because of a lot
> of additional method invocations if not needed
> >>
> >> 2. If the metrics project is not resolved Wicket acts like nothing
> changed
> >>
> >> 3. Because of aspects also components written by the developers are
> also measured. So if a component extends Component the render method and
> the constructor calls are measured (for example). The developer dont have
> to take care of the statistics (See example)
> >>
> >> 4. It is clearly visible which Aspect is providing metrics about a
> component and you dont have to dig through the whole Wicket Code to find
> the measurement implementations
> >>
> >> 5. If there is an error in the statistics they can be turned off easily
> >>
> >> Example class:
> >>
> https://github.com/klopfdreh/wicket/blob/wicket_metrics/wicket-metrics/src/main/java/org/apache/wicket/metrics/aspects/ComponentAspect.java
> >>
> >> In my opinion this is the right way to implement it - even if this
> means to do a little setup before. (jvm-parameter,copy jars)
> >>
> >> Just try it out and let me know what are the results! :-)
> >>
> >> kind regards
> >>
> >> Tobias
> >
>

Reply via email to