JBossDeveloper

Brian Stansberry wrote:

 

By replacing the "extends" attribute on profile with <include profile="x"/> and by moving the subsystem configuration out of the profile element, we are really moving away from any sort of notion of "this profile extends the standard pre-defined 'web' profile that ships with AS 7, except with the following overrides and additions."

I actually don't like this notion (at least the way I understand it). Which is probably why I thought of a different way to configure this thing. Where is this pre-defined "web" profile defined? What's its content, what can be overriden (all or parts) and how? The user will have to learn that to understand the configuration. If you don't explicitly mention this pre-defined web profile then maybe it's less confusing? To me at least it is.

Brian Stansberry wrote:

 

Alexey Loubyansky wrote:

 

Actually, I would get rid of 'type' attribute in subsystem as well. E.g.

 

<web:subsystem name="myweb1">
  <web:container ... />
</web:subsystem> 

 

So <web:subsystem/> extends some base type in urn:jboss:domain:1.0 ?

Yes, it could.

Agreed, that's why I said that notion was not clearly though through.   But any thoughts on how to make it easy for people to set up a "web" profile configuration?

Should it? I don't like that kind of thing because it ties the subsystem schema to the urn:jboss:domain schema; see Jesper's post.

But if it doesn't, then we could end up with a confusing mix:

<web:sub name="xxx"></web:sub>

<ejb:subsystem id="yyy"</ejb:subsystem>

<ws:sistema name="zzz"></ws:sistema>

A type attribute on a urn:jboss:domain element avoids that.

Brian Stansberry wrote:

 

Should it? I don't like that kind of thing because it ties the subsystem schema to the urn:jboss:domain schema; see Jesper's post.

 

But if it doesn't, then we could end up with a confusing mix:

 

<web:sub name="xxx"></web:sub>

<ejb:subsystem id="yyy"</ejb:subsystem>

<ws:sistema name="zzz"></ws:sistema>

 

A type attribute on a urn:jboss:domain element avoids that.

It depends. First of all even if there is no requirement for specific subsystems to extend a common base type defined in the domain schema, the element names can be anything. I.e. a type name or its structre doesn't pose any restriction on the element name, which will come from the specific subsystem's namespace anyway.

But the domain schema may explicitly say that it expects this element from this namespace.

As to the common schema and its re-use across subsystems, it might be useful and might optional, in principle.

David Lloyd wrote:

  <profile name="blah">
      <web:subsystem>
          <web:container ... />
      </web:subsystem>
  </profile>

 

This would have to be done either with <xs:any> or substitution groups.  I'd be interested in seeing how well IDEs deal with either of those in terms of automatic completion and so on.

My eclipse xml editor did not offer a substitution group member as a choice instead of the group head. This was true whether or not the group member was defined in the same namespace as the group head (urn:jboss:domain:1.0) or in the web namespace I was using.

Further, if the separately namespaced web schema declares group member "web-container" that extends a type in urn:jboss:domain:1.0, if I create a urn:jboss:domain:2.0 schema and try to use web:web-container in a document based on that schema it fails:

45:45 cvc-complex-type.2.4.a: Invalid content was found starting with element 'web:web-container'. One of '{"urn:jboss:domain:2.0":subsystem}' is expected

So, not seeing much benefit to substitution groups.

David Lloyd wrote:

 

What if the domain:2.0 element was a substitution for the domain:1.0 element?  Just curious.  I think xs:any is probably good enough personally

Remind me to experiment again and test. Agreed that xs:any is probably ok; examining this was kind of a self-tutorial.

One thing about substitution groups, perhaps closer to what Jason was thinking. (???)

I can see ALR wanting a typed API something like this:

Server server = getConfigObjRepresentingServer();

EjbSubsystem ejbsub = server.getEjbSubsystem();

So in urn:jboss:domain we can create a "subsystem" element of type subsystemType that takes xs:any as a child.

Then also in urn:jboss:domain there are substitution group members defined for all the known, stable subsystem types: web-container, ejb-container etc.

I've pushed to my schema-dev branch on github:

1) Got rid of containers element.

2) Definition of profileType as follows:

<xs:complexType name="profileType">
    <xs:annotation>
      <xs:documentation>Contains a list of subsystems</xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="include" type="profile-includeType" minOccurs="0" maxOccurs="unbounded"/>
      <xs:choice minOccurs="1" maxOccurs="unbounded">
          <xs:element name="subsystem" type="simple-subsystemType"/>
          <!-- FIXME move web-containers to another namespace and remove this -->
          <xs:element ref="web-containers"/>
          <xs:any namespace="##other">
            <xs:annotation>
                <xs:documentation>A profile declaration may include configuration
                elements from other namespaces for the subsystems that make up the profile.
                </xs:documentation>
            </xs:annotation>
          </xs:any>
      </xs:choice>
    </xs:sequence>
    <xs:attribute name="name" type="xs:string" use="required">
      <xs:annotation>
        <xs:documentation>Name of the profile</xs:documentation>
      </xs:annotation>
    </xs:attribute>
    <xs:attribute name="extends" type="xs:string" use="optional">
    </xs:attribute>
  </xs:complexType>

  <xs:complexType name="profile-includeType">
    <xs:annotation>
      <xs:documentation>Specifies that a contents of a named profile are to be included in
      the profile whose definition includes this type.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="profile" use="required">
      <xs:annotation>
        <xs:documentation>Name of the profile to include</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>

  <xs:complexType name="simple-subsystemType">
    <xs:annotation>
      <xs:documentation>A subsystem is a specific technology, service or a set of or a functionality
                        which can be enabled in a profile. A simple subsystem is one
                        that has no configuration except its name.</xs:documentation>
    </xs:annotation>
    <xs:attribute name="name" use="required">
      <xs:annotation>
        <xs:documentation>Name of the subsystem</xs:documentation>
      </xs:annotation>
    </xs:attribute>
  </xs:complexType>

3) Added a jboss-domain-naming.xsd. That's a rough draft schema for a naming service, but really was just a base for showing an example subsystem config coming from a foreign namespace.

<domain xmlns="urn:jboss:domain:1.0"
        xmlns:naming="urn:jboss:domain:naming:1.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:jboss:domain:1.0 jboss-domain.xsd
                            urn:jboss:domain:naming:1.0 jboss-domain-naming.xsd">

    <profile name="something">
        <subsystem name="ejb"/>
        <subsystem name="jms"/>
        <!-- FIXME move web-containers to another namespace -->
        <web-containers>
            <web-container name="jboss.web">
                <!--  FIXME the use of address/port here needs to be updated to use the central socket configuration facility -->
                <http-connector id="httpsConnector" address="10.0.0.5" port="8443" protocol="tls" scheme="https" secure="true" 
                                default-virtual-server="localhost">
                    <ssl password="changeit" cipher-suite="SSLv2+SSLv3"/>
                </http-connector>
    
                <virtual-server id="localhost" http-connectors="httpsConnector" hosts="localhost">
                    <access-log/>
                </virtual-server>
           </web-container>
       </web-containers>
       <naming:naming-service bootstrap-socket-binding="jndi" bootstrap-executor="someThreadPool" 
            remoting-connector="someConnector"/>
    </profile>

    <profile name="something2">
        <include profile="something"/>
        <subsystem name="additional"/>
    </profile>

Re: the somewhat odd simple-subsystemType:

dmlloyd: it's probably smart having a simple config-less option.
[7:10pm] bstansberry: but, it may not even apply
[7:10pm] bstansberry: sure, if there are subsystems that don't have configs, which could very well be
[7:10pm] dmlloyd: but I don't like having subsystems being identified *either* by, uh, "nametype", or the namespace of the root element that happens to define it
[7:11pm] dmlloyd: seems like it should be one or the other
[7:11pm] • dmlloyd critic, always the critic
[7:11pm] bstansberry: the latter is better, but then you are creating a namespace that has nothing but a root element
[7:12pm] dmlloyd: yeah, seems crazy
[7:12pm] bstansberry: an empty one
[7:12pm] bstansberry: but, we can see if there is an actual use case
[7:12pm] bstansberry: if not, drop the concept
[7:13pm] bstansberry: if subsystems are brought in via dependency, then the only ones in <profile> are those that aren't depended on
[7:13pm] bstansberry: and how many of those will take no config?
[7:15pm] dmlloyd: yeah I can't think of a configless subsystem offhand, unless maybe it's JNDI