3 Replies Latest reply on Mar 10, 2010 9:19 AM by brian.stansberry

    EE Application Names

    brian.stansberry

      This is related to the EE module name work discussed at http://community.jboss.org/thread/148991?tstart=0

       

      That work is implementing the EE.8.1 requirements re: modules names. Implementing those specs is leading to a behavior change versus previous releases, in that 2 non-ear deployments, e.g. application.war and application.jar, fail to deploy.

       

      One of the requirements is that a module name for a module not contained in an ear, if not specified in the deployment descriptor, is, per EE.8.1.2

       

      .. the base name of the module file with any extension (.war, .jar, .rar) removed and with any directory names removed.

       

      So, the "module name" for both application.war and application.jar would be "application". This is leading to deployment failures, like this seen when ACLIntegrationUnitTestCase tries to deploy an acl-integration.jar after previously deploying an acl-integration.ear:

       

      20:13:57,189 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to PreInstall: name=jboss.naming:module=acl-integration aliases=[java:module] state=Real: java.lang.IllegalStateException: Unable to register context name=jboss.naming:module=acl-integration aliases=[java:module] state=Real, name already exists: jboss.naming:module=acl-integration

       

      We don't actually have to support this use case. EE.8.1.2 further states that:

      when a stand-alone module is deployed, the module name is used as the application name, and obeys the same rules as described above for application names.

       

      The "same rules described above say:

       

      The name of an application must be unique in an application server instance. If an attempt is made to deploy an application with a name that conflicts with an already deployed application, the deployment tool may choose a new unique name for the application.

       

      So, we "may" help the user by choosing a new application name, but we don't have to. Question is, do we want to? Note that for users to work around this they can either give their deployment artifacts distinct names, or use the "module-name" element in all the EE 6 deployment descriptors to set unique names.

       

      I think it would be simple enough to write a deployer that tracks the application name of all applications that pass through it and generates a unique name for the application if there is a conflict. This would be limited to ears or wars/jars/rars not packaged in an ear.

       

      In order to complete my module naming work, I'm going to fix the testsuite deployments that are showing this issue (i.e. have them specify unique names.) Whether we decide to generate unique application names is a separate issue.

        • 1. Re: EE Application Names
          brian.stansberry
          This is leading to deployment failures, like this seen when ACLIntegrationUnitTestCase tries to deploy an acl-integration.jar after previously deploying an acl-integration.ear:

           

          Typo there -- the previous deployment was acl-integration.war  -- not .ear.

          • 2. Re: EE Application Names
            wolfc

            If we don't have unique application names we run into trouble binding beans.

            java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-qualified-interface-name>]

            • 3. Re: EE Application Names
              brian.stansberry

              Yes, for sure the 2nd application won't deploy properly. Question is do we want to make up a unique name for the 2nd app, or just require the user to rename the deployment or configure a unique name in it's deployment descriptor. The spec gives us leeway.

               

              Writing a deployer to detect conflicts and make up a unique name wouldn't be hard; it's mostly a matter of thinking if there are any gotchas, reasons why trying to do this would be opening up a can of worms.

               

              Said deployer would have to run after (or be part of) ModuleNameDeployer, as that's what figures out the default name for modules. That currently runs in PRE-REAL as it must run after metadata generated by scanning is available. So one theoretical gotcha would be if changing the application name in PRE-REAL was too late. (I'm just brainstorming a bit here.)