New Article: Modularizing Existing Web Applications With OSGi

Discussions

News: New Article: Modularizing Existing Web Applications With OSGi

  1. Today you can write a new web application and just run it with Equinox/Jetty or Felix http services. However, what if you need to keep evolving an existing web application and can't just stop and spend months rewriting everything to OSGi architecture? This article explores how you can build on an existing web application and adopt OSGi for web components without first having to rewrite the whole application. An example is provided using Tomcat 6 and Equinox. Read article
  2. Link is not working[ Go to top ]

    Link is not working
  3. Step 1, cut a hole in a box
  4. "Twelve easy steps?"[ Go to top ]

    Is it just me, or is that statement slightly offputting? I mean, as soon as it goes over something like SEVEN steps, it's no longer truly easy -- esp. when it wants Eclipse Web Tools experience in the first place. Ruckelshaus Petrie
  5. Re: "Twelve easy steps?"[ Go to top ]

    Is it just me, or is that statement slightly offputting? I mean, as soon as it goes over something like SEVEN steps, it's no longer truly easy -- esp. when it wants Eclipse Web Tools experience in the first place.
    Yes, especially when you can do the same in one step: pax-run "--profiles=war" war:mvn:org.apache.wicket/wicket-examples/1.3.0/war you have to wait for a while as the WAR gets downloaded - when you see Jetty output scroll past the console, surf to: http://127.0.0.1:8080/mvn_org.apache.wicket_wicket-examples_1.3.0_war just a short demo, but it shows this can be much simpler. for more details about Pax-Runner see: http://wiki.ops4j.org/display/ops4j/Pax+Runner (disclaimer: I'm a member of the OPS4J community)
  6. JSPs beside classes[ Go to top ]

    The article states : "In a classic WAR, you can isolate the module's classes in their own JARs but you can not keep the module's web resources in the JAR." This is not correct. Apps built with the web4j tool are allowed (and encouraged) to place JSP snippets directly beside the code that uses them. Why? Because its more modular, and allows package-by-feature. I think Wicket follows a similar style as well.
  7. Re: JSPs beside classes[ Go to top ]

    Uh... You can put resources in jars just fine. You could put them in the same jar or separate for that matter. You could put each class/resource set in their own jars. Or each class in its own jar and each resource in its own jar. The possibilities are endless! I can't believe someone who's trying to get OSGi working in a webapp wouldn't know that. The world's a strange place and gets stranger every day...
    The article states :
    "In a classic WAR, you can isolate the module's classes in their own JARs but you can not keep the module's web resources in the JAR."

    This is not correct.

    Apps built with the web4j tool are allowed (and encouraged) to place JSP snippets directly beside the code that uses them. Why? Because its more modular, and allows package-by-feature.

    I think Wicket follows a similar style as well.
  8. Today you can write a new web application and just run it with Equinox/Jetty or Felix http services. However, what if you need to keep evolving an existing web application and can't just stop and spend months rewriting everything to OSGi architecture?
    One thing that I still fail to see is why anyone would *want* to run everything in an OSGi architecture? And I am fairly sure that I will still need to reboot the container rather sooner than later - and the fact that Eclipse encourages me to restart Eclipse after installing a plugin does not make me more optimistic. The whole "using OSGi as an end user technology" smells a lot like reinvention of the wheel yet again.
  9. Today you can write a new web application and just run it with Equinox/Jetty or Felix http services. However, what if you need to keep evolving an existing web application and can't just stop and spend months rewriting everything to OSGi architecture?

    One thing that I still fail to see is why anyone would *want* to run everything in an OSGi architecture? And I am fairly sure that I will still need to reboot the container rather sooner than later - and the fact that Eclipse encourages me to restart Eclipse after installing a plugin does not make me more optimistic.

    The whole "using OSGi as an end user technology" smells a lot like reinvention of the wheel yet again.
    This "reboot not required" meme dilutes what I see as the key benefit of OSGi: modularity. By looking at a bundle's metadata I can immediately see what it needs and what it provides, compared to the current "hit and miss" approach to building the classpath for large applications (this really caused a lot of grief at one of my previous workplaces). The metadata also helps automate and verify deployments. When done right you shouldn't really be aware of OSGi at all, it should just be there in the background helping you manage your application - and hopefully maybe encourage re-use. And ideally any library that becomes OSGi-enabled can still be used in a classic app without requiring OSGi, at least that's what we managed to do with Guice... I also like the OSGi service model, though not the raw API. Disclaimer: I provide an open-source project that builds on top of OSGi services and I'm co-writing a book on OSGi in general - so feel free to take what I say with a pinch of salt :)
  10. I agree with what Stuart says about true modularity with the help of bundle metadata being the key benefit of OSGi versus old-style JARs. I guess in my article I should have at least referred to the great work done at ops4j with PAX. The example in the article shows that - thanks to the plug-in provided with it - I can RUN the app with one press of a button - the green "Run" button in Eclipse - no scripts to execute, no manual redeployment and certainly no 12 steps. Among other things, the servletbridge allows for tight integration of bundelized and non-bundelized JSPs. I used Wicket for two years with OSGi and having the html directly in the code directory was nice. I still prefer my JSPs in a WebContent folder though. In the sample app I am making web-enabled OSGi bundle look and behave like "mini-WARs". That means that it should be easy to bring such bundles to work with the upcoming OSGi RFC-66 specification, once it is finalized and implemented.
  11. Interesting article[ Go to top ]

    The ability to dynamically replace one part of application (demonstrated on switching CSS modules) looks very interesting, I must say. Unfortunately, the last point (#12) doesn't work for me. After stopping or uninstalling the org.rsp.example.http.jsp2_1.1.0 bundle I got 404 code on main page refresh, with no hint in Tomcat console what's wrong (no stacktraces in the console, perhaps the fact that it is also OSGi console blocks printing stacktraces).
  12. Disclaimer: I provide an open-source project that builds on top of OSGi services and I'm co-writing a book on OSGi in general - so feel free to take what I say with a pinch of salt :)
    What's the project and what will the book be called. Come on man, plug away. This is TSS.
  13. EJB Modularization[ Go to top ]

    Is there any way to apply OSGi on EJB applications? It would be nice if you could put business code in modules (OSGi bundles) and reload them at runtime without application restart. Our clients would appreciate if we didn't have to restart application (or server) for every installation. We're using WAS and I haven't found any examples of EJB+OSGi. Regards, Stipe