It's not a secret anymore!*
The moose likes Other Application Frameworks and the fly likes OSGI bundling vs CDI bundling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "OSGI bundling vs CDI bundling" Watch "OSGI bundling vs CDI bundling" New topic
Author

OSGI bundling vs CDI bundling

Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

which one is better OSGI funding or latest JEE spec -web module based bundling which also supports context and DI framework?
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
OCGi and DI/CDI do quite different things. In which way do you think they're comparable or might even compete?
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

Tim Moores wrote:OCGi and DI/CDI do quite different things. In which way do you think they're comparable or might even compete?


What I mean to say is JEE6 supports a component architecture which supports a modular concept of build applications from components to be reused in different situations. You can deploy the web modules without restarting the server. Something what OSGI famous for.
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
You're referring to Managed Beans? Those are quite limited in scope, and don't even begin to offer OSGi functionality like versioning, dependency management and dynamic unloading/reloading etc.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

Managed beans is a part of JSF framework, which has no relationship with web modularity. In JEE 6 you cant deploy the servlet without restarting server.


-Jignesh
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
Sorry to appear dense, but I'm having a hard time understanding what you're referring to. Web Fragments? Shared Framework Pluggability? Can you point me to some relevant documentation?

Managed Beans go way beyond JSF in JEE 6, by the way.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

I am referring web fragments.
http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview_Part2.html
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
I see nothing in there that mentions any kind of dynamic deployment, but if you say it's there then I'll take your word for it. But still: how does that even remotely come close to what OSGi does (which has the features I mentioned in my second post, and then some)? I'll grant that it does add a (quite small IMO) amount of modularity over "classic" web apps.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

Agree web modularity/fragmentation is not 100% OSGI, but I believe they are still good enough to serve the modularity for the web projects. By the way if we are just thinking of debating then JSR 277 is coming up which has all the feature of OSGI and there is a JSR 291 which talks about building a bridge between OSGI and Java.
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
I believe they are still good enough to serve the modularity for the web projects.

Depends on what you're looking for, obviously. They provide modularity, but not any kind of dynamism, which to me is the more important aspect of OSGi. If you're not going to load, unload and reload pieces of an application during runtime, and possibly having to manage differing dependencies of those pieces, then OSGi is not the best approach, IMO.

For example, OSGi has the HTTP Service (like in Apache Felix: http://felix.apache.org/site/apache-felix-http-service.html) which lets you deploy web components at runtime, undeploy them later, and then redeploy the same package with possibly altered functionality later - that's where OSGi shines.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

Tim,
Thanks for sharing all the details. I am very much interested to use OSGI due to cloud nature of our application but at the same time I do like to weight it against not using C&DI functionality. If you were me what do you choose?

One of the thing I read in one of the blog for OSGI, is their web service module is still not that much mature.

-Jignesh
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
I do like to weight it against not using C&DI functionality.

That's like saying "I don't like to use a fork because it doesn't provide what I need in a spoon". OSGi isn't a DI framework. If you need a DI framework, use one. If you need OSGI's capabilities, use OSGi. If you need both, use both.

If you were me what do you choose?

That depends on your requiremnets, about which we know nothing.

One of the thing I read in one of the blog for OSGI, is their web service module is still not that much mature.

There is no single "their" - several OSGi implementations exist, some more mature than others. Without context, this sentence makes no sense. Assuming you're talking about the HTTP service (web services are something else entirely), I've never seen the allure of that particular OSGI module. I think if I needed that kind of dynamism in a web app I'd go about it differently.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626


That's like saying "I don't like to use a fork because it doesn't provide what I need in a spoon". OSGi isn't a DI framework. If you need a DI framework, use one. If you need OSGI's capabilities, use OSGi. If you need both, use both.

Two years back java wasn't a DI framework but seeing the benefits of that it become DI framework. So it is not right to say OSGI is not for the DI support. DI is a desirable feature to have in OSGI then to consider it as alternative.

That depends on your requiremnets, about which we know nothing.

After the initial release we have a requirement to deploy code dynamically. And we will be using hadoop(i.e cloud underneath for data processing).


One of the thing I read in one of the blog for OSGI, is their web service module is still not that much mature.



There is no single "their" - several OSGi implementations exist, some more mature than others. Without context, this sentence makes no sense. Assuming you're talking about the HTTP service (web services are something else entirely), I've never seen the allure of that particular OSGI module. I think if I needed that kind of dynamism in a web app I'd go about it differently.


I am talking about service layer here. This is interesting to know about different versions of OSGI. If you can provide more details about them then it will be helpful.

Following link is having some heated discussion about OSGI vs JEE 6.
http://seamframework.org/103610.lace
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
So it is not right to say OSGI is not for the DI support. DI is a desirable feature to have in OSGI then to consider it as alternative.

It is absolutely right; let me emphasize that: OSGi is not for doing DI. And I repeat: Saying "DI is desirable, therefore if OSGi doesn't do it I have to consider alternatives" is like saying "A fork is useful, so if my spoon can't act as one, I'll have to look for alternatives (even if I'm eating soup)." During a proper meal you'd use both, each for the task it is meant for.

This is interesting to know about different versions of OSGI. If you can provide more details about them then it will be helpful.

I'm not talking about different versions of OSGi (which of course do exist), I'm talking about different implementations: Apache Felix, Eclipse Equinox, Knopflerfish. OSGi itself is just a specification.

I found a useful page here if you want to learn about OSGi: http://www.coderanch.com/how-to/java/OSGiLinks
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
Following link is having some heated discussion about OSGI vs JEE 6. http://seamframework.org/103610.lace

You think that's heated? You ain't seen nothing yet

That's just talk about how to provide modularity in JEE - the age-old argument that OSGI is here now (and has been for years), but that Java's built-in modularity system will be used by JEE once it's released. That modularity system, by the way, was supposed to be in Java 7, but wasn't, now it's supposed to be in Java 8, which has just been postponed to 2013. So you'd have to wait another two years for Java 8, and then some time X after that until the next JEE spec is released, and then some time Y after that until your favorite JEE app server supports it. I'd argue that anyone who is prepared to wait that long doesn't actually need the feature.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626


So it is not right to say OSGI is not for the DI support. DI is a desirable feature to have in OSGI then to consider it as alternative.
It is absolutely right; let me emphasize that: OSGi is not for doing DI. And I repeat: Saying "DI is desirable, therefore if OSGi doesn't do it I have to consider alternatives" is like saying "A fork is useful, so if my spoon can't act as one, I'll have to look for alternatives (even if I'm eating soup)." During a proper meal you'd use both, each for the task it is meant for.

Ok let me put other perspective. Why do we have C&DI? - to provide faster development and better readable code(which in turn makes maintenance easier). Now though it is a desirable feature, isn't it an essential feature for any software development.

I'm not talking about different versions of OSGi (which of course do exist), I'm talking about different implementations: Apache Felix, Eclipse Equinox, Knopflerfish. OSGi itself is just a specification.

Is there any link to see comparison among them? I found one as below:
http://stackoverflow.com/questions/560794/what-osgi-container-do-you-recommend

And how about Spring DM? Can I make Spring DM get it run on JBoss7 which supports OSGI?


I found a useful page here if you want to learn about OSGi: http://www.coderanch.com/how-to/java/OSGiLinks


Thanks for the Link.
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
SpringDM isn't an OSGi implementation, it's a server for providing OSGi features (using any one of the 3 implementations I mentioned) in an otherwise Spring environment. Not much seems to be happening with it since it has been spun off from Spring to the Eclipse Foundation, so I would be hesitant to use it.
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

How about Spring Roo? It seems it is very active.

I am also curious to know embedding apache felix on JBoss 7? If not JBoss then which container is better to do that?

-Jignesh
Michael Van
Ranch Hand

Joined: Nov 25, 2003
Posts: 33
I haven't seen a response to your posts in a couple of days, so I thought I'd respond. Before I continue, you should know that I'm an Apache Software Foundation Committer, and have been a contributor to the Apache Karaf project now for over a year. Additionally, I'm actively involved with thier efforts to migrate their provisioning mechanism so that it will be compliant with the OSGi Service Platform early release subsystem spec. What does this mean? It means I know what I'm talking about with respect to OSGi, Apache Felix, Apache Karaf, Aries, etc.

There was a quote about the use of the web-services in OSGI. Eclipse Virgo (SpringDM for those who are trying to keep-up) is able to use Virgo TomCat for web-interaction. This implementation of TomCat is OSGi compliant, and allows the deployment of WAB (Web Archive Bundles), and the speedy conversion of WAR's to WAB's if you dont' want to learn OSGi. Additionally, Karaf (the closest thing to a competitor of Virgo) allows you to use a number of different frameworks for Web interaction. I have used Jetty, and Jersey. Karaf uses Pax-Wicket internally. What I'm trying to say here is that the OSGi community of service-platforms and containers provides a number of very robust tools to allow RESTful and normal HTTP/S type of interaction.

SpringRoo's mention here seems out of place. So, I will not mention it other than to say that is "should" work well within any OSGi container. SpringSource has gone to great lengths to ensure their jar's play nicely within OSGi.

Yes, you can deploy Felix inside of a web container. That said, I fail to see why you would want to do this. Doing this is akin to sticking a small car in the trunk of a larger car and then trying to steer from the smaller car. Sure, with some fiddling you can get it to work, but why the heck would you want to?

Perhaps a different approach to help you would be for you to tell us what your final goal of this question is. What are you trying to create?


Mike Van
Apache Software Foundation Committer
Jignesh Patel
Ranch Hand

Joined: Nov 03, 2001
Posts: 626

Michael,

First of all, thanks for time and providing indepth insight.
Now, considering my limited knowledge in OSGI and good hands on experience with app server, I opt to use app server. The another reason, I am not aware of any good container which supports OSGI. The third, may be not imp at this time but envisioning enterprise apps need support for more protocols like JMS, once after it start growing.

My application may have back end code running in mysql, in that case I will use Hibernate API.
Or it can have HBase running and in that case I will row apis in use.

-Jignesh
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: OSGI bundling vs CDI bundling
 
Similar Threads
OSGi and Equinox : OSGi future
Do OSGi and Equinox have Eclipse plugins?
OSGI: Dependency Hell
OSGi Myths
FuzzyJess and OSGI Equinox