You may take a look at Pax Web and Pax Web Extender Whiteboard as it may be what you explained bellow. Basically with Pax Web Extender Whiteboard you are able to deploy a bundle that just have to publish the servlets under an alias (specified as service property) and Pax web Extender will take care of the rest. As soon as you stop the bundle the servlets are unregistered. Same for resources. And if you are just using servlets/resources you can use Pax Web Extender with any http service implementation. But if you need more like jsp/filters/listeners,... you will have to go for Pax Web Http Service implementation.
And if you need more do not hesitate to ask :), Alin On Sat, Feb 16, 2008 at 5:42 AM, Kirk Knoernschild <[EMAIL PROTECTED]> wrote: > > > 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
