1 2 Previous Next 24 Replies Latest reply on Jul 7, 2010 12:48 PM by Brian Stansberry

    svn location for domain schemas and xml examples

    Alexey Loubyansky Master

      I've committed them currently here https://svn.jboss.org/repos/jbossas/projects/profileservice/trunk/domain/src/test/resources/schemas

      Since this is where the first steps were taken. If there is (or should be) a better project/location, we can move them there. Also it will perhaps make sense to have a Jira project for this.

       

      I've committed the originals written by Scott plus an example XML that I wrote following the schemas. I didn't specify namespaces yet because they looked a bit messy to me. I'll review and probably do some clean-up. There are also a few (really) minor deviations in the XML.

       

      I am going to start changing the schemas and the xml according to what we discuss/agree upon here.

        • 1. Re: svn location for domain schemas and xml examples
          David Lloyd Master

          I had a long and involved, uh, "discussion" on IRC with Jason about this topic.  We were figuring out why and how we would use namespaces for these core things.  The conclusion we came to basically amounts to this feedback to your initial proposal:

          1. Most things should just live under the main "domain" namespace.  I.e. eliminate the "common", "profiles", "resources", "servers", "security-config", "web" sub-namespaces and merge them back into one.  The rule here is that everything which is versioned with or tied to the AS release cycle will live under one namespace.
          2. The stuff I did for threads and remoting does not fit in well with the domain model as is, so let's completely remove that stuff for now and we'll revisit it once things are off the ground.
          3. The "host" stuff I did should be merged in here because a lot of those data types are common between domains and hosts; instead we'll just have a "host" and "domain" root element.
          4. We will support extensibility via <xs:any> elements under the root <domain> element.
          5. We need a domain-level "deployment" element.
          6. (From earlier discussions) - "cluster" should be a logical property of a server group, not a separate entity (right Brian?).
          7. I'm not sure about "containers".  We haven't discussed it yet.  But we should...
          8. Do we want system properties to be domain-wide as well as host-wide etc?

           

          Let the flamewars begin!!

          • 2. Re: svn location for domain schemas and xml examples
            David Lloyd Master

            Also I'm not a huge fan of attributeless elements that contain text content:

             

            <jvm-options>-Xmx512m</jvm-options>
            

             

            I prefer:

             

            <jvm-option value="-Xmx512m"/>
            

             

            Or even better:

             

            <heap size="128m" max-size="512m"/>
            

            in this case.

             

            What do you guys think?

            • 3. Re: svn location for domain schemas and xml examples
              David Lloyd Master

              David Lloyd wrote:

               

              Also I'm not a huge fan of attributeless elements that contain text content:

               

               

              There's an exception to this personal rule of mine though - large amounts of content should be within an element.  Here's an example from another project:

               

                  <diffie-hellman-parameter-spec name="OakleyGroup14">
                      <generator value="2"/>
                      <prime radix="16">
                          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
                          29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
                          EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
                          E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
                          EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
                          C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
                          83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
                          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
                          E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
                          DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
                          15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
                      </prime>
                  </diffie-hellman-parameter-spec>
              
              
              • 4. Re: svn location for domain schemas and xml examples
                David Lloyd Master

                It's interesting that you're employing ID and IDREF.  It raises some questions:

                1. Is there some correlation between an element ID and its name representation in the container (i.e. the service name)?
                2. If so, how does that mapping work, and why?
                3. if not, then how are IDs chosen?  I understand that certain other app servers use generated IDs but they generate incomprehensible character sequences which causes problems and annoyances for administrators.
                4. For elements that we have defined as being named, can we use ID instead?  Why or why not?
                • 5. Re: svn location for domain schemas and xml examples
                  John Bailey Novice

                  I think we should try to use the third style as much as possible.  Less possibility to mess it up and the schema does a lot better job guiding users/admins to what is expected.

                   

                  Although for this specific example there will also need to be a generic version like option #2 order to support less common properties.

                  • 6. Re: svn location for domain schemas and xml examples
                    Jason Greene Master
                    (From earlier discussions) - "cluster" should be a logical property of a server group, not a separate entity (right Brian?).

                     

                    I originally proposed that there only be groups, and that a "cluster" was just a server with clustering services on it. However it was pointed out that there is common configuration to a cluster, and that that common configuration should be a separate schema element, so that there is type checking on that.

                    • 7. Re: svn location for domain schemas and xml examples
                      Jason Greene Master

                      I prefer:

                       

                      <jvm-option value="-Xmx512m"/>

                       

                      The problem with this approach vs the other two is that the user has to backslash quotes. I like the third option the best, but the only issue with it is that it requires knowing how to pass these values on every JVM we support.

                      • 8. Re: svn location for domain schemas and xml examples
                        David Lloyd Master

                        Jason Greene wrote:

                         

                        I prefer:

                         

                        <jvm-option value="-Xmx512m"/>

                         

                        The problem with this approach vs the other two is that the user has to backslash quotes. I like the third option the best, but the only issue with it is that it requires knowing how to pass these values on every JVM we support.

                        Yeah I did take this as a given: in my example schema I have "JVM type" parameter.  I think it would be nicest for users - they can switch JVMs easily, in the event they wanted to do so - but it's also a little more work for us.

                        • 9. Re: svn location for domain schemas and xml examples
                          David Lloyd Master

                          Jason Greene wrote:

                           

                          (From earlier discussions) - "cluster" should be a logical property of a server group, not a separate entity (right Brian?).

                           

                          I originally proposed that there only be groups, and that a "cluster" was just a server with clustering services on it. However it was pointed out that there is common configuration to a cluster, and that that common configuration should be a separate schema element, so that there is type checking on that.

                          OK makes sense - however I think in this case the cluster element should be a child of server-group.

                          • 10. Re: svn location for domain schemas and xml examples
                            Alexey Loubyansky Master

                            Ok, I've committed the following changes:

                            - namespace urn:jboss:domain:1.0
                            - threads and remoting removed
                            - changed jvm-option element to <jvm-option value="-Xmx512m"/>
                            - added <heap size="128m" max-size="512m"/>
                            - added domain-level subsystems and server-group subsystems that should be disabled

                            - added domain-level deployments and server-group deployments that should be disabled

                             

                             

                            {code:xml}<domain xmlns="urn:jboss:domain:1.0"
                              targetNamespace="urn:jboss:domain:1.0"
                              xmlns:sec="urn:jboss:security-config:5.0"
                            >

                              <subsystems>

                                <subsystem name="ejb"/>

                                <subsystem name="war"/>

                                <subsystem name="jms" allowed="false"/>

                              </subsystems>

                             

                              <deployments>

                                <deployment name="my-app.ear" sha1="xxx"/>

                                <deployment name="my-ejb.jar" sha1="xxx"/>

                                <deployment name="my-war.ear" sha1="xxx" allowed="false"/>

                              </deployments>

                             

                              <server-groups>

                                <server-group group-name="group1">

                                   <java-config java-home=${java.home}

                                                debug-enabled="true" debug-options="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n"

                                                javac-options="-g" env-classpath-ignored="true">

                                     <heap size="512m" max-size="1024m"/>

                                     <jvm-option value="-server"/>

                                     <jvm-option value="-XX:-DisableExplicitGC"/>

                                   </java-config>

                             

                                   <subsystems>

                                     <disable name="http"/>

                                     <disable name="ejb"/>

                                   </subsystems>

                                   <deployments>

                                     <disable name="my-ejb.jar"/>

                                   </deployments>{code}

                            • 11. Re: svn location for domain schemas and xml examples
                              David Lloyd Master

                              Alexey Loubyansky wrote:

                               

                              - added domain-level deployments and server-group deployments that should be disabled

                               

                               

                              Not 100% sure about applying this to deployments too.

                               

                              Originally Jason wanted to list every deployment in every server group separately (i.e. every server group has a private list of deployments).  I didn't like this because it might make it awkward to do domain-level processing on the deployment (validation and addition to the domain model) before passing it up to the server group(s).

                               

                              I originally wanted all deployments listed on the domain level, but each containing a list of server groups it was applied to.  Jason and Brian didn't like this because given a server group element, you don't get a clear picture of what's going into it.

                               

                              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.

                               

                              I think listing all deployments at the domain level and doing exclusions at the server group level is nice from the perspective that it's less XML overall - but it does take away some of this capability.

                               

                              Thoughts?

                              • 12. Re: svn location for domain schemas and xml examples
                                David Lloyd Master

                                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.

                                • 13. Re: svn location for domain schemas and xml examples
                                  Alexey Loubyansky Master

                                  David Lloyd wrote:

                                   

                                  Originally Jason wanted to list every deployment in every server group separately (i.e. every server group has a private list of deployments).  I didn't like this because it might make it awkward to do domain-level processing on the deployment (validation and addition to the domain model) before passing it up to the server group(s).

                                  IMO, that's one of the possibilities I would consider, even though currently I lean more toward domain-level deployments.

                                   

                                  David Lloyd wrote:

                                   

                                  I originally wanted all deployments listed on the domain level, but each containing a list of server groups it was applied to.  Jason and Brian didn't like this because given a server group element, you don't get a clear picture of what's going into it.

                                  I like domain-level but I also share the same opinion with Jason and Brian.

                                  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.

                                  • 14. Re: svn location for domain schemas and xml examples
                                    Alexey Loubyansky Master

                                    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].

                                    1 2 Previous Next