I'm sure there are numerous other angles I've not thought of where
those "aha moments" are going to keep coming in different areas for
different people. Too bad we can't capture them all and spill them
back to the rest of the world.
I'll be sure to track the p2 work. That seems like a significant step.
thanx.
Kirk Knoernschild
http://www.kirkk.com
http://techdistrict.kirkk.com
http://planet.kirkk.com
On Oct 16, 2007, at Oct 16, 11:29 PM, Jeff McAffer wrote:
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
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
