• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OSGI bundling vs CDI bundling

 
Ranch Hand
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
which one is better OSGI funding or latest JEE spec -web module based bundling which also supports context and DI framework?
 
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am referring web fragments.
http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview_Part2.html
 
Tim Moores
Saloon Keeper
Posts: 7582
176
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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: https://coderanch.com/how-to/java/OSGiLinks
 
Tim Moores
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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: https://coderanch.com/how-to/java/OSGiLinks



Thanks for the Link.
 
Tim Moores
Saloon Keeper
Posts: 7582
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Jignesh Patel
Ranch Hand
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Jignesh Patel
Ranch Hand
Posts: 686
Mac
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eventually I have implemented OSGI and war file on wildfly 10, which can support both at that time and it works as expected.
 
Saloon Keeper
Posts: 15485
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow, blast from the past!

Great job Jignesh, and thanks for reporting back to us
 
reply
    Bookmark Topic Watch Topic
  • New Topic