There’s been a lot of hype around OSGi over the last year or two in the enterprise space. Last year even Caucho dallied with adding OSGi support to Resin, though we’ve abandoned the idea in the meantime. In this post, I’ll tell you what’s cool about OSGi, why we were initially attracted to it, why we eventually dropped it, and what we did instead. The more I talk to enterprise developers who’ve actually used OSGi, the more I hear this same story.
Archive for the ‘Engineering’ Category
I’ve put together a CanDI binding pattern tutorial (pdf) for four major binding patterns: services, resources, startup, and plugin/extensions.
Focusing on common CanDI patterns should show how CanDI is used in full applications like SubEtha maillist manager, and avoid the temptation to focus on complicated features that only 1% of applications would ever need.
In the tutorial, the key CanDI classes are:
- @Current - the service and unique bean binding annotation.
- @BindingType - the resource custom binding annotation used for declarative injection.
- Instance<T> - the extension/plugin iterator and programmatic bean factor.
- @Any - the special annotation for extension/plugin matching of any registered beans
Gavin King’s announcement is on his wiki.
Although the external annotations and classes are pretty similar (except for a major package change), the internal SPI has changed radically, so it’s quite a bit of work for me to keep up. A version based on for Resin 4.0.1 should be possible, though.
As a quick introduction to pomegranate (I’m crushed for time today), here’s a quick diagram that shows the basic module structure for a typical pomegranate configuration.
Pomegranate is designed to solve the module versioning and classloader issues from an enterprise-application perspective. Although we’re doing a bit of classloader magic behind the scenes, the developer perspective is fairly simple and clean:
- remove jars from your .war
- drop them in Resin’s project-jars directory
- declare jar dependencies in Maven .pom files
- import them to your web-app with WEB-INF/pom.xml or in your resin-web.xml
Pomegranate resolves the module versions, and builds a classloader graph for the web-app. The module graph looks like the following:
Studying the source code for a full application is the best way to really understand a technology like Java Injection (CanDI, JSR-299). Fortunately, Jeff Schnitzer, Scott Hernandez, and Jon Stevens have created a subetha mail, an open-source Java implementation of a mail list manager (like mailman) using CanDI extensively. Because subetha is also a sophisticated JavaEE application using EJB @Stateless beans, JMS queues with EJB @MessageDriven beans, servlets, and Hessian remote services, it’s a great overall application to study.
Ever since Google App Engine (GAE) supported Java, it has opened a slew of other languages that GAE indirectly and unofficially supports. PHP is one of them through Quercus, our 100% Java clean-room implementation of the PHP language.
Today I had a Resin user ask about the Resin watchdog and how it works. We’ve got some documentation, but I thought I’d show an example here in case you’ve never had a chance to try it out or were confused. I’ll show the actual command line input and output that you’ll see. After that, I’ll also talk about a feature we’re considering adding watchdog which we’d like feedback on.
We use WordPress for this blog and I recently upgraded to the 2.7.1 version. The developers have started using a .htaccess file with Apache mod_rewrite rules, so we need to emulate that to support certain things like permalinks. This is a quick and trivial example, but it gives a glimpse at our new rewrite dispatch syntax in Resin 4.
By adding Java to their App Engine, Google has opened the door for a whole slew of languages that have been implemented on the JVM, now including PHP via Quercus. For the last couple of weeks, I’ve been looking at Google App Engine and what its possibilities are for Quercus. Some folks from a PHP shop in Britain got Quercus running, but the version they were using was pretty old and seemed to come from a bizarre cross slice of our SVN repository. We wanted to make sure that the current version of Quercus runs on GAE with all its performance and compatibility enhancements. So Scott created a GoogleQuercusServlet just for the task. I wrote up how to get started using Quercus on GAE and some notes about what PHP can and can’t do within GAE at the moment.
This week, I’ve been prepping for a talk on Quercus in which I promised to show a demo of Spring MVC using a PHP view. So that means that I actually had to do it. Turns out it was quite easy and PHP makes for a very nice, compact view technology for Spring MVC. This is a bit of tease since the code for this won’t go out until at least next week, but since a number of people have been asking for this a while, I thought I’d give a preview…