[osgi-dev] war, jar, and Equinox

Kirk Knoernschild kirk-osgi at kirkk.com
Tue Oct 16 22:58:02 EDT 2007


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
> osgi-dev at www2.osgi.org
> http://www2.osgi.org/mailman/listinfo/osgi-dev
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev at www2.osgi.org
> http://www2.osgi.org/mailman/listinfo/osgi-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www2.osgi.org/pipermail/osgi-dev/attachments/20071016/a99f8eda/attachment.html


More information about the osgi-dev mailing list