. Proposal for V3 :
With the Repository facility, it becomes quite easy to control the order the repositories are searched to provide more flexibility than static parameters.
V3 modules and libraries
Each repository is organized with a duet of directory, the repository itself where we get the modules and a jars subdirectory where we load all the jars (libaries) directly referenced from a module's manifest CLASSPATH attribute.
On startup V3 should be configured with a few repositories (see table below) each of these repository can have a optional jars subdirectory where all the libraries will be stored and accessed. This point is not to keep the file server layout compatible but try to keep the users experience compatible.
For instance we should not plan to continue support for :
- domain.xml classpath configuration
- in place upgrade from V2 to V3.
- any feature that requires JVM parameters (unless customer needs it and adds it to the configuration).
Additional glassfish executables :
appclient
The appclient today is loading most of the application server code in the client due to lack of modularity. Appclients also inherit most of the shared libaries that users may have added to the configuration.
upgrade
tbd
verifier
tbd
Shared repository
For backward compatibility, it might be useful to define a shared repository where jar files (not modules) can be loaded from. This is particularly useful for things like jdbc drivers that can be loaded from a Class.forName() call. This can also be used for other sorts of backward compatibility issues around system libraries in V3. Such libraries would be accessible by all the application server modules as well as the applications themselves, this would be implemented using a parent class loader scheme. We can use a specific directory like lib/shared.
Container pluggability
Although nothing prevents container to install themselves in the main lib repository, it is better to separate each container by installing them in a different repository (subdirectory for instance) :
- quicker startup as we parse less modules metadata
- clear separation between the nucleus runtime and the containers
- services implementation only discovered once the repository is added to the runtime
- easy removal of a particular container (rm -rf...)
so for instance, taking the web container as a example, we can install of the web container's module in lib/web (with dependent jars in lib/web/jars).
Configuration/CLI commands dilemma
The layered approach although tempting introduces some complexity around Services discovery. If a particular container repository is not known to HK2 runtime until the container is started, the configuration and potentially Services implementation like CLI command cannot be discovered until the container is started. This is clearly a problem for things like CLI commands, you would want the EJB container to define EJB specific CLI commands and have these commands available as long as the container is installed not necessarily started.
There is probably a need to a differed initialization of the sub repositories once the V3 has started so it does not impact startup time but this introduce complexity due to the dynamic nature of container's startup in V3 (we don't necessarily know how many we have until sniffers have ran successfully). We could alternatively ask the container developer to install such shared components (CLI commands, configuration elements) in our of our shared repository keeping only the container implementation in a sub directory.
Compatibility
lib/*.jar versus lib/shared.
In V3, customers had the ability to put jars in the lib directory and have these jars automatically added to the application server classpath. This is not very useful to add such libraries in V3 as they would only be loaded if one of the application server's module CLASSPATH referenced them. It can however be useful for applications to install frameworks like Spring, however people should have used the appLibs directory for that.
For simplicity and backward compatibility we might want to just consider lib/shared for this kind of use case. Should we then rename the lib repository in something like <installRoot>/modules and keep lib empty for backward compatibility.
addons
Add ons developed for previous versions of the application server will need to be massaged to fit in this architecture unless they were not using any appserver services. However, there might be some documentation updates necessary on how to install and remove addons since they will most likely leverage HK2 download facilities. There might also be a need to develop at least one HK2 module that would defines the addon container.
Proposed Layout
Assuming we use <installRoot>/modules to store all of our nucleus modules, we could do
Application Server layout
Jspwiki style: h1
