Hi Kirk,
As far as I know those application servers making use of OSGi internally are
unfortunately not exposing mechanisms to allow user applications to take
advantage of it. For the moment this means that if you want to use OSGi in your
application you will have to deploy a WAR/EAR that uses an approach to launch a
private framework instance similar to the equinox servletbridge.
One point I wanted to clarify is that although deploying a WAR file your
application does not have to be static. You can deploy a minimal WAR file and
then use the same OSGi based deployment technologies you might use in a
stand-alone framework to alter and configure the set of bundles in your
application.
As Felix pointed out your reasons for going standalone or embedded should be
purely about the environment you're integrating with. Either way your code
should be the same as the Http Service API provides a uniform way to register
your servlets and resources. A stand-alone framework is indeed simpler but
there are still plenty of good reasons to use a WAR/EAR based solution. Off the
top of my head, many of the configuration aspects of an application server are
better supported and easier to control in the various management consoles or
via various conf files. From my perspective, if you're developing an end-user
product the customer is probably not going to care about the OSGi good-ness of
your product and be more concerned that it works in Websphere or Jboss or
whatever that particular organization has standardized on and knows how to
manage.
On balance, I would tend to use a standalone framework solution at development
time and for casual use. For most production server environments I would still
go with the WAR/EAR based solution.
HTH
-Simon
----- Original Message -----
From: Kirk Knoernschild
To: OSGi Developer Mail List
Sent: Friday, February 15, 2008 4:42 PM
Subject: Re: [osgi-dev] Embedding
I was hoping there would be a clearer argument one way or the other. If I
embed OSGi within an application server, am I still required to deploy a .war
file? As I approach OSGi with a developer's perspective, it would be wonderful
if the static web application (.war files) went away and applications were
delivered independently as a composition of bundles. Similar to how application
server technology is leveraging OSGi to dynamically add and remove services to
create an adaptable application server, I'd like to do the same with my
applications. Why deploy a .war file at all? Why not just a bunch of bundles
that exposed their resources via URI's and services to the outside world?
But maybe either approach is going to give me that. It's being tied to the
.war that I'm struggling with, and if the .war is needed for deployment when
embedding OSGi within an application server, then I'd lean towards the other.
--kirk
x38854On Feb 14, 2008, at Feb 14, 4:25 AM, Felix Meschberger wrote:
Hi Kirk,
Am Mittwoch, den 13.02.2008, 21:45 -0600 schrieb Kirk Knoernschild:
I'm curious what the thoughts are regarding embedding OSGi in a
Servlet Container vs embedding a Servlet Container in OSGi. I'm not
finding any discussions surrounding the best approach, listing the
pros and cons. Anyone have compelling arguments, advantages, or
disadvantages on one vs. the other?
I think it all depends where you are looking from and what you intend to
do. And whatever you do, try to implement a solution, which is as
generic as possible. That is hide the fact to your bundles.
For example, we at Apache Sling [1] provide to launchers for the
framework: One is a standalone Java Application, which embedds a servlet
container as a bundle. The container is made available to the bundles
through the OSGi HttpService.
The second launcher is a web application where the OSGi framework is
started when the respective servlet is intialized. The servlet container
is made available to the bundles through a HttpService proxy (we use the
Equinox proxy).
In the end, bundles registered in the framework (a) don't care whether
the framework runs in a servlet container or embeds the servlet
container and (b) they don't even know.
Now, for my personal preference, I would generally use standalone Java
application launcher, because its lifecycle is easier to manage, for
example on *nix box you may create your init.d scripts. If OTOH you have
you servlet container infrastructure or are required to run in an
application server, e.g. to share EJB or resources, you use the web app
based launcher.
Hope this helps.
Regards
Felix
[1] http://incubator.apache.org/sling
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
------------------------------------------------------------------------------
_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev_______________________________________________
OSGi Developer Mail List
[email protected]
https://www2.osgi.org/mailman/listinfo/osgi-dev
