Eclipse Debugger, part II

As I said in the Part I, this time I will focus on the Hit Count property and the Conditions of breakpoints. If you go to the breakpoint's properties (right click on the breakpoint and choose Breakpoint properties... option) you will see two interesting options:

Hit count

When we enable the Hit Count and give some positive integer value X the breakpoint will suspend the execution when it would be hit Xth time.
Lets illustrate this with example. If we consider the following code:

and we set the Hit count of the breakpoint (look at the picture above to see where the breakpoint is placed) to 7 we will find the following output in the Console view before the execution is suspended:

So as you can see the execution was suspended when the breakpoint was hit 7th time.

Conditions
Sometime everyone faces the situation when we want a breakpoint to be active only if some condition is fulfilled (e.g. we go in the loop through a 1000 elements list o people's names and we want to debug this loop for a particular name and we don't want to go 1000 times through this loop). To see how it works let's take the same code and let's set the condition the following way:
In this case the output in the Console view will look as follows:
The given condition is evaluated in the context of the breakpoint, so we can use all the variables that are available the context. Of course you don't have to use the numerical conditions, any expression that gives boolean answer can be used!

Eclipse Debugger, part I

Last semester I had some classes with students during which they had to prepare some easy projects. One of my requirements was that the project had to be implemented in Java, hence every team used Eclipse as an IDE. In my discussion with students it came out that a lot of them prefer debugger from Visual Studio over debugger from Eclipse. I was pretty surprised as I had a chance to use the VS debugger a lot in one of my projects and it didn't make good impression. When I got into details during the discussions it looked like the students had no idea about many features of Eclipse debugger and after some time some of them agreed that it is better then VS debugger.
This situation made me think that there is a need for some kind of tour through Eclipse debugger's features to share our knowledge about this great tool. Every week I will try to write a little bit about one of the debuger's aspect. If you have any hints or hacks for the debugger let me know - we can learn from each other!

Types of breakpoints
I would like to start with different kinds of breakpoints that are available in the debugger. We can use:
- line breakpoint
- method breakpoint
- field breakpoint
- class breakpoint
- java exception breakpoint
I guess that most of us use usually the first type and we tend to forget about others, however, that often can come very handy.

Line breakpoints
The post popular ones, so I won't get into the details. They make the execution pause whenever the given (marked as breakpoint) line is hit. Breakpoints like this can be created by clicking the ruler on the line we want to put the breakpoint on.
Method breakpoints
This kind of breakpoints pauses the execution whenever the processing enters or/and exists the given method. Breakpoints like this can be created by clicking the ruler on the line where the name of the method in the declaration of the method is written.
When we look to the breakpoint properties (right click on the breakpoint and choose Breakpoint Properties...) we will find the option to activate the breakpoint on method entry or/and exit:
Field breakpoints
Field breakpoints pause the execution whenever the given field is read or/and modified.
In the breakpoint properties we can set when the breakpoint is active:
Class breakpoints
These breakpoints pause the processing when the given class (or interface) is loaded by the JVm for the first time.

Java exception breakpoints
Allow to pause the execution of the application when particular exception is thrown. They can be set in the Breakpoints view. Choose Add Java Exception Breakpoint option:
and give the name of the exception you want to monitor:
In the end in the breakpoint properties you can set if you want this breakpoint to be active on caught or/end uncaught exceptions or maybe on subclasses of the given exception:

Did I miss any kind of breakpoints?

Next time I will try to write about the Hit count option and the breakpoints' conditions.

OSGi example = Spring Dynamic Modules + Equinox Declarative Services

Well, it took me a while to came up with that example.
As I am working on design of some fancy spring osgi equipped application some research was needed to check how and if it works as described ;).
But why not to make this more interesting and add some integration to this deliberations.

Summary

In this post I am going to show how to integrate Spring DM and OSGi DS (Equinox implementation). The only purpose for the code is to show that it is possible. It is only OSGi powered version of helloWorld software :D

What can be useful ?

• Eclipse IDE
  
• Maven
  
• Spring tooling set
  
• Maven tooling set
  
• cup of coffee :D
  

Main idea

As it was late in the night usability of the example is not catchy :D "hello" here "hello there" but the main idea is to show that it works :D.
Ok so we have 3 bundles. Two of them are using declarative services and the last one is using spring to provide it services :D

Programmer notes

First thing to mention. To build spring bean I am using maven. As you all know there is something called maven project structure. The best place to store META-INF is resources directory in src catalog. Don't do it this way. To make bundle visible for PDE tooling we need to store META-INF in the root of the project. Of course this requires changes in pom.xml project description.

As we have it visible as a bundle let me add some content.
First our service:

package nugae.spring.example;
public interface IHelloService {
  void sayHello();
}

It has its implementation in nugae.spring.example.impl package.
Next we need to define our service definition. It is recommended to split osgi and beans definition.


I assume that you may know standard bean definition so I will only focus on the osgi definition (component-osgi.xml):

Basically, saying that we deliver some service can be done with this declaration:

<osgi:service id="springService" ref="helloService" interface="nugae.spring.example.IHelloService" />

At the moment (in theory) we have our service (and bundle) ready to deployment.

Lets move then to our declarative services. As I've mention we'll add consumer and another provider bundles.
It is worth to mention that in eclipse 3.5M3 we have DS tooling available in PDE.

Declaring service using DS is nothing more complicated than using spring approach.
Neither specifying services required.

So what we have here ?
We just specified that our bundle requires two services (one delivered by other DS bundle and second provided by Spring bundle.

So let bring it to life :D

To bring the DS functionality to our target platform we need some bundles (can be checked out from :pserver:anonymous@dev.eclipse.org:/cvsroot/rt):

The simplest way to run spring osgi support is to use target provided by spring framework.

It contains all required bundles.

Conclusions

It works. Well I am surprised cause sometimes not everything work as described ;).
I think that OSGi brought new quality to developing java application. The level of freedom we've using different approaches make it even more attractive.
If you want to run this example (hopefully you will be able following this post)
source codes can be downloaded from here.