13 Replies Latest reply on Sep 12, 2005 12:57 PM by starksm64

    Composition of build artifacts into higher level builds

    starksm64

      So the initial foray into the jbossas installer brings up a problem with being able to incorporate existing component artifacts into a new release type of build. The problem is that for every artifact that one would like to customize as part of the installer, a duplicate artifact needs to be maintained. Currently the duplicate artifact(a jboss-service.xml descriptor as an example), needs to be marked up with the velocity template to allow the installer to customize the features the user changes.

      I question whether a build that allows for a canonical artifact definition is possible. One extreme would require that a service like the tomcat deployer define artifacts for the jboss-service.xml and server.xml fragments, and these would be composed differently by the standard jbossas dist build vs the jbossas installer.

      Alternatively, the jbossas installer could just transform the artifacts into the velocity templates using xslt for example. In this case you could argue that although there is an xlst for each artifact that needs to be changed, its not a duplicate. There certainly still is a synchronization issue.

      Another approach would be to introduce the velocity template at the base component artifact level, and have a default command line installation mode that simply produces the existing default jbossas dist output. This would allow for simplification of the current testsuite custom jboss server configurations that are generated as the same "installation process" could be used with different variables/component selection.

      Its just a question of what is easiest to keep in synch. This thread is just a starting point for how we want to move forward in developing a build system that facilitates component usage across the various build scenarios.

        • 1. Re: Composition of build artifacts into higher level builds

          Why use scripting at all? Why not just fix the configuration to include this notion?

          e.g.

          ports-policy.xml

          <policy name="Ports" class="org.jboss.server.Ports">
           <option name="Naming">1099</option>
          ...
           <option name="HTTP11">8080</option>
          </policy>
          


          tomcat-policy.xml
          <policy name="Tomcat" class="org.jboss.web.tc5.TomcatPolicy">
           <option name="JBossClassLoader">false</option>
           <option name="Port"><policy name="Ports" option="HTTP11"/></option>
          </policy>
          


          Tomcat's jboss-service.xml:
           <attribute name="UseJBossWebClassLoader"><policy name="Tomcat" option="JBossClassloader"/></attribute>
          


          NamingService:
           <attribute name="Port"><policy name="Ports" option="Naming"/></attribute>
          


          It might look like it just moves the problem, but it separates the user
          changeable options from the other configuration allowing
          the service configuration to evolve without breaking people's policy files.

          The default distro would have some predefined policy files,
          the installer can generate them from a GUI.


          • 2. Re: Composition of build artifacts into higher level builds
            starksm64

            This does not address all of the configuration usecases. One example from the tomcat server.xml is whether the mod_jk connector should be enabled. Another more complicated connector is whether the https connector should be enabled, and this would have dependencies on the configuration of the keystore. The server.xml file is not parsed by the jboss deployment layer today.

            Another j2ee descriptor example is enabling security of the jmx-console.war. The security constraints need to either be added or commented out/removed depending on the installation choice.

            A templating language is the only thing that can be used without having to change existing deployment/configuration processing semantics.

            • 3. Re: Composition of build artifacts into higher level builds

               

              "scott.stark@jboss.org" wrote:

              A templating language is the only thing that can be used without having to change existing deployment/configuration processing semantics.


              I'm never interested in "quick and dirty" :-)

              Especially when it leads to "out of band" dependencies.
              Its just a question of what is easiest to keep in synch

              And the same issue/problem arises for the admin console.

              So that is at least three places to update for every change in config.
              Not to mention the documentation/wiki.

              • 4. Re: Composition of build artifacts into higher level builds
                starksm64

                You still haven't given me a better solution.

                • 5. Re: Composition of build artifacts into higher level builds

                   

                  "scott.stark@jboss.org" wrote:
                  This does not address all of the configuration usecases. One example from the tomcat server.xml is whether the mod_jk connector should be enabled. Another more complicated connector is whether the https connector should be enabled, and this would have dependencies on the configuration of the keystore. The server.xml file is not parsed by the jboss deployment layer today.


                  Yes, we do not have full control over Tomcat configuration.
                  That is a problem regardless of these issues.
                  e.g. How does the Admin Console (running under Tomcat) configure Tomcat?


                  Another j2ee descriptor example is enabling security of the jmx-console.war. The security constraints need to either be added or commented out/removed depending on the installation choice.


                  This configuration does not have to be web.xml, it is just the spec location.
                  There is nothing to stop a J2EE server looking somewhere else, e.g. alt-dd

                  • 6. Re: Composition of build artifacts into higher level builds
                    starksm64

                     


                    Yes, we do not have full control over Tomcat configuration.
                    That is a problem regardless of these issues.
                    e.g. How does the Admin Console (running under Tomcat) configure Tomcat?

                    A template run through an engine of course. This is in line with the maxim any problem can be solved with another layer of indirection.


                    This configuration does not have to be web.xml, it is just the spec location.
                    There is nothing to stop a J2EE server looking somewhere else, e.g. alt-dd

                    The alt-dd is not supported in the web.xml or ejb-jar.xml descriptors. Its only supported from the ear application.xml.

                    • 7. Re: Composition of build artifacts into higher level builds

                       

                      "scott.stark@jboss.org" wrote:
                      [This is in line with the maxim any problem can be solved with another layer of indirection.


                      Including user confusion? :-)



                      This configuration does not have to be web.xml, it is just the spec location.
                      There is nothing to stop a J2EE server looking somewhere else, e.g. alt-dd

                      The alt-dd is not supported in the web.xml or ejb-jar.xml descriptors. Its only supported from the ear application.xml.


                      - e.g. alt-dd
                      + e.g. using a mechanism like alt-dd

                      • 8. Re: Composition of build artifacts into higher level builds
                        starksm64

                         

                        Including user confusion? :-)

                        Yes, its called hiring someone to specialize in the indirected solution.

                        e.g. using a mechanism like alt-dd

                        Now your deep into the indirection, and we'll have to hire one person just to deal with this one. Maybe IBM is more your style.

                        • 9. Re: Composition of build artifacts into higher level builds

                           

                          "scott.stark@jboss.org" wrote:
                          Maybe IBM is more your style.


                          No, the IBM solution would be to use xpath over xml files stored in a DB2 database
                          that can only be edited by booting yet another Websphere instance just to download
                          and run an applet :-)

                          • 10. Re: Composition of build artifacts into higher level builds

                             

                            "scott.stark@jboss.org" wrote:

                            e.g. using a mechanism like alt-dd

                            Now your deep into the indirection


                            What is wrong with having?

                            <jboss-web>
                             <alt-dd>somewhere/else</alt-dd>
                            </jboss-web>
                            


                            or even just

                            <jboss-web>
                             <security-constraint/>
                            </jboss-web>
                            


                            Of course, you know that my preference is really aspectized deployment
                            WEB-INF/security.xml

                            I'd prefer any of these solutions to having to modify a velocity template
                            everytime I add a configuration option.
                            Although, it might stop me adding new configuration options (which wouldn't be a bad thing :-)

                            • 11. Re: Composition of build artifacts into higher level builds
                              starksm64

                              The problem is that this will not work without a major change to the tomcat deployer to be able to inject web.xml configuration elements after the fact. Alternatively, the deployer would have to be modified to merge the alt-dd into the web.xml passed to tomcat.

                              I appreciate the feeling of abhorrence to introducing the templating to the descriptors, but until we have a consistent treatment of overriding/augmenting jboss and standard deployements with configuration info in a consistent manner, I'm not seeing a solution in the descriptor indirection.

                              • 12. Re: Composition of build artifacts into higher level builds

                                Like I said before, I'm not interested in "workarounds".

                                If this can be done with just templates inside the installer then I am ok with this kludge.

                                But, if (like some other recent changes) this leads to other kludges (inside JBoss)
                                to fix this kludge, etc., we just introduce more and more cruft that becomes
                                impossible to change/fix properly later.

                                • 13. Re: Composition of build artifacts into higher level builds
                                  starksm64

                                   

                                  throw new StackOverflowError("Insufficient progress on a 4.0.x solution")
                                  


                                  So this discussion needs to turn to something that improves the prospects for the 5.x installer.