Would it be possible to get a working example of how to do this? Thanks, Dennis Crissman
> Subject: Re: Dynamically debugging services with aspects... > From: [email protected] > Date: Sun, 23 Jan 2011 19:34:09 +0100 > To: [email protected] > > Definitely, or, using the same method described below, you can also intercept > all EventHandlers that are listening to events. > > On 23 Jan 2011, at 15:55 , Angelo van der Sijpt wrote: > > > Ooh, nice method, I've had this problem before. > > > > To add to that, you could ease debugging (or at least, tracing of calls to > > EventAdmin) by attaching the method that calls this postEvent or sendEvent > > method, for instance by using > > result.append(Thread.currentThread().getStackTrace()[2]) > > > > I am aware that this will fail in certain environments, but in most > > situations it gives you an idea of 'where this message came from'. > > > > Angelo > > > > On Jan 22, 2011, at 3:18 PM, Marcel Offermans wrote: > > > >> For ACE-112 [1] I had to debug the events flowing through the system to > >> see if the events being sent were created and received correctly. Most > >> events (in ACE) are being sent asynchronously, which makes debugging by > >> setting breakpoints a bit more difficult, as setting breakpoints in > >> handleEvent() will not reveal the sender. > >> > >> One way to get more information is to "intercept" all calls to EventAdmin, > >> and the technique to do this is what I wanted to share with you in this > >> e-mail. > >> > >> What we can do is use the Dependency Manager to create an aspect service > >> on top of EventAdmin. An aspect can intercept all calls to services and in > >> your interceptor you can still delegate the calls to the original service. > >> Technically, this is being implemented using service rankings, which means > >> that consumers will automatically react to aspects. > >> > >> What I did was add the following to the Activator of the VaadinClient: > >> > >> manager.add(createAspectService(EventAdmin.class, null, 10, null) > >> .setImplementation(new EventAdmin() { > >> volatile EventAdmin m_eventAdmin; > >> > >> private String print(Event event) { > >> StringBuffer result = new StringBuffer(); > >> result.append("Event[ "); > >> String[] names = event.getPropertyNames(); > >> for (String name : names) { > >> result.append(name); > >> result.append('='); > >> result.append(event.getProperty(name)); > >> result.append(' '); > >> } > >> result.append(']'); > >> return result.toString(); > >> } > >> > >> public void postEvent(Event event) { > >> System.out.println("postEvent: " + print(event)); > >> m_eventAdmin.postEvent(event); > >> } > >> > >> public void sendEvent(Event event) { > >> System.out.println("sendEvent: " + print(event)); > >> m_eventAdmin.sendEvent(event); > >> } > >> })); > >> > >> When we create the aspect service, the first two parameters are the > >> service class and a filter condition (null here) we want to create aspects > >> on top of. For each service that matches the service name and filter, and > >> aspect will be instantiated of the class specified below. The third > >> parameters is the service ranking for this aspect. This is there because > >> you can also chain aspects on top of each other. The final option (null > >> here) is the name of the member that should be injected into the aspect > >> service (null means any member of the right class). > >> > >> The implementation is just one that intercepts all calls, prints the > >> event, and then delegates them to the real EventAdmin (which is injected > >> automatically). > >> > >> So it's quite easy to debug a service this way, and it's fully dynamic. > >> Even in a running production system, you can install a new bundle that > >> adds an aspect on top of an existing service and you can instantly > >> intercept all calls, and stop or uninstall the bundle again once you're > >> done. > >> > >> Greetings, Marcel > >> > >> [1] https://issues.apache.org/jira/browse/ACE-112 > >> > > > > >
