1 2 3 4 5 Previous Next 69 Replies Latest reply on May 28, 2010 7:11 PM by dmlloyd Go to original post
      • 15. Re: domain.xml work
        starksm64

        What would be an example of injecting a configuration fragment?

        • 16. Re: domain.xml work
          emuckenhuber

          Like tomcat (server.xml), or hornetQ (hornet-configuration.xml). Otherwise we would need to create MCBeans only to override the configuration. We don't have this notion anywhere at the moment, but i in those cases it could be useful to skip the scanning for beans and overriding the beanmetadata.

          • 17. Re: domain.xml work
            starksm64
            1. This is beyond the current doman model discussion. This is truly MDR level overrides of either domain.xml of ManagedComponent properties at a level above the server
            2. I'm not envision that we create any components at the domain or higher. We only have overrides of properties to components associated with a deployment. The domain or higher model may define which deployments are active, but not any actual deployments.
            3. I assumed the answer was no I belive?
            4. The only way this applies is if the metadata for FooComponent intersects with the metadata in the domain.
            5. The only question I see is whether a given domain.xml setting actually applies to a deployment. As it stands now we would not know until runtime.
              • 18. Re: domain.xml work
                emuckenhuber

                For 2) how about a DeploymentTemplate would only create a component metadata in the domain.xml, without a physical deployment. This does not handle local deployments, but is maybe closer to what you want to do with JON?

                • 19. Re: domain.xml work
                  starksm64

                  Right, and my answer for 4 is too generic. JON adds a constraint in a sense to ManagedComponents based on their type/subtype. A ManagedComponent has a type(DataSource, JmsDestination, etc.) and a subtype(LocalTx, Topic, ...). They use this to define the expected properties and operations. So, the exposed ManagedComponent for these type/subtype have an implicit contract based on the rhq-plugin.xml. The domain.xml metadata is largely a pojo representation of type/subtype property structures.

                   

                  A FooComponent has a representation in the domain.xml if its type/subtype is one we have pulled into the domain model. The only thing we don't know is if the FooComponent instance in question exists.

                   

                  The DeploymentTemplate notion Emanuel brought up is simplified, property only view of a ManagedComponent that defines the minimum set of properties that need to be defined in order to create a deployment. If you are thinking of meta-metadata at admin domain and cluster levels where you define defaults for properties like pool sizes, etc., that is something I would also view as true MDR behavior we would need integrate into the implementation. This is not something we would target for implementing initially for EAP6.

                   

                  As we get into admin clusters and domains I can see that we will have overrides, and perhaps even new metadata that intersects with the domain.xml representations for things like HA features, DNS, networks, etc.

                   

                  We really have no ManagedComponents for these features anyway.

                  • 20. Re: domain.xml work
                    jason.greene

                    Scott Stark wrote:

                     

                    1. This is beyond the current doman model discussion. This is truly MDR level overrides of either domain.xml of ManagedComponent properties at a level above the server

                     

                    While we are looking at doing just the server side up front I think it's an important question to answer. It's really a question of what the jboss-management ManagedComponent view represents. Is it a representation of the client view, and thus has a direct mapping to a future multi-server domain.xml, or is it a normalized/realized post-evaluated view? Long term, It can't really be used as a client api if it is solely the latter.

                     

                    It seems like it could be both though, and that's compatible with the approach you describe. A client can edit a view (one that could just be a bunch of managed components, or it could even be static metadata since the model is itself static), and that view would then be transformed into something a service or deployer could act on. In the end this would be realized in changes to the runtime MOs.

                    • 21. Re: domain.xml work
                      starksm64

                      The ManagedComponent view is an admin client view of the deployment metadata, including any override values applied previously. This view would show the value of properties that are specified at an admin domain view, but if I change such a property I have overriden it at a component level. It is a post admin edit view. If we are to allow editing of a local server domain.xml, changes to a ManagedComponent view would have to propagate to the domain.xml. Changes to properties that are dervied from some higher level admin domain would not be propagated because you would not be specifying the domain level value. The admin domain would have a separate component for that.

                      • 22. Re: domain.xml work
                        jason.greene

                        Scott Stark wrote:

                         

                        The ManagedComponent view is an admin client view of the deployment metadata, including any override values applied previously. This view would show the value of properties that are specified at an admin domain view, but if I change such a property I have overriden it at a component level. It is a post admin edit view. If we are to allow editing of a local server domain.xml, changes to a ManagedComponent view would have to propagate to the domain.xml. Changes to properties that are dervied from some higher level admin domain would not be propagated because you would not be specifying the domain level value. The admin domain would have a separate component for that.

                        I just started a requirements wiki for the full domain system here:

                        DomainRequirements

                         

                        I added requirements 5 and 6 should to represent the above:

                         

                        • All client interfaces must be able to view the logical domain model representation
                        • All client interfaces must also be able to view non-classified components, those which are not part of the domain but instead come from deployments or legacy management mechanisms..

                         

                        IMO this will be a useful thing to go over during our upcoming meeting.

                        • 23. Re: domain.xml work
                          starksm64

                          By non-classified do you mean components who's type is not in the domain.xml? If that is the case then requirement 7 about the domain model always takes precedence over  non-classified components is always true.

                          • 24. Re: domain.xml work
                            brian.stansberry

                            Scott Stark wrote:

                             

                            The ManagedComponent view is an admin client view of the deployment metadata, including any override values applied previously. This view would show the value of properties that are specified at an admin domain view, but if I change such a property I have overriden it at a component level. It is a post admin edit view. If we are to allow editing of a local server domain.xml, changes to a ManagedComponent view would have to propagate to the domain.xml. Changes to properties that are dervied from some higher level admin domain would not be propagated because you would not be specifying the domain level value. The admin domain would have a separate component for that.

                             

                            This is something we need to discuss with the console folks. Having a separate view for updating the domain is simpler but not particularly intuitive from a UI point of view. Perhaps more intuitive for a CLI though.

                            • 25. Re: domain.xml work
                              jason.greene

                              Scott Stark wrote:

                               

                              By non-classified do you mean components who's type is not in the domain.xml? If that is the case then requirement 7 about the domain model always takes precedence over  non-classified components is always true.

                               

                              I actually meant everything, regardless of type. I can't really think of a case where the administrator specified domain.xml would be secondary to whatever a deployment specifies. Did you have an example in mind where we would want the deployment to take precedence?

                              • 26. Re: domain.xml work
                                brian.stansberry

                                Requirement #2 is somewhat in conflict with some of what I've read on this thread, wherein the domain.xml configuration data is applied as an override. That means the primary and authoritative representation of the domain is the combination of wherever the overridden configuation values come from + the domain.xml configuration.

                                 

                                That's always going to partially be the case, because all the IOC wiring stuff is really configuration.  But how far are we looking to push this concept? I'm going to give a specific example below, but I'm less interested in the specifics than the general issue of how much is meant to be coming from domain.xml.

                                 

                                For example, how does the profile configuration fit in? Referring to

                                 

                                a) the "user configuration" stuff described at http://community.jboss.org/docs/DOC-14742

                                b) the "server configuration" stuff described at http://community.jboss.org/docs/DOC-14743

                                 

                                We could, in increasing order of verbosity:

                                 

                                1) Ignore the whole thing; the profile name comes from -c and the configuration is outside of domain.xml

                                2) Declare the profile name in domain.xml (or maybe via -c) and allow some configuration overrides (e.g. a hot-deployment scan period)

                                3) Include a) in domain.xml

                                4) Include a number of a)s in domain.xml and use -c to set which one is used

                                5) Include both a) and b)

                                6) Include a bunch of a)s and all possible b)s

                                 

                                Options 2, 3, 4 seem reasonable.

                                 

                                * The same kind of thing pops up with Infinispan and JGroups configs, where AS 5 provides a number of named valid configs to choose from and the services that need a cache/channel include the name to use in their own config, with a global property to set defaults.

                                • 27. Re: domain.xml work
                                  emuckenhuber

                                  Yes we certainly agree on the stable api part and i was not thinking about a dynamic content model. However i think it should be possible for e.g. SOA-P and EPP to extend this model and add their own fragments - without needing a new release of profileservice or AS. Where this might be more an issue for the server side handling which should not be visible to a user nor affect the stability of the API.

                                  • 28. Re: domain.xml work
                                    emuckenhuber

                                    Well at least (a) (the user configuration) should be part of the domain.xml. So that all nodes in a domain not only have a consistent configuration, but also activate the same services - regardless of -c. This is why it is important that all our deployments are moved to a common repository.

                                     

                                    (b) is a bit different. The server side configuration more represent modules, which are available in a repository and shared across multiple domains. Ultimately this has to move to a domain level, where we can use a provisioning service to provide the appropriate version of the module for a domain. Where different domains might have different versions of modules.

                                    • 29. Re: domain.xml work
                                      emuckenhuber

                                      I guess we also should think about the behavior for active (running) domains - so that a active domain always takes precedence over a new node joining this management domain.