As it happens Peter Kriens and Neil Bartlett both set about doing the same thing, all our efforts completely independent of each other. In this post, I'll compare and contrast the three approaches.
Firstly, Peter and I both decided to use Declarative Services (DS), where as Neil decided to create a light-weight service driven API.
In that regard, the approaches fragment and it becomes difficult to compare Neil's approach with the approach taken by Peter and myself. The main advantage of the service driven approach is that you don't need to use DS. You create an instance of the service interface and register it, then the rest of Neil's code makes that implementation available as a Vaadin application. This is a great approach if you might not want to use DS and doesn't stop you from using it if you want. The main disadvantage here is that there is an extra dependency on the API that Neil has created.
With the DS approach there's no additional hard-dependency, though there is a dependency on DS implied. In both Peter's approach and mine, we simply extend com.vaadin.Application and mark the implementation as a component factory. After this, things differ slightly between my approach and Peter's.
My code looks for components with the property "component.factory=vaadin.app" and once I find matching component factories I take the "component.name" of the factory and use that for the HTTP alias against which to register the servlet that does the work. Peter's approach is to look for "component.factory=com.vaadin.Application/*" and take the name from the part represented by the wildcard. This seems like a more sensible approach, as the component name tends to be more unique and use a domain name type structure, if not the component classname, period. A classname is not really an appropriate HTTP alias.
Vaadin uses a fair amount of static resources. My view here is that in most cases a dedicated web-server should be used to handle static resources (e.g. Apache), in a classic n-tier setup where static content web servers sit in front of 'application servers'. As such I've created a second bundle called staticres which will proxy static resources from the Vaadin bundle, but the recommended approach is to use a web-server. Further more, if your app has additional static resources that are not in the Vaadin bundle then these can be added by creating a fragment containing those resources and setting the host to the Vaadin bundle. My "staticres" bundle won't know the difference.
However, this highlights another major difference between my approach and Peter's. In Peter's approach, he expects wraps the Vaadin jar and turns it in to an internal library, exporting it's packages to the container. However, the Vaadin is already a bundle, so this seems unnecessary to me. The additional downside of this is that if the Vaadin jar is updated by the Vaadin folks, then people using Peter's bundle will either need to rebuild it for themselves, or wait for Peter to release a new version. The approach I have taken allows people to update the Vaadin bundle independently of the OSGi code I've written.
The remaining differences between my approach and Peter's are at the code level. Peter's experience shines through showing much better concurrency handling and support for multiple HttpService implementations, where as mine only supports a single HttpService.
So in Conclusion, Vaadin must be an interesting technology (personally I love it) for three individuals to decide to skin that cat in their own way. While the DS approach I've taken is considerably different from Neil's service approach, there are definitely enhancements to what I have produced that I can make based on Peter's code. To summarise the pros and cons of all three:
Neil's approach:
+ no dependency on DS and does not preclude it either
+ not coupled to any specific version of Vaadin
+ lightweight easy to use API
- additional dependency on non-standard API
- no clear way to handle additional static resources
- may end up using DS anyway
Peter's approach:
+ well defined and sensible use of DS
+ high quality implementation
- no clear way to handle additional static resources
- tight coupling to a specific version of Vaadin
Brindy's approach:
+ not coupled to any specific version of Vaadin
+ additional static resources easily handled
- limited to one HttpService
- use of DS needs to be better defined
- needs better concurrency handling
If you're interested in working with Vaadin and OSGi and want a forum in which to discuss your ideas or get help feel free to join our Google Group.
