The bundle stuff is perhaps the most complete and best integrated at the moment. The TODOs basically revolve around the lifecycle stuff. UPDATE/INSTALL The install(URL) works and I don't think it would be hard to do the install(InputStream) you just need to copy the input stream somewhere, but this has relations to the persistence see below. The update has some very funny semantics (which is my least favourite part of the OSGi spec). This basically allows you to update the bundle contents but the classloading changes not effected until somebody does PackageAdmin.refreshPackages() This seems like a recipe for all sorts of classloading leaks, since I doubt any user bundle will understand the full scope of how this should be done properly. START/STOP The basic start/stop is working, but there are other options like lazy activation that are not implementated. This also appears to have relations to the peristence and the run level service so these can be implemented when those are. LOCKING There is a requirement in the spec that when somebody is controlling the lifecycle the bundle should be locked. Other requests on the bundle, whether lifecycle or service operations should wait. I haven't implemented this since this is also an outstanding item on the jboss deployment layer and will need to play nicely with that to avoid deadlocks. RUN LEVEL/PERSISTANCE This stuff should be implementated on top of the profile service within jboss, but we might want to provide vanilla implementations of this for standalone usage? getDataFile() I haven't implemented this optional method. I don't think it would be hard, it's just not a priority. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249973#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...