GlassFish Osgi-javaee (i) GlassFish and enterprise-level OSGi development

Welcome to GlassFish OSGI-JAVAEE Special topic! Since the beginning of GlassFish v3, a new feature has been added to the GlassFish, which is GlassFish Osgi-javaee. This topic will be divided into nine sections to introduce GlassFish Osgi-java EE-related knowledge:

Part1: A simple introduction to GlassFish Osgi-javaee and a brief description of the current status of enterprise-class OSGi development.

Part2: Understand the GlassFish osgi/web container and develop and deploy a Web application bundle to GlassFish.

Part3: Understand the GlassFish OSGI/EJB container and develop and deploy an EJB application bundle into GlassFish.

Part4: Understand GlassFish OSGI/CDI (context-dependent injection) specification and GlassFish OSGI/CDI implementation, while demonstrating how to use GlassFish OSGI/CDI to simplify enterprise OSGi development.

PART5,PART6: Integrated ear and OSGi, where Part5 will embrace the ear and osgi;part6 by integrating the Apache Aries application features to show how to use EJB bundle to bridge the ear through a real case and OSGi to achieve the same goal.

Part7: A deep understanding of the relationship between GlassFish, HK2, and OSGi, while at the same time elaborating one's own point of view on the issues often referred to by the community. (Will HK2 be dead in the future?) ”)

PART8: Deep understanding of the GlassFish kernel (module configuration, loading, and startup), as well as showing how to extend GlassFish to add more custom modules in one case.

Part9: The process of contributing GlassFish OSGi and Osgi-javaee.

This topic will assume that the reader has the basic knowledge of GlassFish and OSGi, limited to space reasons, and I will not specifically introduce the basics of GlassFish and OSGi. If the reader has just contacted GlassFish, we recommend that you refer to the following links:

If the reader does not understand OSGi, recommend that you read the following books:

Neil Bartlett ' s "OSGi in Practice"

"OSGi in Action" such as Richard S. Hall

If you define "what is GlassFish Osgi-javaee" in one sentence, then we can say:

GlassFish Osgi-javaee is the GlassFish implementation of enterprise-level OSGi.

From the 2005 GlassFish 1.0 to the present 4.0 release, GlassFish has gone through 9 years, in this 9-year period, GlassFish experienced JavaEE5 to JavaEE7 evolution, through the acquisition of Sun by Oracle, has undergone significant architectural changes ... In my opinion, the most important change is the GlassFish 3.0 core and design concept of a major change, or even a revolution! Prior to 3.0, GlassFish was an indivisible or integral (monolithic) behemoth, tightly coupled between the kernel and components and various components, and lacked sufficient flexibility for scalability and low start-up performance. In the 3.0 era, the situation has undergone a fundamental shift, with the kernel relying on HK2 and OSGi, each module fully using the OSGi design concept, glassfish become more lightweight and modular, the kernel and components and the various components to achieve a loose coupling, with better scalability, Startup performance has been improved, and more importantly, maintainability is greatly improved. At the same time, more features of the module appeared, GlassFish Osgi-javaee is one of them. And it's all thanks to osgi!.

On the other hand, looking at the world's other mainstream open source Java EE application servers, such as JBoss 7 (now renamed Wildfly), Apache Geronimo 3 and so on are modular design concepts (although JBoss 7 does not directly use OSGi as the kernel), Try to make application server thin, more maintainable and scalable.

We have seen the modular design concept of the Java EE Application Server in the field of success, OSGi as a modular design concept of the most representative product, work not!

Instead of focusing on the basics of OSGi and how to design Java EE application servers using OSGi, we explored how to use OSGi to develop enterprise-class Java applications. But when it comes to OSGi and enterprise-class Java, we're bound to throw a question: Why is enterprise Java required to use OSGi?

To answer this question, we need to answer two of the following important questions:

What are the disadvantages of enterprise-class Java development?

Can the use of OSGi solve these deficiencies?

What are the disadvantages of enterprise-class Java development

Enterprise Java is loosely composed of a series of libraries, APIs, and frameworks built on core Java, and these libraries, APIs, and frameworks provide developers with a range of enterprise services, such as distributed component development, transactions, persistent Access databases, and so on. Enterprise-Class Java has been a huge success (both Java EE itself and the Spring framework), but as enterprise-class Java applications have grown in size and complexity, these applications have begun to become unwieldy and bulky, with standard Java Some of the inherent problems are becoming more serious and sometimes even fatal.

Classpath Hell.

The standard Java classpath is a flat (flat) structure, that is, to search for a class in a linear order in a specified classpath. For example, in Figure 1,

Figure 1: Classpath structure for flat (flat) in standard Java