I sat in on Marcel Offermans’, Karl Pauls’ (both from luminis) tutorial titled “Building Secure OSGi Applications“. Marcel and Karl provided a good incremental discovery approach to the tutorial, starting with the pre-OSGi 4.0 way of managing permission and moving quickly into the state of the art. The take-away from this tutorial for me is that—if you need security in your OSGi application—ConditionalPermissions and BundleSignerConditions are the starting point.

The basic idea is that you can specify a permission that says, “only grant permissions X, Y, and Z to any bundle that’s signed by so-and-so”. You can say, for example, that only your bundles (i.e. the ones signed by you) can write to the file system, or control who can import certain packages (I haven’t tried this last one, so I’m guessing that a relatively fine level of granularity is supported). There’s other kinds of conditions, including BundleLocationCondition which lets you grant permissions (curiously enough) based on the location in the file system of the bundle. You can use this condition to match a bundle’s symbolic name, assuming that the standard of using the symbolic name as the bundle JAR’s name is followed. My intuition is that this isn’t as useful as conditions based on signers, but this may change as I spend more time looking at it.

At this point, it seems that permissions can only be specified programmatically. It seems to me that creating a bundle that lets you specify permissions declaratively shouldn’t be too much work. Marcel stated that he’s not aware of any open source projects currently looking at this.

The tutorial worked mostly from the command line (using Ant to build) which I found a little disturbing. Naturally, I got caught up in making it all work using the PDE and a launch configuration within Eclipse so that I could (easily) use the debugger (Marcel suggested that I just attach the debugger to the application invoked from the command-line). It was actually pretty easy to get this running using the PDE, but did require some reconfiguration of the provided example projects.

I’ll have to incorporate this into an example.

Normally, I like to make my unit tests so that they do not depend on external things running. As a general rule, I try to write tests that prove that the logic in my code works. While I care that communication between my application and, say, a database or application server works, it’s not my code that’s doing the communication, so I don’t tend to write unit tests that cover that. If I’m using something like Apache Jakarta Commons’ HttpClient to do some kind of communication via HTTP, I tend to write tests that confirm that the request (PostMethod or the like) is built properly by my code and that my code handles a return result correctly. With some layering it’s possible to structure you code so that these sorts of tests are easy to execute without actually doing the communication.

While I care that the HttpClient does what it’s supposed to, my unit tests tend to be more concerned with whether or not my code does it what it’s supposed to. Sometimes I will write some unit tests for frameworks that I use, but I tend to try and keep these tests isolated. But that’s a story for later.

The other day, I was inspired to write some unit tests that actually do the live communication between my Eclipse plug-in and an application server via HTTP. Setting this up is surprisingly easy using the Jetty and OSGi HTTP service bundles that’re already included with the workbench.

I added the following two methods to my JUnit 4 test class:

@BeforeClass
public static void startServer() throws Exception {
	Dictionary settings = new Hashtable();
	settings.put("other.info", SERVER_NAME);
	settings.put("http.port", 0);
	JettyConfigurator.startServer(SERVER_NAME, settings);

	ServiceReference[] reference = Activator.getDefault().getBundle().getBundleContext().getServiceReferences("org.osgi.service.http.HttpService", "(other.info=usagedata.upload.tests)");
	Object assignedPort = reference[0].getProperty("http.port");
	port = Integer.parseInt((String)assignedPort);

	tracker = new ServiceTracker(Activator.getDefault().getBundle().getBundleContext(), reference[0], null);
	tracker.open();
	HttpService server = (HttpService)tracker.getService();
	server.registerServlet(GOOD_SERVLET_NAME, new GoodServlet(), null, null);
	server.registerServlet(BAD_SERVLET_NAME, new BadServlet(), null, null);
}

@AfterClass
public static void stopServer() throws Exception {
	tracker.close();
	JettyConfigurator.stopServer(SERVER_NAME);
}

This code creates an HTTP server, asking the server to find an available port (which my client code needs to complete the communication) and then registers some servlets.

Some bundles have to be added to my test fragment (I tend to build unit tests for plug-ins in fragments):

• javax.servlet
• org.eclipse.equinox.http.jetty
• org.eclipse.osgi.services

In this example, I’m adding two servlets to the server, one that does good things and one that does bad things. The servlets are mockups of the real things that exhibit very specific behaviour for testing purposes. The code that I’m testing invokes these servlets via the aforementioned HttpClient framework.

I’m still not convinced that this is exactly what I want to do (I certainly have some Law of Demeter issues to work out with it), but it works well. The best part is that my unit tests can be easily automated since they don’t have to depend on some external thing being properly configured.

I’ve managed to pick up some extra responsibilities for the upcoming JavaPolis 2007 conference in Antwerp, Belgium. In addition to the talk on Mylyn that I’ve been planning to do for a while now, I’ve recently been coerced (in a relatively nice way) into delivering a three hour “IDEs in Day” slot. “Three hours of talking about Eclipse”, you say, “how hard can that be?” The wrinkle is the topic: “Eclipse and Java EE 5 development”.

To be honest, I’m not sure how big a deal this is going to be. I have spent a fair chunk of my life doing Java EE development using Eclipse, so I feel pretty confident that I can provide a good experience to those in attendance. The problem is that I haven’t really done very much with Java EE in the past two years, and I assume that at least some things have changed. I assume that servlets and JSPs are still interesting. Are people still using Struts? Has JSF made the big time yet? Are EJBs still interesting? Web services anyone? I imagine that Spring has to be high on the list of technologies people want to hear about. What have I left out?

Clearly, Web Tools is the focal point of this talk. However, I think that I’ll spend at least some time talking about Equinox as a server and on a server. There’s probably some room to talk about EclipseLink and Dali (JPA). It might be good to pull out ATF; folks can’t get enough of that Ajax stuff these days…

So… those of you who are doing Java EE development, what are the Java EE topics that people care about? What should I cover in this talk?

In this podcast, Jeff McAffer, Eclipse Equinox Project Lead, discusses Eclipse membership in the OSGi Alliance, the factors motivating the adoption of OSGi as the component model for Eclipse, the cool places that OSGi turns up, and the rosy future of OSGi and Equinox.

Unfortunately, the recording quality of this podcast isn’t as high as I’d like, but the content is good. You should be able to access the podcast here (the link may be temporarily broken while it replicates to our mirrors).

On a related note, I’ve added a podcast feed to the Eclipse Resources page. If you scroll way down on the right, you’ll see a box containing icons that can hook the feed up to your favourite feed reader. Or you can just access the feed here.