The most important thing about OSGi is its support for modularity. But because most applications and systems were not designed for modularity, or were designed and built with a home-grown modular design, adopting OSGi typically involves some level of difficulty, writes Eric Newcomer on SearchSOA.com. Newcomer suggests you must be able to adopt the additional structure OSGi requires in order to obtain its benefits, and to take the time and investment required to really adopt modularity. The benefits of modular programming have been well understood for about 40 years, but before OSGi developers had to invent their own modular designs and systems. Using the OSGi programming model for enterprise applications can achieve a lot of benefits, but this is also where some challenges still remain. Along with the initially burdensome structure of the OSGi programming model, however, come the benefits of improved flexibility and decreased cost once modularity is achieved. Still, there is no universal rule for choosing whether to use OSGi . Each project must be assessed individually. Read more of Newcomer on OSGI ... http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1365017,00.html

I'm curious if anyone has any statistics on companies using OSGi for "rearchitecting" legacy web applications. Specifically are people refactoring the exiting app to be more modular and to truly use OSGi (I believe Linkedin is doing this) or are they adding some new functions in OSGi and are leaving the existing legacy application as is in the J2ee container? Has anyone been successful in either case? Thanks! Gary

Has anyone been successful in either case?

Nope. OSGi sucks IMO. If you want to invest time in yourself, dont waste it on OSGi, better do something more constructive.

I'm curious if anyone has any statistics on companies using OSGi for "rearchitecting" legacy web applications.

What do you want? The usual faked 'statistics' like those about Agile and Spring adoption?

What do you want? The usual faked 'statistics' like those about Agile and Spring adoption?

No but I'm curious if people are making the move.. I don't want stats from the OSGi alliance (I would ask them directly if I wanted those kind).. So I guess I should have asked if anyone reading The Server Side is porting a legacy app to OSGi? If so, are they doing a full port to utilize an OSGi container or are they embedding OSGi inside of an existing J2EE application (in an app server)? the OSGi "folks" recommend the first option but that seems impractical for lots of projects.. I know linkedin is doing it as they gave a presentation at EclipseCon (or one of those conferences). But I haven't seen/heard of any others especially those doing the second option.

What do you want? The usual faked 'statistics' like those about Agile and Spring adoption?

No but I'm curious if people are making the move.. I don't want stats from the OSGi alliance (I would ask them directly if I wanted those kind).. So I guess I should have asked if anyone reading The Server Side is porting a legacy app to OSGi? If so, are they doing a full port to utilize an OSGi container or are they embedding OSGi inside of an existing J2EE application (in an app server)?

the OSGi "folks" recommend the first option but that seems impractical for lots of projects.. I know linkedin is doing it as they gave a presentation at EclipseCon (or one of those conferences). But I haven't seen/heard of any others especially those doing the second option.

Yes we have followed the second option in WSO2 Carbon which is based on OSGi and also the base platform all Java products in WSO2. Carbon is merely a webapp which can be embedded in an App server. We use Equinox servlet-bridge concept with some modifications. This has worked very well for us, even though, we had some issues initially, when migrating our Java projects to OSGi.

"and learning a new language (in the case of OSGi, the OSGi metadata language that sits in between the modules)" I seriously hope the author is not referring to the manifest files. I've been building OSGi enabled applications for the past year and I have not had to learn a new language. Certainly I have had to become familiar with the OSGi API, but that is not a new language. Tell me, what is this so called new language that I was supposed to have learned?

"and learning a new language (in the case of OSGi, the OSGi metadata language that sits in between the modules)"

I seriously hope the author is not referring to the manifest files. I've been building OSGi enabled applications for the past year and I have not had to learn a new language. Certainly I have had to become familiar with the OSGi API, but that is not a new language.

Tell me, what is this so called new language that I was supposed to have learned?

I think the manifest file syntax is what is meant here. It's technically a language, just one with a very small scope. It's not Turing complete or anything.

I think the manifest file syntax is what is meant here. It's technically a language, just one with a very small scope. It's not Turing complete or anything.

Wouldn't you still say it is just a bit of an exaggeration to state that you have to learn a new language? Also, manifest files are not new. We might be adding new properties to the manifest file, but I still wouldn't consider it a new language. FYI - I use annotations and Maven to build the manifest files.

I think the manifest file syntax is what is meant here. It's technically a language, just one with a very small scope. It's not Turing complete or anything.

Wouldn't you still say it is just a bit of an exaggeration to state that you have to learn a new language? Also, manifest files are not new. We might be adding new properties to the manifest file, but I still wouldn't consider it a new language.

FYI - I use annotations and Maven to build the manifest files.

Yeah, I can see that. It's probably good to point out that it is not a full-fledged programming language or anything close to that for those who haven't tried OSGi yet. My point is that it's mainly semantics. Sure these are just lines in a manifest file but Java code is just lines in a text file. It's the interpretation that makes it a language. I think the author meant 'language' in a strict sense in which case it's correct to classify it as such.

"and learning a new language (in the case of OSGi, the OSGi metadata language that sits in between the modules)"

I seriously hope the author is not referring to the manifest files. I've been building OSGi enabled applications for the past year and I have not had to learn a new language. Certainly I have had to become familiar with the OSGi API, but that is not a new language.

Tell me, what is this so called new language that I was supposed to have learned?

I think the manifest file syntax is what is meant here. It's technically a language, just one with a very small scope. It's not Turing complete or anything.

Yes, correct. Sorry again for the confusion.

"and learning a new language (in the case of OSGi, the OSGi metadata language that sits in between the modules)"

I seriously hope the author is not referring to the manifest files. I've been building OSGi enabled applications for the past year and I have not had to learn a new language. Certainly I have had to become familiar with the OSGi API, but that is not a new language.

Tell me, what is this so called new language that I was supposed to have learned?

Sorry, perhaps that was a misuse of the word "language." I didn't mean new language in the sense of a new programming language, but in the sense of a new metadata language. Sorry for the confusion.

At WSO2, we migrated our suite of Java middleware products into a new architecture based on OSGi which we call WSO2 Carbon. To be frank, it was a pain migrating to OSGi, but mostly it was because we were new to OSGi & OSGi has a steep learning curve. But the benefits of this exercise are immense. We have been able to create an SOA platform. Each feature in a product is developed as a Carbon component, which is an OSGi bundle. So, sharing features between products has become very simple, and everything nicely fits together. Even the JSP & AJAX based management console is developed as a set of OSGi bundles, so when a new UI component is available, it automatically shows up on the management console. We have gone one step further by integrating the Equinox P2 based provisioning support. Now, we have a set of P2 features which can be installed, uninstalled or upgraded. In summary, I would say that the benefits of OSGi outweigh the negative aspects associated with it.

Really? I mean, sure, most applications aren't perfect because of schedules and deadlines and whatnot, but it's it really accurate to claim that most applications aren't written in a modular fashion? And for poorly-designed applications, are the OSGi manifest annotations really going to suddenly create good design? I don't see the logic here.

Really?

I mean, sure, most applications aren't perfect because of schedules and deadlines and whatnot, but it's it really accurate to claim that most applications aren't written in a modular fashion?

And for poorly-designed applications, are the OSGi manifest annotations really going to suddenly create good design? I don't see the logic here.

I would have to agree with you on that one too. What is this so called 'new structure'? JAR files? They are new? I wonder if the author has heard of Maven. The thing is that well designed applications are often broken down into modules and/or reusable artifacts. The only difference is that instead of bundling all of the JARs together. We are deploying them independently.

Really?

I mean, sure, most applications aren't perfect because of schedules and deadlines and whatnot, but it's it really accurate to claim that most applications aren't written in a modular fashion?

And for poorly-designed applications, are the OSGi manifest annotations really going to suddenly create good design? I don't see the logic here.

I would have to agree with you on that one too. What is this so called 'new structure'? JAR files? They are new?

I wonder if the author has heard of Maven. The thing is that well designed applications are often broken down into modules and/or reusable artifacts. The only difference is that instead of bundling all of the JARs together. We are deploying them independently.

Re: Maven, check the new Tycho project to integrate OSGi and Maven for details on how these technologies complement each other. (http://www.sonatype.com/people/2009/03/the-future-of-maven-osgi-join-the-tycho-users-mailing-list/) RE: Are applications modular already - the article acknowledges that many applications may already be modular, but not in the way that OSGi does it, i.e. by enforcing the use of a consistent modularity metadata for deployment in a runtime framework that enforces that metadata. This is why all the Java vendors are using it - OSGi improves overall capabilities for modular programming. Not that people aren't already doing modular programming, but that OSGi takes it a step further.

Really?

I mean, sure, most applications aren't perfect because of schedules and deadlines and whatnot, but it's it really accurate to claim that most applications aren't written in a modular fashion?

Standard Java doesn't offer enough features to produce the kind of modularity that OSGi allows for. It's not that OSGi will magically make your application modular (it won't) but that it makes it possible. The best example I can give of this is that you can define which version of which library your module uses. In standard Java execution environments, the qualified name of the class is all you have to work with. If there are two jars with that name in the classpath, you get which ever one comes first. This makes modularity difficult at best because it makes it difficult to use 2 classes that depend on different versions of a 3rd class in the same application. The other feature of OSGi that helps with modularity is that if you don't export a package, it's not visible to other modules. This greatly eases the difficulty of implementing proper encapsulation.

Standard Java doesn't offer enough features to produce the kind of modularity that OSGi allows for. It's not that OSGi will magically make your application modular (it won't) but that it makes it possible.

This doesn't make any sense. It's certainly possible to write modular code without OSGi.

The best example I can give of this is that you can define which version of which library your module uses.

That's a linking capability. It's not a modularity capability.

The other feature of OSGi that helps with modularity is that if you don't export a package, it's not visible to other modules. This greatly eases the difficulty of implementing proper encapsulation.

How does that simplify encapsulation? Normally when writing Java code, if you don't import a package, you don't see it. Sure, it's technically possible to import packages you shouldn't see, but that's just bad practice.

The best example I can give of this is that you can define which version of which library your module uses.

That's a linking capability. It's not a modularity capability.

Are you just arguing semantics here? Can you explain how this is a meaningful distinction?

The other feature of OSGi that helps with modularity is that if you don't export a package, it's not visible to other modules. This greatly eases the difficulty of implementing proper encapsulation.

How does that simplify encapsulation? Normally when writing Java code, if you don't import a package, you don't see it. Sure, it's technically possible to import packages you shouldn't see, but that's just bad practice.

With OSGi you can have packages full of public classes that are not visible to other bundles. This means that all you need to do is put the classes you do want exposed into exported packages. With standard Java features, you can only make these classes package-protected. That means that you have to carefully plan your package structures so that the classes that need to see these classes are able to but no one else. Saying that it's bad practice to look at things you aren't supposed to doesn't solve anything. OSGi allows you to specify what should be looked at and what should not.

That's a linking capability. It's not a modularity capability.

Are you just arguing semantics here? Can you explain how this is a meaningful distinction?

Selecting jar versions and making them visible in a classloader really doesn't have anything to do with modularity. Or are you defining modularity as dividing code into jars? That's not very interesting. Normally, modularity refers to the structure of the code in an application, i.e. part of the architecture.

OSGi you can have packages full of public classes that are not visible to other bundles. This means that all you need to do is put the classes you do want exposed into exported packages. With standard Java features, you can only make these classes package-protected. That means that you have to carefully plan your package structures so that the classes that need to see these classes are able to but no one else.

What problem, exactly, is this solving? The restricted package structure that OSGi requires is perfectly implementable in Java. If you want to force your project to follow that style, you can do that without OSGi. OSGi itself does nothing to help there, it's just enforcing a certain architecture.

Saying that it's bad practice to look at things you aren't supposed to doesn't solve anything. OSGi allows you to specify what should be looked at and what should not.

So? That's solving a non-problem.

Or are you defining modularity as dividing code into jars? That's not very interesting. Normally, modularity refers to the structure of the code in an application, i.e. part of the architecture.

You are saying this features are not valuable but there is no meat to your argument. Nothing you are saying here is any more meaningful than "no it isn't"

The restricted package structure that OSGi requires is perfectly implementable in Java. If you want to force your project to follow that style, you can do that without OSGi.

Given that OSGi is designed for and implemented in Java, it's pretty self-evident that this can be done in Java. But without a similar type of framework, how do you propose hiding public classes in public packages from other classes in the same application?

Saying that it's bad practice to look at things you aren't supposed to doesn't solve anything. OSGi allows you to specify what should be looked at and what should not.

So? That's solving a non-problem.

"So?" That's your argument? Frankly, that you don't believe this solves a problem makes me think you don't have enough experience to make the assertions you are making.

, but it's it really accurate to claim that most applications aren't written in a modular fashion?.

It would be tough to prove unless one could see all applications in existence. But of the ones I have seen (not including the ones I am currently working on) - Zero are modular.

OSGi represents another epic fail in the IT world. We are constantly flooded with new technologies, very few of which contain some kind of added value beyond the hype. We have been talking about the general lack of productivity JEE has suffered since its inception. We are now listening that taking the next panacea to all JEE problems "takes patience". No, I am afraid I won't buy this one.

OSGi represents another epic fail in the IT world.

You post pretty much lacks any substance at all. How,specifically and technically, has OSGi failed you. Have you tried it? What was it supposed to accomplish for you that you feel it did not?

OSGi represents another epic fail in the IT world.

You post pretty much lacks any substance at all.

How,specifically and technically, has OSGi failed you. Have you tried it? What was it supposed to accomplish for you that you feel it did not?

I may start with the awful loading times, huge memory consumption and frequent incompatibilities that I experience in Eclipse. I may go on with the wild growth of built-in services that are making OSGI look more and more like CORBA (e.g. transactions). I expected a lean, simple framework for handling dependencies between modules. It ended up like yet another unmanageable framework. In other words, a FAIL.

I may start with the awful loading times, huge memory consumption and frequent incompatibilities that I experience in Eclipse.

I hope your not implying that you're only experience with OSGi is Eclipse. Have you started up a fresh Felix instance? I can tell you that it is quite quick. Exceptionally quick. I'm also not following what you mean by a 'wild growth of built-in services'. A fresh instance has a handful of bundles. Nothing too wild. Also, what do services have to do with transactions? The API for OSGi is pretty simple. I don't see anything unmanageable. What do you find unmanageable about it? Have you actually deployed an application (set of bundles) to Felix before? Have you worked with the console?

I hope your not implying that you're only experience with OSGi is Eclipse.

Of course not. I have dealt with some OSGI-implemented projects in my company.

Have you started up a fresh Felix instance? I can tell you that it is quite quick. Exceptionally quick.

Also my PC after a fresh install is exceptionally quick.

I'm also not following what you mean by a 'wild growth of built-in services'. A fresh instance has a handful of bundles. Nothing too wild. Also, what do services have to do with transactions?

http://osgi.mjahn.net/2008/08/28/some-thought-on-the-osgi-r42-early-draft/

The API for OSGi is pretty simple. I don't see anything unmanageable. What do you find unmanageable about it?

The extreme module fragmentation that you must achieve in order to accomplish an OSGI implementation.

Have you actually deployed an application (set of bundles) to Felix before? Have you worked with the console?

Needless to say, yes. I am not excited at all.

We have been talking about the general lack of productivity JEE has suffered since its inception. We are now listening that taking the next panacea to all JEE problems "takes patience".

No, I am afraid I won't buy this one.

Don't buy. This is actually a conspiracy. Ssssshhhhh...The plan is to offer OSGi as an alternative to JEE, and so developers will get a lot more bloatware that would make JEE to look like slimware! Then, all those Java developers rush to JEE. LOL!! Seriously, OSGi does come with interesting ideas. I think it's foolish to dismiss it quickly. It would be even more foolish to get religious about it, and claim to be the panacea for all ills. If you try to prove OSGi benefits by showcasing the edge cases it solves, like some commenter's seem to do here, then I doubt it's viability. Still, it's too early to shoot something down.

Shaw,I do not really care about JEE (that is another awful bloatware). Just have a look at what is being propsed for v4.2 and tell me if it is not going to become another application server technology: http://osgi.mjahn.net/2008/08/28/some-thought-on-the-osgi-r42-early-draft/ What have transactions to do with JAR dependencies and versions? I liked the lean and simple idea behind OSGI. But I need someone to really convince me that this is not going to be the next CORBA. Seriously.

Shaw,I do not really care about JEE (that is another awful bloatware). Just have a look at what is being propsed for v4.2 and tell me if it is not going to become another application server technology: http://osgi.mjahn.net/2008/08/28/some-thought-on-the-osgi-r42-early-draft/
What have transactions to do with JAR dependencies and versions?
I liked the lean and simple idea behind OSGI. But I need someone to really convince me that this is not going to be the next CORBA. Seriously.

Majority of Java community have been good at rejecting bloatware. EJB 1.x & 2.x were good examples. Even with JEE, the community is quite divided. Many people (including myself) still aren't clear how exactly JEE is more beneficial than something like, say Spring. Anyway, I'm not trying to convert this into JEE vs Spring argument, but all I'm saying is community is not going to take BS and go with it. All I'm saying is, it's probably too early to take sides. People need to try with projects to understand what it solves etc. If it's a bloatware, OSGi will find a new neighbourhood with EJB 1.x & 2.x etc. That you can be sure :)

Shaw,I do not really care about JEE (that is another awful bloatware). Just have a look at what is being propsed for v4.2 and tell me if it is not going to become another application server technology: http://osgi.mjahn.net/2008/08/28/some-thought-on-the-osgi-r42-early-draft/
What have transactions to do with JAR dependencies and versions?
I liked the lean and simple idea behind OSGI. But I need someone to really convince me that this is not going to be the next CORBA. Seriously.

First of all, CORBA succeeded. Hundreds of applications around the world use CORBA successfully, and some types of applications actually succeeded better using CORBA than Java EE, for example SOA based applications. The largest of these in production today are based on CORBA. Second, it is a false comparison. OSGi is a modularity framework, not a distributed computing standard. Yes, we added remote services in R4.2, but this is simply a way to integrate existing distributed computing environments. It is not a new distributed computing environment. Finally, the use of Java EE components such as JTA and JNDI are completely optional and do not even have to be loaded if they are not needed. The Java EE vendors are using OSGi exactly for the purpose of reducing the complexity of Java EE. Eclipse is not the same thing as OSGi. Eclipse is an application on OSGi. Eclipse may be large, but other OSGi based applications are much smaller, such as Sprint Titan, BMW iDrive (formerly), Deutsche Bahn control system, etc.

I had the venture of working on the design and development of functionally equivalent large applications on J2EE and OSGi. Building an application architecture on top of J2EE was painful. Working on OSGi has been a great experience. There is non silver bullet. But there are good technologies, and OSGi is a very good modularization technology. IMO J2EE is not very good in this aspect. Ciao Sandro

1. OSGI has a huge cost - So be prepared to spend lot of time and energy on training , understanding as well as non technical silly little stuff like incorrect bundle dependency, manifest file editor issues etc :). 2. If you work in a place where people are always on the go and cant wait enough to learn new technologies then this is not for you. This is not as smiple as going to SOA model either. THIS IS A CULTURAL change for techies. 3. its not fully matured yet. Bottom line - think of days when you adopted EJB 1.0. its hellish. !!!

I've stated this before that I'm not in favor of OSGi being something consumed by the application developer. We already have enough popular and mature component APIs. We don't need another. I'm also down on the fine-grain classloading that OSGi has. In JBoss since 2003 we've had a very flexible classloading architecture with a lot of options. This has caused confusion off and on with our user base. The thing is, we're more coarse grain for OSGi and I worry with more flexibility users will get even more confused. What you're basically doing is asking the developer to become a linker. In the past with C/C++ development, we had a program to do stuff like this (the linker). Another analogy is Java EE. Java EE has had class-path manifest extensions for awhile. It adds more confusion, not less. I'm not FUDding OSGi. I'm just voicing my concerns based on years of experience developing middleware. I think we need OSGi to focus on deployment and get the 90 of 90/10 of applications working in a simple, transparent way. Then to just go away and let the rest of us plug in our services and component libraries to the spine...Defining a new component model or a new way to "modularize" your code base is not what the community needs. We already have a butt-load of options here that are already mature. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

I'm also down on the fine-grain classloading that OSGi has. In JBoss since 2003 we've had a very flexible classloading architecture with a lot of options. This has caused confusion off and on with our user base. The thing is, we're more coarse grain for OSGi and I worry with more flexibility users will get even more confused. What you're basically doing is asking the developer to become a linker.

So when I'm pulling my hair out trying to resolve dependency problems (esp. with 3rd party libraries), I should thank my lucky stars that I'm not being asked to be a linker?

I'm also down on the fine-grain classloading that OSGi has. In JBoss since 2003 we've had a very flexible classloading architecture with a lot of options. This has caused confusion off and on with our user base. The thing is, we're more coarse grain for OSGi and I worry with more flexibility users will get even more confused. What you're basically doing is asking the developer to become a linker.

So when I'm pulling my hair out trying to resolve dependency problems (esp. with 3rd party libraries), I should thank my lucky stars that I'm not being asked to be a linker?

I fail to see how OSGi solves this problem. Its fine-grainess will only make the problem worse.

I fail to see how OSGi solves this problem. Its fine-grainess will only make the problem worse.

Because the bundles specify exactly what they need, the dependency conflicts are eliminated. For example, if I use two 3rd party bundles that require different versions of, say, xerces, as long as the bundles specify what they need they should work in the same application. This is the most basic thing about OSGi. I find it odd that you don't see why this helps.

Because the bundles specify exactly what they need, the dependency conflicts are eliminated.

I wish it were that simple.. I have had numerous conflicts with different bundles with different "uses" clauses on their imports/exports. IE: "org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Package uses conflict: Import-Package:" So to say it's eliminated is not true. You still need to do your due diligence when using varying 3rd party libraries (by the way.. I got this just trying to use CXF DOSGI on Equinox with no other 3rd party libs) Gary PS. Still no one out there doing an OSGi embedded in a J2ee app?

Because the bundles specify exactly what they need, the dependency conflicts are eliminated.

I wish it were that simple.. I have had numerous conflicts with different bundles with different "uses" clauses on their imports/exports. IE: "org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Package uses conflict: Import-Package:"

So to say it's eliminated is not true. You still need to do your due diligence when using varying 3rd party libraries

But OSGi isn't creating this issue. It's making you aware of the issue. This is a good thing. I'd much rather see this than production application failures.

>But OSGi isn't creating this issue. It's making you aware of the issue. This is a good thing. I'd much rather see this than production application failures.

I guess I never had a dependency conflict in a production web application.. It usually happens during test which is when the same thing happened in my OSGi app. I guess if you are doing an Eclipse RCP kind of app it'd be a different story but trying to get OSGi to work under an existing J2ee app hasn't been any better (so far it's actually been worse) (sorry.. but that's our experience so far.. Though, I'd still like to do a from scratch OSGi app and see how that goes) Gary

But OSGi isn't creating this issue. It's making you aware of the issue. This is a good thing. I'd much rather see this than production application failures.

I guess I never had a dependency conflict in a production web application. It usually happens during test which is when the same thing happened in my OSGi app.

To really get the value of this you have to think long term over the life of the application. So many times we focus on what it takes to get something up and running in it's first version. In a lot of ways, that's the easy part.

I guess if you are doing an Eclipse RCP kind of app it'd be a different story but trying to get OSGi to work under an existing J2ee app hasn't been any better (so far it's actually been worse) (sorry.. but that's our experience so far.. Though, I'd still like to do a from scratch OSGi app and see how that goes)

Gary

Where I work we have a lot of different teams that work largely in isolation. It's very easy to trample over each others stuff. Right now we have two options: deploy all dependencies in the web app, or spend gobs of money testing and retesting and dealing with all the project dependencies. An example where I see value in this is that I have a utility library for problems that are common to many of our Java apps. When we want to add something or modify an existing class, can't just do that and push it out to existing apps without retesting them. That's prohibitively expensive. So we end up versioning this jar. That works but the only place that tells you what version each app uses is in the build (hopefully.) Deploying all the jars in the web app is OK. It works for most things but it's far from optimal. Aside from the extra memory usage, we end up will many copies the of the same libraries in the application. It's kind of ugly and unmanageable. I'm not 100% sure OSGi is the answer here. But I can't abide claims that there's no issue. Denial ain't just a river in Egypt, you know. Perhaps some of the issues that people are facing with OSGi is that a lot of Java code is improperly coupled. It might be easier to say that OSGi sucks and go back to ignoring the real issue.

Not sure why you would put many copies of the same jar in the same web app web inf/lib folder so I guess I have never had that issue. (I have one very very large web app to worry about.. not many so I only have one web app and one set of jars).. But that has nothing to do with the original comment which was that with OSGi dependency issues go away.. I have not found that to be the case.. I am starting to feel it is not a fit for putting inside another J2ee web app.. And is anyone doing this? I haven't seen any articles, press releases etc.. nor heard from anyone reading this thread.. So it seems that people are using OSGi for RCP type apps or creating a new Web App (or a complete port to OSGi like Linkedin).. If someone knows of any web apps with 10 years of java code that is putting a few new modules inside OSGi under the existing J2ee app I'd love to hear it. And hear that the issue we have had so far are not real.. That would make me very happy.. Until then I'll be floating on a raft in the Nile.. Thanks. Gary PS.. Just for the record.. I am actually a fan of OSGi.. I just don't think it's works inside another J2ee app..

Not sure why you would put many copies of the same jar in the same web app web inf/lib folder so I guess I have never had that issue. (I have one very very large web app to worry about.. not many so I only have one web app and one set of jars)..

It's not multiple in one war or ear. It's multiple wars and ears with the same libs. Dozens of applications in a server being modified concurrently by different teams.

But that has nothing to do with the original comment which was that with OSGi dependency issues go away..

I was merely responding to what you wrote.

I have not found that to be the case.

I don't mean top suggest that OSGi makes dependency issues magically disappear. It just gives me tools to resolve those issues. Right now I have only ad-hoc approaches. As far as J2EE goes, the only server I know of that is purported to have much OSGi support is GlassFish. But I don't even know if that's related to deployed apps. Jetty can supposedly be started as a bundle in a OSGi container.

It's not multiple in one war or ear. It's multiple wars and ears with the same libs. Dozens of applications in a server being modified concurrently by different teams."

why are changes to one team's war or ears impacting anything outside of that war/ear? and if that's required, don't most app servers have something similar to tomcat's catalina_base at this point? dunno, i haven't really seen a good usecase for osgi outside of eclipse where you have hundreds of people doing god knows what and all that has to be bundled into one jvm instance. the server space just isn't like that.

It's not multiple in one war or ear. It's multiple wars and ears with the same libs. Dozens of applications in a server being modified concurrently by different teams."

why are changes to one team's war or ears impacting anything outside of that war/ear? and if that's required, don't most app servers have something similar to tomcat's catalina_base at this point?

dunno, i haven't really seen a good usecase for osgi outside of eclipse where you have hundreds of people doing god knows what and all that has to be bundled into one jvm instance. the server space just isn't like that.

They don't. But I think what you are missing is that the reason we do things that way is solely to avoid the issues I am describing. Just because we have a workaround doesn't mean there isn't an issue. There's a cost to doing things this way. We've become accustomed to building systems in this (inefficient) way that we don't realize that it doesn't have to be that way.

I've stated this before that I'm not in favor of OSGi being something consumed by the application developer. We already have enough popular and mature component APIs. We don't need another.

I'm also down on the fine-grain classloading that OSGi has. In JBoss since 2003 we've had a very flexible classloading architecture with a lot of options. This has caused confusion off and on with our user base. The thing is, we're more coarse grain for OSGi and I worry with more flexibility users will get even more confused. What you're basically doing is asking the developer to become a linker. In the past with C/C++ development, we had a program to do stuff like this (the linker). Another analogy is Java EE. Java EE has had class-path manifest extensions for awhile. It adds more confusion, not less.

I'm not FUDding OSGi. I'm just voicing my concerns based on years of experience developing middleware. I think we need OSGi to focus on deployment and get the 90 of 90/10 of applications working in a simple, transparent way. Then to just go away and let the rest of us plug in our services and component libraries to the spine...Defining a new component model or a new way to "modularize" your code base is not what the community needs. We already have a butt-load of options here that are already mature.

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Yeah, but what if someone doesn't want to be tied to the JBoss 'option'?

Using the OSGi programming model for enterprise applications can achieve a lot of benefits, but this is also where some challenges still remain. Along with the initially burdensome structure of the OSGi programming model, however, come the benefits of improved flexibility and decreased cost once modularity is achieved. Still, there is no universal rule for choosing whether to use OSGi . Each project must be assessed individually.

Yes I completely agree with you here. Even though OSGi gives a lots of benefits, you might have to face unseen hard challenges. I've been engaged in developing OSGi based applications for about an year now. From my experience, what I've understood is, in order to get most of the benefits of OSGi, your application, including third party libraries should be based on OSGi. This is also not enough in certain cases. For example, if you decided to embed your application in an app server(not based on OSGi), um.. good luck. :)

Most of the techniques used in legacy java apps, is not applicable as it is in OSGi systems. For example

(1)Loading classes using the context class loader,
(2) Usage of Java Service Provider Interface to load implementations and
(3) Usage of Class.forName() to load classes.

These are the places where things can go wrong in OSGi based systems. Anyway, IMHO moving forward with OSGi is the right solution, because it is the perfect solution so far which has addressed the problem of modularizing software. And yes it requires some patience..