aspose file tools*
The moose likes Other Application Frameworks and the fly likes Sweet spot of Spring-DM compared to other implementations? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Sweet spot of Spring-DM compared to other implementations?" Watch "Sweet spot of Spring-DM compared to other implementations?" New topic
Author

Sweet spot of Spring-DM compared to other implementations?

Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41865
    
  63
I'd be curious to know where you see the sweet spot for Spring DM compared to other OSGi implementations like Felix, Knopflerfish and Equinox? Obviously, they all implement the OSGi API, so that's not much if a differentiation... there must be something else that made you chose Spring DM.

I'm only familiar with Felix; in which cases should I be looking at other implementations?

(BTW, some time ago I started to collect OSGi links at http://faq.javaranch.com/java/OSGiLinks; please feel free to add any that you think are useful.)


Ping & DNS - my free Android networking tools app
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

I would be interested how well the different implementations work with each other. As OSGi is a unified specification/API I think the different implementations should work together.

Can module bundles be shared between different implementations? Or are there implementation specific details?

Marco
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Let's be clear about one thing: Spring-DM is not an OSGi implementation. It's a declarative service framework for OSGi, but Spring-DM needs an OSGi runtime (such as Felix, Equinox, etc). SpringSource dm Server (related, but not the same as Spring-DM) may appear to be an OSGi runtime, but in fact, it is running on top of Equinox.

It's better to compare Spring-DM with iPOJO and OSGi Declarative Services, as these 3 things attempt to solve the same problem. iPOJO and DS are fine, but they only address the problem of declaring POJOs as OSGi services. Spring-DM does that, *plus* tacks on some web support, *plus* brings the whole Spring framework with it so that you can not only wire OSGi services together, but also the more fine-grained beans that make up those services.

Also note that OSGi R4.2 includes a spec for "Blueprint Services" which is heavily inspired by Spring-DM (actually, that part of the spec was put together by SpringSource folks). Spring-DM will be the RI for that part of the spec.

Comparing the OSGi frameworks against each other, I tend to favor Equinox because Equinox is the most complete implementation of the spec. Specifically, Equinox has long supported OSGi fragments, while Felix is just now starting to support them. Spring-DM's web stuff leans on fragments quite a bit, so if I'm building a web application with Spring-DM, Felix hasn't been an option (yet).

Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Thanks a lot for clarifying some misconceptions, Craig This was a short and concise summary of many details I didn't know before! I think I should read up a little bit more about this topic...

Just out of curiosity, could you explain in short or provide an URL for this "web support" Spring-DM adds to OSGi?

Marco
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Marco Ehrentreich wrote:Just out of curiosity, could you explain in short or provide an URL for this "web support" Spring-DM adds to OSGi?


In a nutshell, Spring-DM's web support lets you install WAR files as bundles within OSGi. But unlike the HTTP service and other web extenders (such as Pax Web), Spring-DM's extender doesn't try to web-ify an OSGi bundle. Let me clarify that statement a bit...

The OSGi HTTP service, by definition, requires you to programmatically register servlets. The thought of that makes me shudder!

Pax Web provides an extender that takes a regular WAR file (with a bit of OSGi goodness in its manifest) and parses that WAR file's WEB-INF/web.xml to make the calls to the HTTP service for you. But the WAR file is still fully an OSGi bundle...it just happens to contain some web stuff in it.

Spring-DM lets you deploy a WAR file as a bundle, but instead of parsing the web.xml file and web-ifying its contents, Spring-DM recognizes that Jetty/Tomcat already do a great job of parsing web.xml and deploying web contents. So, the WAR file is both a bundle (from the OSGi framework's point of view) and a web application (from the web container...Tomcat or Jetty...point of view).

Building an OSGi-ready WAR file involves (at minimum) giving it a MANIFEST.MF with a Bundle-SymbolicName: entry and probably a Bundle-ClassPath: entry. That Bundle-ClassPath: entry will contain paths to everything the WAR file needs, including all of the JAR files in WEB-INF/lib. It might look like this:



In a truly modular OSGi WAR file, the WEB-INF/lib directory would be empty, so you could reduce it to:



All of the stuff provided by the JAR files in WEB-INF/lib would instead be in other bundles deployed alongside the WAR bundle. The WAR would consume their services and import their exported packages.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
I am just confused that what is the point to deploy a WAR as a bundle.
A WAR is supposed to be deployed in a servlet container, isn't it?

If we deploy a WAR as a bundle and then how to run that WAR? You mentioned Jetty/Tomcat does that mean we will use Jetty/Tomcat to run the WAR? Then how Spring-DM and a servlet container work together.

Please explain more, I just don't understand your explanation.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Kengkaj Sathianpantarit wrote:Then how Spring-DM and a servlet container work together.


Here's roughly how it works...

- Both your web bundle (which is in the form of a WAR file, but with OSGi goodies in META-INF/MANIFEST.MF) is deployed as a bundle in an OSGi runtime such as Equinox.
- There are probably several other bundles also deployed in that OSGi runtime. Perhaps some of them are dependencies of your web bundle that were previously kept in WEB-INF/lib.
- Among those other bundles are a set of bundles for Tomcat (or it could be Jetty).
- There's also a special bundle called a web extender. The web extender's job is to watch the OSGi framework for bundles to be installed and started. More specifically, the web extender is looking for bundles that look like WAR files (that is, have a WEB-INF/web.xml file).
- When the web extender sees such a bundle get started, it taps Tomcat on the shoulder and installs that same WAR file in Tomcat (which, as I've already mentioned, is embedded in Equinox).
- Likewise, when the bundle is stopped it is removed from Tomcat.
- As far as Tomcat is concerned, it's a regular WAR file and Tomcat serves it as such.
- As far as Equinox is concerned, it's just a bundle like any other bundle and manages its lifecycle, package imports, and service consumption needs as such.

Think of it this way: We all play several roles and our roles are determined by who we're dealing with. When I talk to my wife, I'm her husband. To my daughters, I'm daddy. To those around me at work, I'm a co-worker. Everyone sees and collaborates with me in different ways, but I'm still the same person.

Web bundles are like that. To Equinox, they're a bundle. To Tomcat, they're a WAR file.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Thanks for the explanation.

But it seems that the web extender just deploy/undeploy a WAR to/from a servlet container, right?
In that case I still don't quite understand what is the benefit to do that?

I understand a WAR in a servlet container's point of view, but why do we want to deploy a WAR as a OSGi bundle?
Of course, we don't deploy it just to make the web extender deploy it to a servlet container.

Could you please to give a real world example that why do we want to deploy a WAR as a OSGi bundle?
Other bundles want to access Servlets, JSPs or something?
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Kengkaj Sathianpantarit wrote:I understand a WAR in a servlet container's point of view, but why do we want to deploy a WAR as a OSGi bundle?Of course, we don't deploy it just to make the web extender deploy it to a servlet container.


Because once you're able to deploy a WAR file in OSGi, you can start taking advantage of the modularity that OSGi offers.

A typical non-OSGi WAR file has a *LOT* of stuff in its WEB-INF/lib and WEB-INF/classes, right? In the best situation, the stuff in WEB-INF/classes pertains only to web-related stuff (such as Spring MVC controllers, for instance), but in many WAR files, a great deal of the business logic, database persistence logic, and other stuff that has nothing to do with the web layer of the application.

Even if that stuff isn't in WEB-INF/classes, a lot of it is in WEB-INF/lib. Furthermore, there are a lot of 3rd party libraries in WEB-INF/lib.

Even if you develop your application as a bunch of distinct modules, it all ends up in one big monolithic WAR file for deployment...right? Okay, then how can you upgrade to a new version of a 3rd party library without rebuilding the entire WAR file? How can you fix a bug in a DAO without rebuilding and redeploying the entire WAR file? You can't (at least not without hacking under the covers of the web container).

With OSGi, you can deploy a big fat WAR file, that's for sure. But you'll gain no benefit from doing so. Where OSGi starts paying off is when you start extracting pieces of your application out into separate bundles. Ideally, your OSGi-deployed WAR file won't have much in it that isn't web-specific. Your business logic, DAOs, and other miscellany will be in separate bundles deployed alongside your web bundle--they won't be housed within that web bundle. This means that you'll be able to fix that DAO bug without redeploying the web application (in fact, in OSGi, you can fix it without even restarting the web application!). That's because your DAO is in a separate deployment unit from your web application.

And all of those 3rd party libs in WEB-INF/lib...they're also deployed separately in the OSGi framework. This has two implications: (1) you can update them independent of your application and (2) you can have multiple applications running in the same instance that depend on a single library (as opposed to a copy of that 3rd party library for every application that you deploy that needs it).

Could you please to give a real world example that why do we use to deploy a WAR as a OSGi bundle?
Other bundles want to access Servlets, JSPs or something?


In Modular Java, we build a search engine application that is made up of 4 distinct parts: A web front-end, an indexer, a search service, and domain objects. The web front-end is a WAR file, but it is focused on the web layer of the application and contains nothing that isn't specific to that purpose. The indexer has a spider that crawls content and adds it to a Lucene index (via Compass). The search service offers a service that searches that index. And then there are a handful of domain objects in their own module. Each of these are individually developed, tested, and deployed units. Furthermore, all of the third party libraries are independently deployed units. This offers a great amount of flexibility, making is possible for me to update or swap out bundles without affecting the rest of the application.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Craig, thank you very much for taking the time to explain everything at great length! This was really interesting and helpful information!

There's just a simple question left... The feature you mentioned to wrap 3rd party libraries into OSGi bundles reminds me again of the NetBeans module system. In NetBeans you have to/you should package each library JAR inside its own module in order to make it manageable with the correct version and meta data. From what you already explained I suspect that the concept will be very similar with OSGi. Can you confirm this?

Anyway, I think you already convinced me to get a copy of your book

Marco
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Marco Ehrentreich wrote:There's just a simple question left... The feature you mentioned to wrap 3rd party libraries into OSGi bundles reminds me again of the NetBeans module system. In NetBeans you have to/you should package each library JAR inside its own module in order to make it manageable with the correct version and meta data. From what you already explained I suspect that the concept will be very similar with OSGi. Can you confirm this?


In OSGi you don't exactly wrap JAR files in their own bundle (although that is one way you could do it). All you typically need to do is crack open the JAR file and give it a MANIFEST.MF file that suits it. By that I mean the manifest should have a symbolic name, a version, and should import/export packages appropriately.

Peter Kriens' BND tool (http://www.aqute.biz/Code/Bnd) is a fairly awesome tool for doing this. SpringSource's Bundlor and DynamicJava.org's Bundler tools also do kinda the same thing. Pax Construct has two command (pax-wrap-jar and pax-embed-jar) that use BND under the covers to bring non-OSGi JAR files into the OSGi world.

Which prompts me to make this statement: You don't have to convert all of your 3rd party JAR files into bundles...it's probably a good idea in general, but it's not strictly required. What you can do instead is embed a non-OSGi JAR file within a bundle that depends on it. For example, let's say that I've built an OSGi-based application that has several bundles in it, and out of all of those bundles only one of them depends on Lucene. In that case, I *could* just go ahead and embed Lucene JARs within the one bundle that needs it. I'll miss out on some of the ability to update Lucene without rebuilding and redeploying that bundle, but maybe that's okay.

FWIW, the way you embed JAR files within bundles is to just place them somewhere inside the bundle JAR file and add a Bundle-ClassPath: reference to those embedded JAR files in the manifest. (Or if you're using Pax Construct, let pax-embed-jar do it for you...again, I can't say enough good things about Pax Construct.)

Anyway, I think you already convinced me to get a copy of your book


Awesome!
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Craig, thanks a bunch for your time and effort to explain.
Nevertheless, I still don't fully understand how it does really work. And I believe most of people don't really understand it (they might think they understand).

Could you please to verify and correct my understanding below?

Let's suppose that we have:
1. Web bundle (servlet, jsp, Spring MVC controllers, etc)
2. Lib bundle (spring.jar, spring-webmvc.jar, etc)
3. Repository bundle (similar to DAO)

We deploy 1. to Tomcat, then the web extender needs to deploy 2. to WEB-INF/lib and 3. to WEB-INF/classes, right? Because the application will not work if there are no libs and required classes.

Then when we want to update Lib bundle and Repository bundle, how does the web extender do?
Will it deploy to WEB-INF/lib and WEB-INF/classes again? Does servlet container support doing that? I don't know.
But in that case I don't think it would be much different than copying libs and classes to WEB-INF/lib and WEB-INF/classes ourselves.

If I misunderstand anything, please let me know.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Marco Ehrentreich wrote:
There's just a simple question left... The feature you mentioned to wrap 3rd party libraries into OSGi bundles reminds me again of the NetBeans module system. In NetBeans you have to/you should package each library JAR inside its own module in order to make it manageable with the correct version and meta data.

No, normally we will not do that. Each library will be a bundle. But we can bundle libs in a bundle.

Craig Walls wrote:
Which prompts me to make this statement: You don't have to convert all of your 3rd party JAR files into bundles...it's probably a good idea in general, but it's not strictly required. What you can do instead is embed a non-OSGi JAR file within a bundle that depends on it. For example, let's say that I've built an OSGi-based application that has several bundles in it, and out of all of those bundles only one of them depends on Lucene. In that case, I *could* just go ahead and embed Lucene JARs within the one bundle that needs it. I'll miss out on some of the ability to update Lucene without rebuilding and redeploying that bundle, but maybe that's okay.

I agree. I think the benefit of making a library to be a bundle is to make it be used from other several bundles. But if it's clear that there will be only one bundle that uses that library, it wouldn't be necessary to create a bundle for that library.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Kengkaj Sathianpantarit wrote:We deploy 1. to Tomcat, then the web extender needs to deploy 2. to WEB-INF/lib and 3. to WEB-INF/classes, right? Because the application will not work if there are no libs and required classes.


No, it's not like that at all.

For OSGi web apps what you deploy is a bundle that contains JSPs, images, CSS, controller classes, and whatever else that bundle needs to provide the web portion of the application. And you deploy it to an OSGi framework such as Equinox...not to Tomcat or Jetty.

That web bundle could, but doesn't necessarily need to have any libraries in its WEB-INF/lib. (And, in fact, if you're going for full modularity, it probably doesn't have anything in WEB-INF/lib.) When the web extender sees that the bundle is started and that it is a web bundle (because it has a WEB-INF/web.xml file), it will hand it off to Tomcat (or Jetty) that is already running within the OSGi framework itself.

You say that the application will not work if there are no libs and required classes. But that's only true because you're assuming a traditional model where the WAR file contained everything and the web application's classpath was fully defined by what is contained within the WAR file itself. But in OSGi, the web bundle will contain only the parts that are important to the web layer of an application and its classpath can be augmented by other bundles in the OSGi runtime.

Let's say that our application is a Spring MVC application (using the Spring 2.5 annotation-based model...just to complete the scenario). In that case, your web bundle will probably contain one or more controller classes in WEB-INF/classes that are annotated with the @Controller, @RequestParam, and @RequestPath annotations. Obviously, the controller has a dependency on Spring MVC, so Spring MVC *must* be in WEB-INF/lib, right?

Well, it could be, but with OSGi it doesn't have to be. Instead, Spring MVC is deployed as a handful of bundles in the OSGi runtime alongside your web bundle. The Spring bundles export the org.springframework.web.bind.annotation and org.springframework.stereotype packages (as specified in their manifest), so they're available to any other bundle in the OSGi runtime to import. Meanwhile, your web bundle imports those packages (specified in its manifest). The OSGi runtime makes sure that the imported packages from the Spring bundles are available in the web bundle's class space. Thus the dependency on Spring MVC is satisfied--even though the Spring JARs aren't in WEB-INF/lib.

Note that package-dependency relationships are just one way that bundles can interact with each other's contents. The other way is a service/consumer relationship where one bundle publishes a service and other bundles consume that service. But I'll save that discussion for another time.


Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Many thanks, your explanation is informative, it's much more clear now.

Now from my understanding, it's like:
1. Spring-DM manages to make Tomcat/Jetty running in an OSGi framework environment.
2. When using a web application, we don't access Tomcat/Jetty directly, but we access via Spring-DM which it will delegate HTTP requests to the managed servlet container (Tomcat/Jetty) - by managed I mean managed by Spring-DM.
3. At run-time, Spring-DM links dependencies that the WAR needs, so it can access libs/classes specified in META-INF/MANIFEST.MF even though they aren't in WEB-INF/lib or WEB-INF/classes.

If I still misunderstand anything, please let me know.

I have some additional questions:
1. Who does manage HTTP Sessions? Spring-DM or a servlet container?
2. Does Spring-DM also support EAR (EJB + WAR)?
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Hi folks,

are there modified versions of Tomcat/Jetty to run it inside an OSGi container? To me it's still unclear what impact OSGi has on a servlet container running on top of an OSGi container Does this work transparently? Does it have an impact on the configuration, performance, security etc. of the servlet container?

Thanks in advance!

Marco
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Kengkaj Sathianpantarit wrote:
1. Spring-DM manages to make Tomcat/Jetty running in an OSGi framework environment.


Yes


2. When using a web application, we don't access Tomcat/Jetty directly, but we access via Spring-DM which it will delegate HTTP requests to the managed servlet container (Tomcat/Jetty) - by managed I mean managed by Spring-DM.


No...it's Tomcat or Jetty responding directly to those HTTP requests. They just happen to be running within the context of OSGi, not on their own. But yes, Spring-DM (and the OSGi framework) manage them.


3. At run-time, Spring-DM links dependencies that the WAR needs, so it can access libs/classes specified in META-INF/MANIFEST.MF even though they aren't in WEB-INF/lib or WEB-INF/classes.


Not exactly. It's the OSGi runtime that manages those dependencies. In this scenario, all Spring-DM does is watch for web bundles to be installed/started in OSGi and then introduce them to Tomcat/Jetty to serve. It's the underlying OSGi framework (Equinox, Jetty, etc) that handles the dependency management.

1. Who does manage HTTP Sessions? Spring-DM or a servlet container?


The servlet container just as always...that servlet container just happens to be running within an OSGi context.

2. Does Spring-DM also support EAR (EJB + WAR)?


No. There's probably no reason why someone couldn't build such support, but Spring-DM currently doesn't offer that (and I doubt that they ever will).


Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Marco Ehrentreich wrote:are there modified versions of Tomcat/Jetty to run it inside an OSGi container? To me it's still unclear what impact OSGi has on a servlet container running on top of an OSGi container Does this work transparently? Does it have an impact on the configuration, performance, security etc. of the servlet container?


The core of Tomcat/Jetty are unmodified (as far as I know). There's just some special goodness wrapped around them to handle deployment of web bundles into those containers and to let the underlying OSGi framework handle classpath dependencies. But the core of those web containers is the same Tomcat or Jetty that you've already come to know and love.

In fact, the Jetty web server is already quite OSGi-ready even without Spring-DM. A lot of the OSGi HTTP service implementations lean on Jetty because it's already mostly OSGi-ready out of the box. Spring-DM has to do a lot less special work with Jetty than it does for Tomcat because of that.

Except for the deployment of web bundles part, running those web containers in OSGi is very little different than running them natively. There's very little impact on configuration (other than that your web bundles will need some special OSGi stuff in their MANIFEST.MF)...and that the web container configuration has to be packaged up in an OSGi fragment (which annoys me a bit...that's why I created http://jira.springframework.org/browse/OSGI-629 to enable external configuration of Jetty...the same could be done for Tomcat). There's negligible/no impact on performance, security, etc.

Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

Thanks a lot for the detailed information (again)! I guess, I'll just have to give it a try myself instead of asking you for every detail

Marco
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Thanks very much, Craig.
Ivano Pagano
Ranch Hand

Joined: Dec 16, 2006
Posts: 47

Marco Ehrentreich wrote:I guess, I'll just have to give it a try myself instead of asking you for every detail

In the end it was a good thing! For example I understood a good deal better all the web-app deployment stuff thanks to your detailed questions and Craig clear answers.

Thanks to you all.
Ivano
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Ivano Pagano wrote:
Marco Ehrentreich wrote:I guess, I'll just have to give it a try myself instead of asking you for every detail

In the end it was a good thing! For example I understood a good deal better all the web-app deployment stuff thanks to your detailed questions and Craig clear answers.

I agree, it's a good thing to ask questions.
I think no need to worry too much, if someone answered your questions, he just liked or wanted to answer.
Craig Walls
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 301
Kengkaj Sathianpantarit wrote:
Ivano Pagano wrote:
Marco Ehrentreich wrote:I guess, I'll just have to give it a try myself instead of asking you for every detail

In the end it was a good thing! For example I understood a good deal better all the web-app deployment stuff thanks to your detailed questions and Craig clear answers.

I agree, it's a good thing to ask questions.
I think no need to worry too much, if someone answered your questions, he just liked or wanted to answer.


By all means...ask away! I'm doing my best to respond to all of the questions asked this week. Even if I don't know the answer, I'll at least respond to say that I read your question, but that I am unable to answer.

The big gotcha is that you, the questioners, are a distributed model while I, the answerer, am a singleton. As a group, you are capable of asking questions much faster than I can possibly answer them. So, some questions may slip by me. If I don't respond to your question in a reasonable time (keep in mind that I have a day job and do sleep every once in awhile), then ask it again and maybe I'll catch it the 2nd time around.
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1280

By all means...ask away! I'm doing my best to respond to all of the questions asked this week. Even if I don't know the answer, I'll at least respond to say that I read your question, but that I am unable to answer.

Don't worry your answers are brilliant and really helpful And I would ask if I really have a question but sometimes some kind of own "research" is necessary to fully understand things...

Marco
 
Don't get me started about those stupid light bulbs.
 
subject: Sweet spot of Spring-DM compared to other implementations?