7 Replies Latest reply on Sep 7, 2010 2:35 PM by Brian Stansberry

    XML File Deployments

    Jason Greene Master

      In past discussions it seemed unlikely that we would support XML deployments. This was for the following reasons:

       

      1. The file would have to specify module configuration inline for it to even work (there is no more flat classpath in AS7) [and be polluted with other various AS internal info]
      2. Configuration is no longer a "deployable" notion. The domain config contains all admin focused configs and supports runtime updates. This includes which subsystems are available
      3. Code must be associated with it to really be worth being a deployment, so why not just bundle the code with the deployment? Even some kind of templating/scripting would likely be better represented as multiple files.
      4. Everything you can do with an XML file can be done with an archive containing the XML file

       

      Is there a strong case for it that was missed?

        • 1. Re: XML File Deployments
          David Lloyd Master

          Sounds like you nailed all the important points to me  I think the domain management philosophy directly opposes MC-style deployable XML files.

          • 2. Re: XML File Deployments
            Alexey Loubyansky Master

            The reason why it is convenient is that when you have a common library which is stable (or mostly stable and if it needs an update then all the services based on it need the update) and want to configure multiple services (i.e. create multiple instances) with different configuration.

            So if you bundle the library with each deployment then:

            - to modify the config you need to repackage;

            - to upgrade the common library you'll need to repackage all the deployments including it.

            • 3. Re: XML File Deployments
              Scott Stark Master

              So why not have a deployable configuration fragment that addresses the specification of the module and bean configuration in a DSL more approriate than the full mc syntax. Having multiple deployments of common beans seems like a rather common usecase.

              • 4. Re: XML File Deployments
                Jason Greene Master

                OK so the use case that I was missing is that we ship some kind of simple varia/example/one-off services which are more like application utilities then subsystems (note that the domain model allows for adding custom subsystems). At which point we have full control over the xml, and its superfluous to wrap a single xml file in a jar.

                • 5. Re: XML File Deployments
                  David Lloyd Master

                  Alexey Loubyansky wrote:

                   

                  The reason why it is convenient is that when you have a common library which is stable (or mostly stable and if it needs an update then all the services based on it need the update) and want to configure multiple services (i.e. create multiple instances) with different configuration.

                  So if you bundle the library with each deployment then:

                  - to modify the config you need to repackage;

                  - to upgrade the common library you'll need to repackage all the deployments including it.

                  Do you have some more specific examples?  I don't see how this justifies single-file deployments.  It seems that at most this implies the need for deployment descriptor types (inside an archive) to override settings.

                  • 6. Re: XML File Deployments
                    Alexey Loubyansky Master

                    David Lloyd wrote:

                     

                    Alexey Loubyansky wrote:

                     

                    The reason why it is convenient is that when you have a common library which is stable (or mostly stable and if it needs an update then all the services based on it need the update) and want to configure multiple services (i.e. create multiple instances) with different configuration.

                    So if you bundle the library with each deployment then:

                    - to modify the config you need to repackage;

                    - to upgrade the common library you'll need to repackage all the deployments including it.

                    Do you have some more specific examples?  I don't see how this justifies single-file deployments.  It seems that at most this implies the need for deployment descriptor types (inside an archive) to override settings.

                    If you have a library of classes that can be used to create a set of services, JMX beans, other managed beans, EJBs, etc, this library can be put into the servers classpath and then by deploying just deployment descriptors you can create new services, managed beans, EJBs, etc.

                    This feature was added previously to avoid creating JARs that contain only service XML files. Plus, with hot deploy tracking the file modifications it's like WYSIWYG editor (after the save of course).

                    • 7. Re: XML File Deployments
                      Brian Stansberry Master

                      There's been a lot of discussion on this thread on why we would support this; i.e. what the use case is.

                       

                      I think it would be educational to hear more about why we wouldn't; i.e. what are the problems it causes.

                       

                      At this point we have on the pro side IMHO kinda abstract use cases (I'd love to hear an actual concrete example where declaring subsystems wouldn't suffice) while on the con side it's unclear.