1 2 3 Previous Next 32 Replies Latest reply on Jun 17, 2010 7:09 AM by Emanuel Muckenhuber

    Profiles in domain.xml

    Alexey Loubyansky Master

      Ok, I'm new here, so to catch up I'll be asking questions of various degrees of ignorance.

       

      AFAIU, domain.xml can list profiles necessary to start a server instance. I want to better understand the purpose and effects of this.
      What kind of profiles are those? E.g. would web or ejb profiles be an example?
      The reason it's confusing to me is that domain.xml also lists containers, including e.g. web-container. So, the presense of web-container in domain.xml kind of implies the presense of the web profile. Or am I missing something?

      What if the web profile is not on the list but web-container is present?

        • 1. Re: Profiles in domain.xml
          David Lloyd Master

          Alexey Loubyansky wrote:

           

          Ok, I'm new here, so to catch up I'll be asking questions of various degrees of ignorance.

           

          AFAIU, domain.xml can list profiles necessary to start a server instance. I want to better understand the purpose and effects of this.
          What kind of profiles are those? E.g. would web or ejb profiles be an example?
          The reason it's confusing to me is that domain.xml also lists containers, including e.g. web-container. So, the presense of web-container in domain.xml kind of implies the presense of the web profile. Or am I missing something?

          What if the web profile is not on the list but web-container is present?

           

          No, this was my conclusion as well.  In fact I think that the presence of the web container isn't the only thing that should imply that a web container should be set up.  Any web-affecting deployment (WAR, or web services, or even something indirect) should trigger the "profile"'s existence.  Perhaps the web container ought to have sensible defaults in the event that no information is specified but web deployments are present.  Or perhaps in this event, the default web container definition will automatically be written back to domain.xml?

           

          Anyway that's just my opinion.

          • 2. Re: Profiles in domain.xml
            Brian Stansberry Master

            I think if elements like threads, security-policy, containers etc exist outside of a server-group (or one if it's children) it should either be because:

             

            1) Whatever the element describes is intrinsically scoped to the domain (e.g. domain-configuration)

             

            or

             

            2) That element serves as a common confiugration that can be referenced by a (child of) server-group, to avoid having to repeat things across multiple server-group elements.

             

            The latter can save a lot of boilerplate in a complex domain, but it's not intuitive. Perhaps such elements should be enclosed in a container element (e.g. "templates") that explains their usage. (I don't like "templates", just haven't thought of anything else.)

             

            I definitely don't think that the presence of something like web-container at the domain level should imply that every server runs a web container.

             

            If we follow David's thinking that a server's capabilities are determined by what the end user deployments required, then the fixed profile notion largely goes away. Then there could be a 3rd usage for things like threads, security-policy, containers, etc:

             

            3) as the default configuration for X if it turns out that deployments in a server-group introduce a requirement for X.

            • 3. Re: Profiles in domain.xml
              Brian Stansberry Master

              David Lloyd wrote:

               

              Perhaps the web container ought to have sensible defaults in the event that no information is specified but web deployments are present.  Or perhaps in this event, the default web container definition will automatically be written back to domain.xml?

               

              Can't/shouldn't these defaults exist in the schema itself?

              • 4. Re: Profiles in domain.xml
                David Lloyd Master

                Brian Stansberry wrote:

                 

                David Lloyd wrote:

                 

                Perhaps the web container ought to have sensible defaults in the event that no information is specified but web deployments are present.  Or perhaps in this event, the default web container definition will automatically be written back to domain.xml?

                 

                Can't/shouldn't these defaults exist in the schema itself?

                 

                Maybe in principle, but think of things whose default value might depend on environmental settings (i.e memory size or number of CPUs), or the case where we make a mistake and supply a default which is not reasonable and we have to fix it.  The schema is a lot less mutable than our runtime configuration could be.

                • 5. Re: Profiles in domain.xml
                  Alexey Loubyansky Master

                  The thing is, if web profile is included then there must be web-container element (well, eveb if maybe not in theory, in reality I imagine it will always be provided). So, I still don't see a value of listing web profile in addition to that, looks like it's redundant.

                   

                  Actually, I've talked about profiles to Emanuel today. The conclusion was that the user/admin doesn't have to deal/understand/know the notion of a profile, the profiles (with their config details) shouldn't be exposed to the admin and remain our internal implementation detail.

                   

                  I want to clarify this point with everybody and make sure we are all on the same page.

                  • 6. Re: Profiles in domain.xml
                    Brian Stansberry Master

                    That sounds nice. To me the key thing a profile definition does is identify the capabilities a server has. If we can get away from users having to list in advance what capabilities a server has, just let it figure out what capabilities are required based on deployments, then great.

                     

                    Let's just keep in mind though that doing that is not a hard requirement (i.e. a formal product requirement), it's something we *want* to do.

                    • 7. Re: Profiles in domain.xml
                      Brian Stansberry Master

                      David Lloyd wrote:

                      Brian Stansberry wrote:

                       

                      Can't/shouldn't these defaults exist in the schema itself?

                       

                      Maybe in principle, but think of things whose default value might depend on environmental settings (i.e memory size or number of CPUs), or the case where we make a mistake and supply a default which is not reasonable and we have to fix it.  The schema is a lot less mutable than our runtime configuration could be.

                       

                      If the default is a derived from environment settings then we should either expose the non-enviromental portion of the calculation or come up with some other way to express it.

                       

                      The key thing to me is to not be pulling data from all over the place; the domain configuration needs to be largely self-contained. If we want to say that domain.xml is the end user document and some standarddomain.xml[1] located next to it is the source of defaults, that's ok. Just not a situation like we have now where defaults are coming in from all over the place.

                       

                       

                      [1] A joke name, reference to the old standardjboss.xml that serves a similar function.

                      • 8. Re: Profiles in domain.xml
                        Scott Stark Master

                        We need the ability to lock down the features and configuration on a server. That is not to say that there is a need to support the implied capabilities given a set of applications. However, that would require some processing of the deployment in order to determine what capabilities were in use, including resources. So, if there is an abstraction like:

                         

                        <applications>

                           <web-app name="my-store" context-root="/the-best-store" ...>

                           </web-app>

                        </applications>

                         

                        how much work has to be done to adequately identify the required capabilities? We can define the default capabilities implied by the various application types, but ultimately the user should be able to trim that down if they are not using certain features.

                         

                        I still think the best comprimise would be to have profile definitions in the domain in terms of the required capabilities potentially simplified by having implied capabilities associated with each application type that could be overriden by the admin.

                        • 9. Re: Profiles in domain.xml
                          David Lloyd Master

                          Brian Stansberry wrote:

                           

                          David Lloyd wrote:

                          Brian Stansberry wrote:

                           

                          Can't/shouldn't these defaults exist in the schema itself?

                           

                          Maybe in principle, but think of things whose default value might depend on environmental settings (i.e memory size or number of CPUs), or the case where we make a mistake and supply a default which is not reasonable and we have to fix it.  The schema is a lot less mutable than our runtime configuration could be.

                           

                          If the default is a derived from environment settings then we should either expose the non-enviromental portion of the calculation or come up with some other way to express it.

                           

                          The key thing to me is to not be pulling data from all over the place; the domain configuration needs to be largely self-contained. If we want to say that domain.xml is the end user document and some standarddomain.xml[1] located next to it is the source of defaults, that's ok. Just not a situation like we have now where defaults are coming in from all over the place.

                          I get where you're coming from.  I'd just be concerned though if it got to a point where it is impossible to start up a server without a large and complex domain.xml file.  I don't like the idea of merging XML documents though.  I don't think the defaults would be coming from everyplace, just from components which are (a) managed and (b) are in use but were not specified in the domain.xml.

                           

                          Another scenario this could be relevant is where a component is upgraded, causing more features to become available.  The component might want to update its domain configuration with the new default values for the new features.  Patching a secondary XML file at upgrade time seems much messier than just using the defaults from a management perspective.

                          • 10. Re: Profiles in domain.xml
                            David Lloyd Master

                            Scott Stark wrote:

                             

                            We need the ability to lock down the features and configuration on a server. That is not to say that there is a need to support the implied capabilities given a set of applications. However, that would require some processing of the deployment in order to determine what capabilities were in use, including resources. So, if there is an abstraction like:

                             

                            <applications>

                               <web-app name="my-store" context-root="/the-best-store" ...>

                               </web-app>

                            </applications>

                             

                            how much work has to be done to adequately identify the required capabilities? We can define the default capabilities implied by the various application types, but ultimately the user should be able to trim that down if they are not using certain features.

                             

                            I still think the best comprimise would be to have profile definitions in the domain in terms of the required capabilities potentially simplified by having implied capabilities associated with each application type that could be overriden by the admin.

                             

                            OK so what I'm getting from this is a new requirement:

                             

                            "It shall be possible within domain.xml to specify what capabilities/subsystems are allowed (whitelist) or disallowed (blacklist) in order to ensure that undesired subsystems are not inadvertently started causing unexpected performance penalties."

                             

                            If we make this optional we get the best of both possible worlds.  On the one hand, only minimal configuration is required (the default would be an empty blacklist).  On the other hand, administrators can ban only certain subsystems, or lock it down tight if they want.

                            • 11. Re: Profiles in domain.xml
                              Scott Stark Master

                              David Lloyd wrote:

                               

                               

                              If we make this optional we get the best of both possible worlds.  On the one hand, only minimal configuration is required (the default would be an empty blacklist).  On the other hand, administrators can ban only certain subsystems, or lock it down tight if they want.

                               

                              I think that makes sense.

                              • 12. Re: Profiles in domain.xml
                                Brian Stansberry Master

                                Yeah, that makes sense. Thanks, David, for the wording. I've added it to the requirements doc.

                                • 13. Re: Profiles in domain.xml
                                  Brian Stansberry Master

                                  David Lloyd wrote:

                                  Brian Stansberry wrote:


                                   

                                  The key thing to me is to not be pulling data from all over the place; the domain configuration needs to be largely self-contained. If we want to say that domain.xml is the end user document and some standarddomain.xml[1] located next to it is the source of defaults, that's ok. Just not a situation like we have now where defaults are coming in from all over the place.

                                  I get where you're coming from.  I'd just be concerned though if it got to a point where it is impossible to start up a server without a large and complex domain.xml file.  I don't like the idea of merging XML documents though.  I don't think the defaults would be coming from everyplace, just from components which are (a) managed and (b) are in use but were not specified in the domain.xml.

                                   

                                  Another scenario this could be relevant is where a component is upgraded, causing more features to become available.  The component might want to update its domain configuration with the new default values for the new features.  Patching a secondary XML file at upgrade time seems much messier than just using the defaults from a management perspective.

                                   

                                  Let's get into some use cases.

                                   

                                  1) Admin uses tool that communicates with DC to see current configuration of running domain.  That means all the default values a) have to be present in the in-memory domain model so they can be displayed and b) have to be present in the in-memory domain model on the server acting as the DC.

                                   

                                  So a) means the

                                  components which are (a) managed and (b) are in use but were not specified in the domain.xml

                                  must be provided with an SPI via which they can publish the defaults back to the domain model.  Not the end of the world.

                                   

                                  But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC.

                                   

                                  We could say the DC has the ability to query the Servers to determine defaults, but besides being a can of worms it means the admin can't just start the DC and manipulate the domain configuration.

                                   

                                  2) Admin uses some other tool to access "the domain database" for a non-running domain and manipulate its configuration. This means the domain configuration needs to be in an accessible, persistent form; i.e.. I don't know if this is a real use case, but am throwing it out there just so we think about it. There is a nod toward it in some product requirements

                                   

                                   

                                  Instances                will still be configurable even if they are not currently running.                Changes will become active when the instance is next started.

                                   

                                  but it's not clear whether "Instances" means a Server (and not the DC) or whether it also means we can't require a DC. It's also unclear exactly what "configurable" means. If you can edit domain.xml in a text editor, the domain is configurable.  I'll try and get some clarity on this requirement.

                                   

                                  Re: the upgrade situation, that's a good general question. It does make clear the flaw in using the schema for defaults: if the user doesn't update their domain.xml to use new schema version, the new defaults are unavailable.

                                  • 14. Re: Profiles in domain.xml
                                    David Lloyd Master

                                    Brian Stansberry wrote:

                                    1) Admin uses tool that communicates with DC to see current configuration of running domain.  That means all the default values a) have to be present in the in-memory domain model so they can be displayed and b) have to be present in the in-memory domain model on the server acting as the DC.

                                     

                                    So a) means the

                                    components which are (a) managed and (b) are in use but were not specified in the domain.xml

                                    must be provided with an SPI via which they can publish the defaults back to the domain model.  Not the end of the world.

                                     

                                    But b) is more problematic. We could say the DC has access to all domain resources and can therefore start the components needed by any ServerGroup configuration and thereby determine the defaults. But... yuck. IMHO we should try really hard to avoid imposing any such requirement on the DC.

                                    Blah.

                                     

                                    OK how about this alternative view.  Things not specified in domain.xml are also not specified in the doman DB, and the host defaults take over, and there's no writing back to the domain database of defaults.

                                     

                                    So the total domain view is really the sum of the local host configuration plus the domain configuration at the end of the day.

                                    1 2 3 Previous Next