Posted by ss141213
on June 4, 2009 at 3:29 PM PDT
I just put back an initial implementation of OSGi EEG RFC #66 in GlassFish workspace that allows web applications (war files) to be deployed as OSGi bundles and there by taking advantage of OSGi platform as well as Java EE platform.
Since the OSGi-fication of GlassFish started, the initial response was very encouraging, but we were often asked as to how we planned to expose the benefits of OSGi platform to end users in a more direct way. We are committed to making this possible as is evident from the following quote from our initial proposal : "If GlassFish can benefit from OSGi, why not applications deployed in GlassFish? Application developers would like to use sophisticated versioning, class loading, dependency management and component model of OSGi. There is a growing demand for servers that expose such facilities to application developers. So, we shall investigate the use of OSGi by applications." I am glad to say that we have made considerable progress in this area. I just now put back a very preliminary implementation of OSGi EEG RFC #66 in GlassFish workspace that allows web applications (war files) to be deployed as OSGi bundles and there by taking advantage of OSGi platform as well as Java EE platform. Web applications and OSGi is a subject which is being actively discussed in OSGi Enterprise Expert Group (EEG) as RFC #66. As I said, what I have put back is just the start. Basic servlet. JSP, JSF, JDBC, JNDI, etc. works. Injection should work, but I have not tried yet. I know for sure JPA does not yet work as JPA classloading requirements conflict with OSGi's. Work is in progress to resolve it - stay tuned. So, how do you use these features in GlassFish? There are basically two starting points: a) You have a plain vanilla war file. b) You have a war file that has OSGi metadata in it. In the former case, you have to somehow instruct the server that it has to add necessary OSGi metadata to the war file. You should also be able to customize the transformation step. It is achieved by use of a special URl protocol called webbundle together with use of URL query parameters. The server has a custom URL handler for this protocol and it does an in place manifest rewrite when it encounters this scheme. To use it, you can do something like this in GlassFish:
telnet localhost 6666
(telnet support in GlassFish is provided by use of remote shell as described here .) The above commands will make your web app available at localhost:8080/mybundle/. Now you can control the life cycle of the web app via the OSGi bundle. e.g., if you stop the bundle by issuing stop #bundle_id, the web app gets undeployed. To deploy it again, issue the start command. In the latter case, i.e., case #b above, you just have to add a specific meta-data called Web-ContextPath in the manifest.mf to mark the OSGi bundle as a Web Application Bundle, (WAB) in short. Once you have done that, you can either install and start by running the shell commands without using webbundle protocol or simply copy the bundle to glassfish/domains/domain1/autodeploy-bundles/ dir. How this directory works is already described in a previous blog . Although I want to write more now, it's pretty late here. SO, catch you soon with instructions to install the new feature in GlassFish with some concrete example. Thanks.