Twitter github

Lipstick on a Pig, OSGi and JEE

So it looks like OSGi isn’t a secret anymore… it continues to be adopted by the JEE crowd according to a new press release. The only problem with that press release is that it’s somewhat of a farce. I know of only a couple companies that are truly pushing OSGi as the actual application model… not the decrepit JEE stack of technologies like EJBs and friends.

Sure, it’s nice to say that you’re taking advantage of OSGi as the runtime for your application server, but how about for the application model? Once we have bundles running on desktops, servers and devices… things start to become very interesting as this will be the first time I think the industry has one application model across target environments (desktop, server, device).

Maybe all my agnst against JEE is coming out today šŸ™‚

What do you think?

  • Patrick Mueller

    The farce goes both ways: the OSGi HTTP service reuses the old and crusty javax.servlet madness as it’s primary interface. A shame, as I would prefer something more “moist and delicious”. Of course, there isn’t much of an alternative available today; but that doesn’t make javax.servlet “right”.

  • Patrick Mueller

    The farce goes both ways: the OSGi HTTP service reuses the old and crusty javax.servlet madness as it’s primary interface. A shame, as I would prefer something more “moist and delicious”. Of course, there isn’t much of an alternative available today; but that doesn’t make javax.servlet “right”.

  • Donald Smith

    Baby steps, it’s coming along…… šŸ™‚

    A press release like this with a dozen or so companies is not trivial to execute on.

    I spent a lot of time last week on a road trip talking with heavy eclipse users trying to convince them OSGi is real and has weight. If I’d only waited a damn week šŸ™‚

  • Donald Smith

    Baby steps, it’s coming along…… :)A press release like this with a dozen or so companies is not trivial to execute on.I spent a lot of time last week on a road trip talking with heavy eclipse users trying to convince them OSGi is real and has weight. If I’d only waited a damn week šŸ™‚

  • Ian Skerrett

    I agree exposing the application model is the next step. However, Donald hits the nail on the head, a lot of people still don’t believe OSGi is real. This announcement helps with that.

  • Ian Skerrett

    I agree exposing the application model is the next step. However, Donald hits the nail on the head, a lot of people still don’t believe OSGi is real. This announcement helps with that.

  • Jacek Furmankiewicz

    We are using OSGi for “real”…and I have to say perception is mixed. it solves some issues, but sure as hell introduces a lot of other ones (classloader issues galore).

    Can’t say it’s a magical silver bullet.z

  • Jacek Furmankiewicz

    We are using OSGi for “real”…and I have to say perception is mixed. it solves some issues, but sure as hell introduces a lot of other ones (classloader issues galore).Can’t say it’s a magical silver bullet.z

  • Chris Aniszczyk (zx)

    @Donald/Ian, I’m not arguing that this isn’t a good thing… it’s great for the spread of OSGi.

    @Jacek… classloader issues galore? OSGi SOLVES a lot of those problems if you do things right. Do I have to remind you of the Class.forName hacks found through out third party libraries and other crap that caused issues painful to debug?

  • Chris Aniszczyk (zx)

    @Donald/Ian, I’m not arguing that this isn’t a good thing… it’s great for the spread of OSGi.@Jacek… classloader issues galore? OSGi SOLVES a lot of those problems if you do things right. Do I have to remind you of the Class.forName hacks found through out third party libraries and other crap that caused issues painful to debug?

  • Jacek Furmankiewicz

    Yeah, but those are the libraries you are stuck using…and a lot of them don’t work out of the box in OSGi…hence the issues.

    Also, the issues of running JUnit tests in an OSGi environment can be quite a Pandora’s box…it’s a big hole in the oSGi stack right now

  • Jacek Furmankiewicz

    Yeah, but those are the libraries you are stuck using…and a lot of them don’t work out of the box in OSGi…hence the issues.Also, the issues of running JUnit tests in an OSGi environment can be quite a Pandora’s box…it’s a big hole in the oSGi stack right now

  • Chris Aniszczyk (zx)

    @Jacek, how so? If JUnit in an OSGi environment was an issue, how would Eclipse be tested :)?

    There are some difficulties around testing packages that aren’t exposed via Export-Package, but there are ways around that if you become a fragment to the bundle you want to test.

    I would be curious to hear your viewpoint on what is lacking and what PDE or Equinox could do to make life easier.

  • Chris Aniszczyk (zx)

    @Jacek, how so? If JUnit in an OSGi environment was an issue, how would Eclipse be tested :)?There are some difficulties around testing packages that aren’t exposed via Export-Package, but there are ways around that if you become a fragment to the bundle you want to test.I would be curious to hear your viewpoint on what is lacking and what PDE or Equinox could do to make life easier.

  • Anonymous

    “I know of only a couple companies”

    Maybe, but one of them happens to be SpringSource… And when SpringSource says jump these days, the Java world says how high!

  • Anonymous

    “I know of only a couple companies”Maybe, but one of them happens to be SpringSource… And when SpringSource says jump these days, the Java world says how high!

  • Josh Reed

    All I can say is: “let’s all hold our breath until JSR-277 is released and it solves all of the problems with OSGi.” Actually don’t, because I think that’s what Sun is hoping because there’d be no one left to oppose the JSR-277 fiasco.

    It’s going to be sweet when I can install my webapp as a set of OSGi bundles, but until then I’m just happy that they support OSGi on the app server side.

  • Josh Reed

    All I can say is: “let’s all hold our breath until JSR-277 is released and it solves all of the problems with OSGi.” Actually don’t, because I think that’s what Sun is hoping because there’d be no one left to oppose the JSR-277 fiasco.It’s going to be sweet when I can install my webapp as a set of OSGi bundles, but until then I’m just happy that they support OSGi on the app server side.

  • David Carver

    Chris, OSGI isn’t the answer to everything. Yeah, JEE can suck, and it’s bloated. OSGi can solve some of this issue, but Eclipse’s use of osgi is getting bloated with all the various plugins. Especially, the load once and never really unload mechanism. Memory usage does matter despite what people may think. Anyways, it would be good for you to experiment around again with other frameworks…there are good and bads about both ways of doing things. Efficient code can help a lot regardless of what platform or framework is used.

  • David Carver

    Chris, OSGI isn’t the answer to everything. Yeah, JEE can suck, and it’s bloated. OSGi can solve some of this issue, but Eclipse’s use of osgi is getting bloated with all the various plugins. Especially, the load once and never really unload mechanism. Memory usage does matter despite what people may think. Anyways, it would be good for you to experiment around again with other frameworks…there are good and bads about both ways of doing things. Efficient code can help a lot regardless of what platform or framework is used.

  • Peter Kriens

    javax.servlet 2.1: The OSGi specification dates ten years back and is widely used in non-JEE environments. The 2.1 spec is highly useful in these worlds because it does not require huge stacks. There are several possibilities that we are investigating what to do with web applications because we learned a lot in the last ten years. Anyway, the fact that the OSGi does not have a “moist and delicious” OSGi service does not have to stop you from using some of the webservers available as bundles like Tomcat and Jetty that seem to be more yummy.

    Class loading issues: As Chris indicates, OSGi makes class loading problems go away but it can’t do miracles. Strong modularity provides an enormous amount of advantages in developing software. However, many applications have included dynamic class loading tricks that are oblivious of modularity and the associated constraints like versioning and consistency graphs: they assume global visibility. And you can’t have it both ways: strong modularity and a global classpath. Lots of people insist on using the hacks and tricks that worked well in this global classpath world on OSGi and that is doomed to fail. If you need an extension/plugin facility, services are the way to go, they solve an amazing number of class loader problems in my experience. And problems not solved with services are handled very well with the extender model.

    Fortunately, more and more libraries are becoming available that take advantage of OSGi’s features (extender mode, services). In almost every case I’ve seen creating a smaller, robuster, and more elegant solution. But it does require some work.

  • Peter Kriens

    javax.servlet 2.1: The OSGi specification dates ten years back and is widely used in non-JEE environments. The 2.1 spec is highly useful in these worlds because it does not require huge stacks. There are several possibilities that we are investigating what to do with web applications because we learned a lot in the last ten years. Anyway, the fact that the OSGi does not have a “moist and delicious” OSGi service does not have to stop you from using some of the webservers available as bundles like Tomcat and Jetty that seem to be more yummy.Class loading issues: As Chris indicates, OSGi makes class loading problems go away but it can’t do miracles. Strong modularity provides an enormous amount of advantages in developing software. However, many applications have included dynamic class loading tricks that are oblivious of modularity and the associated constraints like versioning and consistency graphs: they assume global visibility. And you can’t have it both ways: strong modularity and a global classpath. Lots of people insist on using the hacks and tricks that worked well in this global classpath world on OSGi and that is doomed to fail. If you need an extension/plugin facility, services are the way to go, they solve an amazing number of class loader problems in my experience. And problems not solved with services are handled very well with the extender model.Fortunately, more and more libraries are becoming available that take advantage of OSGi’s features (extender mode, services). In almost every case I’ve seen creating a smaller, robuster, and more elegant solution. But it does require some work.