Some "boot" libraries of the NetBeans Platform need to be placed in Tomcat's common class loader. They are:
-rw-rw---- 1 fritz staff 255877 Jan 2 17:35 boot.jar
-rw-rw---- 1 fritz staff 619165 Jan 2 17:35 core.jar
-rw-rw---- 1 fritz staff 563443 Jan 2 17:35 org-openide-filesystems.jar
-rw-rw---- 1 fritz staff 23335 Jan 2 17:35 org-openide-modules.jar
-rw-rw---- 1 fritz staff 625986 Jan 2 17:35 org-openide-util.jar
For instance, you can put them in a tomcat-libs directory; in this case, modify the conf/catalina.properties file so there is this line:
This is an annoyance - could be also a problem in some cases (e.g. providers with virtualized hosts don't give you access to the Tomcat configuration). For sure it would be better if you could place these libraries under WEB-INF/lib, but trying that leads to very strange errors. Still investigating on this.
A Final Word of Wisdom
The thing works, and at least for the Wicket part I'm having it in production since a couple of months (the WebDAV and REST part are still in development). As usual, you must be very careful when dealing with class loaders, since they can lead to obscure errors when you don't expect (for instance, it suffices that a part of the frameworks you're using does a Class.forName(...) - see how I had to patch Milton, for instance). So, before going that way, prototype and test toroughly. Of course, if you only deal with FLOSS software, problems should be always trackable and fixable in some way.
One should also investigate how the thing scales - for instance, being the NetBeans Platform designed primarlily for the Desktop (= single user applications), it could contain bottlenecks when used with concurrent users. Only testing can tell - so far, so good, but I'm not running yet with a high number of concurrent customers. In my scenario, I think that I know quite well the NetBeans Platform so I could tweak it if necessary, and this little risk is worth while since I'm getting a huge code reuse (in any case, I've got a "backup plan" for my customer in case I find some blocking issue). In other scenarios, one might want to be more careful. For sure, using the NetBeans Platform in this way is an architectural choice that needs to be explored.
It is also to be said that the NetBeans Platform contains some unnecessary hardwired dependencies on Swing, for instance if you use the DataObjects. In this case, you will need to bring into your application some Swing-related modules to resolve that dependencies, even though they will be not used. Also in this case, I didn't experience problems, but you have to test it in our scenario.
Last but not least, it would be interesting to see how many parts of the NetBeans Platform can be effectively used in a server-side application. For instance, I'm not using Nodes - but they can be useful as well, as they associate actions (menus) to objects and could be used together with Wicket's AJAX capabilities to generate dynamic context menus. On the other hands I fear that they, being related to the single-thread model of Swing, could be a serious bottleneck. I guess this is matter for further investigation (and a further article).
For the record, I've proposed that the small adapter library is added to the PlatformX project. Also, I've submitted a speech proposal about these topics at JavaOne 2009 - so, if you like this article, please speak loud. ;-)