1 2 Previous Next 24 Replies Latest reply on Jul 7, 2010 12:48 PM by brian.stansberry Go to original post
      • 15. Re: svn location for domain schemas and xml examples
        dmlloyd

        Alexey Loubyansky wrote:

         

        David Lloyd wrote:

         

        In IRC discussions we've determined that identifying elements by XML ID is not something we need to do.  Elements have names that are relevant (or not) within their containing scope.

         

        So we shouldn't need any "id" attributes of type "ID" or any "IDREF"s.

        There are currently no 'id' attributes. There are 'name' and 'ref' attributes of types 'ID' and 'IDREF' though.

         

        For the reference (quoting http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/):

        - an ID must not appear more than once in an XML document as a value of this type; i.e., ID values must uniquely identify the elements which bear them;

        - the value  space of ID is the set of all strings that match the NCName production in [Namespaces  in XML] and have been used in an XML document;

        - the lexical  space of ID is the set of all strings that match the NCName production in [Namespaces  in XML].

        The problem is that the elements which have xs:ID as a type are all in separate namespaces.  So it's perfectly reasonable to have a security domain with the same name as a deployment with the same name as a thread pool.

        • 16. Re: svn location for domain schemas and xml examples
          dmlloyd

          Alexey Loubyansky wrote:

          David Lloyd wrote:


          The compromise we came up with was to have the deployments and their characteristics listed at a domain level, then at the server group level you list the assignment of deployment to server group.  This way every server group has a complete listing of its associated deployments (and a handy element which could potentially be used to provide per-server-group overrides); the domain has the complete overall listing (with a handy element which could be used for domain-wide overrides); and there's a concise mapping between them.

          Doesn't sound nice to me. Is it the same thing as Jason's original proposal but with listing all the deployments at the domain level? What would be the reason? Like with subsystems to "lock up" a set of possible deployments (like a deployment library)?

           

          Can we think of what would be the most common for server-group customizations deployment-wise, i.e. to more exclude or more include? Would exclusion be more like an exception?

          The reason I proposed for deployments to follow susbsystem-like way is because I thought that exclusion would happen much less often that inclusion.

          I understand that there is a use case where there are possibly hundreds of server groups in a domain.  There's no reason to believe that if this is the case that the server groups would be mostly similar.

           

          Also there may be some deployment types - like the domain controller itself - which definitely do not lend themselves to being applied to everything by default.

           

          Also it's reasonable to expect that deployment parameters might be overridden on a per-server-group basis even if a deployment spans many server groups in the domain.

          • 17. Re: svn location for domain schemas and xml examples
            aloubyansky

            Ok, perhaps my picture is limited here...

             

            Still just listing all the deployments at domain level doesn't make sense to me. Unless perhaps if they can be organised into deployment groups that later can be referenced/included by server-groups.

            • 18. Re: svn location for domain schemas and xml examples
              aloubyansky

              David Lloyd wrote:


              Also there may be some deployment types - like the domain controller itself - which definitely do not lend themselves to being applied to everything by default.

              Then if it's a unique server/server-group deployment-wise (if I understand it correctly) then again what's the point in listing its deployments at the domain level?

              • 19. Re: svn location for domain schemas and xml examples
                dmlloyd

                Alexey Loubyansky wrote:

                 

                Ok, perhaps my picture is limited here...

                 

                Still just listing all the deployments at domain level doesn't make sense to me. Unless perhaps if they can be organised into deployment groups that later can be referenced/included by server-groups.

                 

                They're at the domain level because this gives you the notion of a deployment "identity".  If a hosts's server manager has 8 hosts servers running in 8 server groups and 5 have the same deployment, you pull the deployment down only one time.  Without this notion, we could have some real scalability issues.

                 

                Now we could accomplish a similar thing by putting all the deployments at the server group level with an identifier (name+sha1) but then we'd lose the ability to override a deployment setting on a domain-wide basis - common overrides will have to be repeated in every server group.  (I'm thinking of things like adding overrides for a development environment perhaps, or for a run-time fix etc).

                • 20. Re: svn location for domain schemas and xml examples
                  brian.stansberry

                  David Lloyd wrote:

                  Now we could accomplish a similar thing by putting all the deployments at the server group level with an identifier (name+sha1) but then we'd lose the ability to override a deployment setting on a domain-wide basis - common overrides will have to be repeated in every server group.  (I'm thinking of things like adding overrides for a development environment perhaps, or for a run-time fix etc).

                   

                  We've gotten feeback from the field that people want to be able to configure applications (e.g. wars) without having to crack open the archive. Cracking the archive to add a jboss-web.xml means a 3 month delay. So I expect some users will want to do a fair amount of deployment configuration via the domain and not via the deployment descriptors. Repeating that in every server group wouldn't be so nice.

                   

                  I think a deployment-group notion at the domain level makes sense.

                  • 21. Re: svn location for domain schemas and xml examples
                    brian.stansberry

                    A new source tree for AS 7 is slowly taking shape in git.  Let's shift work on this to that repo. We're still in a bit of a brainstorming mode and git is a much better mechanism than svn+forums for people pushing out ideas.

                     

                    Jason's working on getting an "official" Red Hat repo set up. At the moment, the best repo to fork is David Lloyd's at http://github.com/dmlloyd/jboss-as

                     

                    Mine's at http://github.com/bstansberry/jboss-as

                     

                    Over the course of the day I'll be working to push stuff to http://github.com/bstansberry/jboss-as to get it up to date.

                     

                    There's a new #jboss-as7 chat room on freenode that's meant to be the central place for more quickly interactive discussions. Anyone working on this should hang out there.

                    • 22. Re: svn location for domain schemas and xml examples
                      emuckenhuber

                      I just copied the current state of the schemas from the profileservice project into my fork of jboss-as/domain. I used a new folder, since i don't want to conflict with the other stuff in there. From now on the work on the schemas should happen there and not in profileservice any more, so i'll most likely remove them from there to avoid confusion.

                      • 23. Re: svn location for domain schemas and xml examples
                        brian.stansberry

                        I pulled your stuff, merged it into the domain/src/main/resources/schema dir and pushed it to my github repo. With that done we should all work off of that dir instead of "schemas", since with git we all have our own dev branch anyway and won't step on each other unless we want to.

                        • 24. Re: svn location for domain schemas and xml examples
                          brian.stansberry

                          Another note on ID and IDREF -- with the division into domain.xml and host.xml it's likely that referents will not exist in the same document as the referring element. E.g. a ref like this from server to server-group won't work:

                           

                          <xs:complexType name="serverType">
                             <xs:sequence>
                                 <xs:element name="server-group-ref" minOccurs="1" maxOccurs="unbounded" type="server-group-refType" />
                             <xs:sequence/>
                          </xs:complexType>
                          
                          <xs:complexType name="server-group-refType">
                             <xs:attribute name="ref" type="xs:IDREF"/>
                          <xs:complexType/>
                          
                          1 2 Previous Next