Discussions

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?

...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?

...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.

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.

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?

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?

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?

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

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.

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.

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.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.