Home

News: Jerome Dochez: Glassfish V3 runs on OSGi

  1. Jerome Dochez: Glassfish V3 runs on OSGi (12 messages)

    Jerome Dochez has written "Glassfish V3 runs on OSGi," which says that since last week they are able to run Glassfish V3 on Apache Felix and Knopflerfish... and that Glassfish is going to switch to OSGi as their underlying module subsystem. It's very easy to start:java -DGlassFish_Platform=Felix -jar modules/glassfish-10.0-SNAPSHOT.jarHowever, note that a lot of the features you might be used to in Glassfish V2 aren't there yet for V3, so don't forget to read the quick start guide. It should be noted that by default, this runs Glassfish by itself inside of the Felix container; check out $GLASSFISH/felix/conf for configuration files to add things like the text administration console to the Felix deployment. [Editor's note: The grand question for me still remains: suppose I deploy GFv3 inside of an OSGi container - how do my servlets use resources from the other OSGi bundles?] One commenter asked:
    Will this have any influence on supporting JSR-277? Until now it didn't look like OSGi and JSR-277 would play well together.
    Interesting question! Is it even good for Java to have two competing module subsystems, even if you discount things like HK2 (itself designed for Glassfish) or JPF, along with many similar projects?

    Threaded Messages (12)

  2. And the purpose is...[ Go to top ]

    ...what exactly? Just to run a container on top of a container? Hardly convincing. Just use the module system? Hardly convincing. The only sensible thing would be to implement Glassfish on top of an OSGi container - in a modular fashion using OSGi of course - but also strictly relying on OSGi for protocol services, security, parsing, user management, system management .... But then again: Is there any OSGi container around that is good enough as a basis for an industry strength application server?
  3. Re: And the purpose is...[ Go to top ]

    ...what exactly? Just to run a container on top of a container? Hardly convincing. Just use the module system? Hardly convincing.

    The only sensible thing would be to implement Glassfish on top of an OSGi container - in a modular fashion using OSGi of course - but also strictly relying on OSGi for protocol services, security, parsing, user management, system management .... But then again: Is there any OSGi container around that is good enough as a basis for an industry strength application server?
    Well, I personally like the idea, since it allows me to cut down on how many JVMs I run in order to run an application environment.
  4. Re: And the purpose is...[ Go to top ]

    Well, I personally like the idea, since it allows me to cut down on how many JVMs I run in order to run an application environment.
    Right. But the module running on top of OSGi (say the application server) can still do things that can break the entire environment if not adherent to whatever the framework specification is. Very much like the sole EJB that can bring down an entire application server. So, while now, your application server crashes, in the future, the application environment is going to crash. At the end of the day, using any environment like that, the need to certify a particular module for the platform will arise very quickly.
  5. Re: And the purpose is...[ Go to top ]

    I don't get it - application server crashing is not a norm - that's a rare occurrence. It has to be a bug in the container that shuts down when one of the modules running in it throws some exception. Or, are you referring to JVM errors like OutOfMemoryError?
  6. Re: And the purpose is...[ Go to top ]

    I don't get it - application server crashing is not a norm - that's a rare occurrence. It has to be a bug in the container that shuts down when one of the modules running in it throws some exception. Or, are you referring to JVM errors like OutOfMemoryError?
    Exactly but in addition people do strange things - spawning threads, infinite loops eating cpu using cool jni code that dunps cores.....
  7. Re: And the purpose is...[ Go to top ]

    I don't get it - application server crashing is not a norm - that's a rare occurrence. It has to be a bug in the container that shuts down when one of the modules running in it throws some exception. Or, are you referring to JVM errors like OutOfMemoryError?


    Exactly but in addition people do strange things - spawning threads, infinite loops eating cpu using cool jni code that dunps cores.....
    That's true, Karl. The model that we have today (OS hosting a language runtime like the CLR, JVM, etc. as a process) is fairly vulnerable to this type of problem. It's like when Windows Explorer GPF's, and (even though it does restart) it's like someone ripped a vital organ out of the OS .. There is a JSR around isolation that should help, but fundamentally it's a 40-year old rickety model that we're perched on top of. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  8. Re: And the purpose is...[ Go to top ]

    That's true, Karl. The model that we have today (OS hosting a language runtime like the CLR, JVM, etc. as a process) is fairly vulnerable to this type of problem.
    Ah, an interesting thought. But on the contrary, one could argue that the model we have today (an OS hosting various processes) is fairly *stable* against this type of problem. While it might be easy to crash a process, it is actually quite hard to crash an operating system (well, depending on the operating system one could argue otherwise but still). Of course building applications in a stable way required some compromises and some overhead, like interprocess communication or even remote communication. But even then the OS might already provide a sufficient job in isolation (think about Solaris containers and the involved optimizations). And even than, the question is rather: Is that not a very small price to pay for a properly working system in 99% of all use cases.
  9. Java EE server OSGi based[ Go to top ]

    OW2 JOnAS Application server v5 is running on top of OSGi. New versions are only delivered as a set of OSGi bundles running for example on top of Apache Felix. OSGi world, by using BundleContext, is available from Java EE components like EJB by using @OSGiResource annotation. Existing OSGi bundles can be deployed as any other Java EE applications by dropping them in JONAS_BASE/deploy directory.
  10. Bidirectional interaction between OSGi bundles and Java EE components is an interesting area. Each container that supports OSGi can provide their proprietary API to access OSGi environment. We have not implemented that yet, but it's surely in the pipeline.
  11. Or you can do what real people do: scratch the entire EJB shit and run java components directly on top of OSGi and hibernate or whatnot. Simpler, less restricitive and better performing.
  12. Or you can do what real people do: scratch the entire EJB shit and run java components directly on top of OSGi and hibernate or whatnot.

    Simpler, less restricitive and better performing.
    Not sure where this came from: Java EE != EJB.
  13. Or you can do what real people do: scratch the entire EJB shit and run java components directly on top of OSGi and hibernate or whatnot.

    Simpler, less restricitive and better performing.
    another dowdy EJB bash...