glassfish
  1. glassfish
  2. GLASSFISH-12633

EJBContainerProviderImpl ignores classpath entries when they are EJB modules but not specified using EJBContainer.MODULES

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: future release
    • Component/s: ejb_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      12,633

      Description

      I am using GF 3.1 build 9.
      The faulty code is (EJBContainerProviderImpl.getRequestedEJBModuleOrLibrary,
      lines 281 - 285):

      DeploymentElement result = null;
      ...
      if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
      result = new DeploymentElement(file, isEJBModule);
      }

      return result;

      The use case: the container is started and the EJB modules are specified:
      return EJBContainer.createEJBContainer(parameters);
      where parameters contains a mapping EJBContainer.MODULES -> "ejbmodules".

      Still, every classpath entry is checked whether it is an EJB module or WAR or
      simple lib (EJBContainerProviderImpl.getRequestedEJBModuleOrLibrary method) - I
      don't think this should happen, it should first check if the classpath entry is
      listed in MODULES. But that's not the real problem.

      The problem is that some classpath entries can be discivered as EJB modeles, and
      not listed in MODULES, so they should be probably treated as plain library
      entries. However, the code quoted above fails to do so - in the described test
      case, the 'if' will never return true - isEJBModule is true, so it will go on to
      the last condition, which checks whether the name is within the required modules

      • and the DeploymentElement will remain null, effectively making the whole
        classpath entry excluded from deployment.

      If I use a library that has an EJB for some reason, the described behaviour will
      simply ignore it and the application will blow up in runtime.

      I think the check whether an EJB module is listed using MODULES should be done
      earlier, as if it is not listed, it doesn't really matter if there are EJBs or
      not, it should be a plain library entry. If however, for some reason, the name
      check is to stay as it is, the quoted 'if' should be changed, something like:

      if (isEJBModule && !moduleNames.contains(moduleName)) {
      isEJBModule = false; // treat entry as plain library
      }
      if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
      result = new DeploymentElement(file, isEJBModule);
      }

      or

      if (!isEJBModule || moduleNames.isEmpty() || moduleNames.contains(moduleName)) {
      result = new DeploymentElement(file, isEJBModule);
      } else if (isEJBModule && !moduleNames.contains(moduleName)) {
      result = new DeploymentElement(file, false); // treat the entry as library
      }

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            marina vatkina
            Reporter:
            szczyp
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: