good points Kirk. Thanks for pointing this out. The Equinox focus on using Eclipse is, as you say, understandable. Interestingly some of us come at this quite a different way. For all intents and purposes most of us know little about J2EE but do know alot about bundles. So, the "Aha moment" was when you could just do a normal Eclipse launch of a set of bundles and have a mess of servlets and JSPs running in an embedded server (Jetty in this case). That means you can use all the funky development techniques normal to bundle development in Eclipse and then, with no fuss or muss (or waiting) get a server running. Web development made easy from a different angle.
As for examples that feature WARs, yes, that will be prevalent until there is a decent way of managing bundles on servers etc. There are several efforts underway not the least of which is the p2 work at Equinox (http://eclipse.org/equinox/incubator/provisioning). With such technologies you will no longer be reduced deploying whole WARs or typing cryptic commands in a console to manage your server. Jeff Kirk Knoernschild <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10/16/2007 10:58 PM Please respond to OSGi Developer Mail List <[email protected]> To OSGi Developer Mail List <[email protected]> cc Subject Re: [osgi-dev] war, jar, and Equinox I suppose it's a combination of a few things. Any of the useful examples I've found illustrating OSGi and web application development are always done using Eclipse and Equinox. I haven't found any useful documentation that illustrates how to embed Felix, etc. in a servlet container. There are a lot of really good examples on the Server-Side Equinox site ( http://www.eclipse.org/equinox/server/), but most of them assume you're using Eclipse as the IDE (for good reason, I suppose). While Eclipse is a wonderful IDE, for those new to OSGi, it's strength also serves as a weakness in that it shields the developer from so much of the underlying technology that you don't experience the value that OSGi provides. On top of that, most of the detailed examples assume you're embedding a servlet container (jetty) in Equinox, which I don't feel is the enterprise use case, as it's more likely that OSGi will be embedded within the application server. When embedding Equinox in a Servlet container like Tomcat, all of the examples use the ServletBridge, and a bridge.war is even provided that serves as a template project. Now, with the recent release of Eclipse RAP, the documentation is also centered around deploying a .war file ( http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.rap.help/help/html/intro.html ), and there's an explicit section labeled "WAR deployment". I can see where it would be easy to embed all the bundles directly in the WAR file when using the ServletBridge. After experimenting for a while, I dropped the bridge.war in the Tomcat webapps directly and then installed my bundles from the OSGi console. This was a real eye opener, especially after I got Jasper up and running and could include JSP pages within WAR files. It was a "WOW" moment, because it was characteristic of enterprise development. Since I did all this outside Eclipse, I really saw exactly what was happening. When you add it all up, I don't think the supporting documentation comes right out and says "...this is really going to change how you develop enterprise software systems. You'll no longer deploy individual web applications, but instead systems will be an assembly of bundles that come and go as necessary. In other words, WAR files are dead and JAR files are hip." Or something like that, but probably a bit more eloquent. Either way, I believe that the more documentation that continues to reference .war files as the deployment model, the more confusion that's going to exist. Maybe that's just where we're at right now, and we're not sure what the future exactly holds, so it's difficult to explain it any other way. Right now, I wanted to make sure I wasn't too confused, and misunderstanding something significant, as I continue to explore how OSGi fits into the world of enterprise development. Kirk Knoernschild http://www.kirkk.com http://techdistrict.kirkk.com http://planet.kirkk.com On Oct 16, 2007, at Oct 16, 9:23 AM, Simon Kaegi wrote: At least with respect to the Equinox Servletbridge the use of a WAR file is a means to an end. The Servletbridge uses a WAR file just to provide the integration with existing Java EE application servers and in particular it is an attempt to allow server applications get away from a monolithic deployment strategy. The Servletbridge approach is a recognition of the current world that many of us operate in and is trying to provide a way forward without necessarily paving the daisies. As OSGi matures inside of application servers we're sure to see better approaches. If what you're seeing is "constant references to WARs" then I'm just as concerned as you are as this is just integration glue. I agree with you in that the message we want to give is to think in terms of web components instead of web applications. I'd be very interested if you have any ideas on how we could better deliver this message. One problematic approach I frequently see done with the Servletbridge is the packaging of all the various bundles in the WAR file. This is typically done to simplify deployment but obviously lacks some of the interesting dynamic characteristics we'd like to have. It doesn't have to be this way and subsequently I'm very interested in partnering up the various provisioning technologies to create a more complete solution. My feeling is that this is the required next step. -Simon ----- Original Message ----- From: Kirk Knoernschild To: OSGi Developer Mail List Sent: Tuesday, October 16, 2007 8:48 AM Subject: [osgi-dev] war, jar, and Equinox If this isn't appropriate for this list, I apologize. If not, and you can point me to the correct list, I thank you. I seem to have grown confused regarding the deployment model related to server-side OSGi, and how I continue to constantly see references to .war files. I've been doing some work with Server-Side Equinox, and all of the documentation I find repeatedly talks about deployment of .war files. But it seems that a significant benefit of OSGi is that we no longer need to continue thinking in terms of web applications, but instead think in terms of web components that are individually deployed as OSGi bundles. In the ideal world, it would seem sensible that we no longer work with .war files at all. Instead, when it came time to develop for the web, we think more in terms of features, use cases, business functions, or technological layers. But regardless, we would deploy individual bundles within an OSGi framework that was an inherent part of the application server. At this point, the separation between what we traditionally view as webapps becomes nothing more than how URL's are registered within a BundleActivator instead of thinking of a webapp as an individual deployable unit. Then, given the current OSGi specification, if we desired to run different components in a separate VM, we would either embed another OSGi framework within the application server or setup another application server instance altogether. So my question...is the constant reference to .war files a stop-gap solution until more application servers have built-in support for OSGi? Do I continue to hear .war file as the unit of deployment simply because the Equinox ServerBridge is required to embed OSGi in a Servlet Container, and the only way to currently do this is to deploy the ServletBridge within a webapp (.war). Or is .war deployment still the long-term solution? If .war is still the long-term solution, possibly someone can clarify a few things for me. I do understand that we would still possess the ability to dynamically load bundles within that webapp. But the greater problem of determining the behavior of one webapp versus another still stands, and this is a prevalent problem in the world of enterprise software development where a software system is really a system of systems. Take away the notion of .war and begin thinking in terms of componentization, and it would offer significant architectural and design benefits. Continue to use .war files for deployment, and there are definitely system administration benefits (dynamic loading, etc.), but there could be so much more that OSGi brings to the table from and architectural and design (ie. modularity) perspective. Or...am I missing the boat? Kirk Knoernschild _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
