Change the naming strategy of the simons

[Dani]

Hi all,

I`m using JavaSimon to monitor some business services of my JEE application, based on Spring. As i can't place the @Monitored annotation in the code which is going to be monitored i've used the second choice described in the wiki (I think the second choice is better because it doesn't impact already existing code). How can i change the naming strategy of the simons? I have read the wiki but i'm not sure how to do it.

Simon name defaults to `fully.qualified.ClassName.methodName`, this can be customized 
  - with annotation attributes (see javadoc for more).
  - injecting a different stopwatch source in the `MonitoringInterceptor`, you may extend the default one: `SpringStopwatchSource`

How should i inject a different SpringStopwatchSource in the interceptor?

Thank you very much

Best Regards

[Gérald]

Yes you're right.
SpringStopwatchSource is basically a function which gives the Stopwatch associated to any MethodInvocation, from there you can customize your Simon naming scheme. The MonitorSource interface plays the same role that TransactionAttributeSource for transactions or MethodSecurityMetadataSource for security access controls.

Gérald

[Richard Richter]

Welcome Dani

I have to say you nearly got me on this one. :-) However it seems that
MonitoringInterceptor has this constructor:

public MonitoringInterceptor(MonitorSource<MethodInvocation,
Stopwatch> stopwatchSource) {
this.stopwatchTemplate = new
StopwatchTemplate<MethodInvocation>(stopwatchSource);
}

That means, that adding constructor arg into this bean definition shoudl help:

<bean id="monitoringInterceptor"
class="org.javasimon.spring.MonitoringInterceptor">
<constructor-arg>
<bean class="sk.posam.cruz.FunnyStopwatchSource"/>
</constructor-arg>
</bean>

My quick and dirty and probably not quite threadsafe source (but made
just for you ;-)):

package sk.posam.cruz;

import org.aopalliance.intercept.MethodInvocation;
import org.javasimon.SimonManager;
import org.javasimon.source.AbstractStopwatchSource;

public class FunnyStopwatchSource extends
AbstractStopwatchSource<MethodInvocation> {
private int counter = 0;

public FunnyStopwatchSource() {
super(SimonManager.manager());
}

@Override
protected String getMonitorName(MethodInvocation invocation) {
return "whatever." + invocation.getMethod().getName()+ '.' + counter++;
}
}


I have to say I learned something new now as well about our lib. ;-)
Can you please confirm success so we can celebrate with you?

Cheers

Virgo

> --
> You received this message because you are subscribed to the Google Groups "javasimon" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to javasimon+...@googlegroups.com.
> To post to this group, send email to java...@googlegroups.com.
> Visit this group at http://groups.google.com/group/javasimon?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Gérald]

Something like the following should work:

<bean id="monitoringInterceptor" class="org.javasimon.spring.MonitoringInterceptor">

    <constructor-arg>
        <bean class="com.mycompany.myproject.MySpringStopwatchSource"/>
    </constructor-arg>
</bean>
<aop:config>
    <aop:pointcut id="monitoringPointcut" expression="execution(* com.mycompany.myproject
.*Service.*(..))"/>
    <aop:advisor advice-ref="monitoringInterceptor" pointcut-ref="monitoringPointcut"/>
</aop:config>

Gérald

[Dani]

Hi guys,

Fortunately i can confirm you that it worked :D . Now i´m able to change the name strategy, giving a different name for the same monitored object depending upon a functional criteria.

<bean id="stopwatchSource" class="com.mycompany.myapp.MyStopwatchSource" scope="prototype"/>

<bean id="monitoringServices" class="org.javasimon.spring.MonitoringInterceptor">
        <constructor-arg ref="stopwatchSource"/>
</bean>

I think scope="prototype" could solve the non thread-safe problem

Thank you very much!

[Richard Richter]

Good to hear that it works.

Never mind thread-safety of my "prototype" implementation :-) it
supposed to be a joke. Scope would not fix it because the interceptor
itself is used in multitude of threads. That shared int variable must
be synchronized somehow. But I guess that your strategy does not need
any shared state.

Cheers