I use this blog post to explain what it is all about. What does this feature accomplish?After this feature is implemented, the actual startup time for Application Server became nearly half of what it was in its previous version.
Why was it taking longer to startup earlier?In my mind, Java EE is a mature and really capable technology for enterprise applications. As an Application Server compliant to Java EE, GlassFish supports many technologies or services specified in the Java EE specification. Lets try to name a few of them... Servlet, JSP, Webservices, EJB, JMS, Connectors, JDBC, JMX, JSF....
Application server, on startup, initialize containers/components that provide these services eagerly and this takes a long time AND lot of memory.
So, what does this new feature do?Most of the developers are not going to use all the services in the Application Server. I am not talking about those who develop really complex EE applications all the time, but about developers who download the Application Server and just try out a few samples, or folks who learn one or two technologies at a time or even folks who work on small projects that use only some of the technologies from the Java EE stack. This group of developers would not like to incur the overhead of startup-time/memory for all the services they would not use.
Hence now, the Sun Java System Application Server does not start all the containers during startup. In fact when you install Application Server and start it afresh, there will be only a handful essential services initialized, namely a local JNDI provider, JMX connector (for administration). Now, how would a developer configure the application server to use the other services?
That is the best part of the feature. User doesn't need to do anything special to initialize the other services that are not started by default. The user uses the application server as he normally would. As and when a service is used, the Application Server will transparently start it.Here are some details about the implementation.Mainly there are 3 "entry points" to the Application Server. The entry points are basic functionality in the Application Server that will be used while accessing a user-facing service in Application Server.
1. JNDI Lookup.
Many services and resources in Application Server are looked up using a JNDI name. Examples? Looking up an EJB, a JDBC resource, a JMS connection factory...
2. Server Ports.
Whenever you do something with the Application Server, a server port is accessed. It can be when you try to see the index.html of the webserver , or connect to the JMS provider from a standalone application, or it can be when you try to lookup a JDBC resource from server's JNDI provider from a standalone Java application.
3. Application Loader.
During the loading of an application,the application Server will read the deployment descriptor of the application for house keeping operations and initialization of the application.
Whenever a user-request reach any of these entry points,the Application Server will identify the type of incoming request and start all relevent services (or service groups) that are required. For example, if the user is accessing http port and if webserver is not started, then the webserver is started lazily/transparently. Or if user is accessing JMS port and JMS provider is not started, Application Server will start the JMS provider. When an ear file containing a EJB is loaded, and ORB is not yet started, Application Server will start ORB.
Note: Opposite to lazy loading is <load on startup>1
