glassfish
  1. glassfish
  2. GLASSFISH-18329

Deployment/kernel cleanup - Phase 4: Misc Tasks

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0_b22
    • Fix Version/s: future release
    • Component/s: deployment
    • Labels:
      None

      Description

      Hong,

      I am creating this task to capture what we discussed the other day. As you might have noticed, I have cleaned up XModuleType which was a prerequisite for these items. Feel free to create subtasks if you wish. I am definitely hopeful doing all these will not only give us cleaner code, but also improve performance. Moreover, this will also help us getting closer to modular dol.

      1) Move DeploymentUtils.isEJB/isWAR/isEAR/isRAR/isCAR to respective ArchiveDetector.handles(). Because cloud folks and admin gui introspects archive without deployment context, we need two methods: one that accepts DeploymentContext so that it could retrieve the information already computed in earlier stages of deployment and another one that just takes an Archive.

      2) deployer sorting cleanup

      3) Fix the following code which is in DeployCommand in nucleus: // done to disable versioning support for osgi
      if ( name != null && !isUntagged && type != null && type.equals("osgi") ) {

      4) Preselect certain sniffers to improve performance - especially for ejbjar. This is no longer a low priority, as this has to be fixed in order to address the osgi archive type support.

      5) Remove List<Sniffer> prepareSniffersForOSGiDeployment(String type, DeploymentContext context) from Deployment; Its implementation in ApplicationLifecycle is incorrectly treating type as containerType instead of archiveType. The man page says it is archive type. Moreover, it seems to be created as a shortcut to address issues involved in OSGi archive type support. While doing this, make OSGiArchiveHandler a non-composite handler.

      Optional:
      6) It will be better to introduce an abstraction called DeploymentUnit with subclasses like Ear, EjbJar, War, Rar, Car, PlainJar, OSGiArchive, etc. It represents the structure of the bits getting deployed. Adding a new DeploymentUnit is a very expensive operation. It is like adding a new language in an extensible extensible compiler architecture. ArchiveHandler can be a producer of these objects with a source Archive as input. Since this is a stateful object, this can be set in DeploymentContext as opposed to storing a stateless object like ArchiveHandler. DeploymentUnit can have a method called getModuleType(): XModuleType. DeploymentUnit should also have a method called getSource(): ReadableArchive.

      7) Remove all XXX_SNIFFER_TYPE constants from Application config bean. This will also require a change in ApplicationLifecycle which is using CONNECTOR_SNIFFER_TYPE to decide which applications to load first. We should separate that as a strategy and provide it from j2ee server distribution. Instead of looking for sniffer types, use archive type and define a loading order for each archive type. Allow the loading order to be overridden by application metadata during deployment: to be done

      8) Add a method in ArchiveHandler called getEmbeddedClasses() which can be used by SnifferManagerImpl to iterate over while looking for annotations. This will avoid the hack we have in DeploymentUtils.getModuleLibraryJars() which being in nucleus knows about all the archive types and not at all extensible.

      9) Why don't we call Sniffer.handles() first before looking for annotations in SnifferManagerImpl.getSniffers()?

      Thanks,
      Sahoo

        Issue Links

          Activity

            People

            • Assignee:
              Hong Zhang
              Reporter:
              Sanjeeb Sahoo
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: