David Lloyd wrote:

 

Comment 1: As I stated in another thread, I think we should eliminate any per-container-type collection elements like <web-containers>.

That's fine by me.

Question 1: We have the capability to maintain independent service namespaces for every kind of container.  So, from the perspective of the domain model, should we allow more than one container with the same name, as long as the type differs?

 

The use case would be something like this:

 

 

    <containers>
        <web-container name="Public">...</web-container>
        <remoting-container name="Public">...</remoting-container>

        <web-container name="Private">...</web-container>
        <remoting-container name="Private">...</remoting-container>
    </containers>

 

The thinking is that the public and private variations would have different connector configurations.

 

Question 4: How do we assign containers to server groups?  I guess this is one case that having a single namespace for all containers could be helpful, to allow a simple <container name="Foo"/> element.

Do you need a single namespace for that? Or just uniqueness in the names?

Question 2: Should we bother trying to figure out a way to avoid duplication of connector declarations within a container when there are multiple container declarations of a type, but they're mostly the same (e.g. container B is just like container A except it adds one extra connector)?

I'd say no, just on the KISS principal and the "we have lots of other stuff to do" excuse.

The best counter-argument to my "no" is if we decide to make "connectors" a domain level element and all connectorish things are declared there. See my recent comment on "Remoting in domain.xml" thread. We'd need to get buyin on that from web and HQ teams, as it affects their container schema.

Question 3: Should we make any effort to preserve the declaration order of containers (or any other named sub-element)?  For comparison purposes I'm presently storing these things in TreeMaps which are sorted by type then name, but we could also maintained a linked hash set of the names to preserve the insertion order easily enough.  If we don't then every time the domain.xml is written out the elements will be re-sorted.  Pros: keep the user layout; Cons: more memory consumption.

That Pro certainly seems to outweigh what seems to be a really trivial Con.

Question 5: What's the best way to express that a given container is the default configuration for that container type?

In our chat last week I came to the opinion that defaults just aren't worth it, since we'd have to analyze the subsystem in a server-group's profile just to see if a default was needed.

Or are you talking about a case where, e..g multiple web containers were declared in a server-group and we need to decide which is the default against which webapps are deployed?

David Lloyd wrote:

 

To rephrase: Should container names be globally unique, or only unique to a container type?

If they are unique to container type, inside the server group it gets ugly:

<remoting-container-ref xmlns="urn:jboss:remoting:3.1" name="Foo">
<web-container-ref xmlns="urn:jboss:web:3.1" name="Foo"/>

If the children of <containers/> could be restricted to types that extend a base type declared in urn:jboss:domain:1.0, then you could do something like:

<container type="remoting" name="Foo">
<container type="web" name="Foo"/>

But a) that snippet above feels kludgy b) it seems fragile, e.g. what happens when urn:jboss:domain:2.0 comes out c) I don't know how to declare that containers takes an unbounded sequence of xs:any ##other but restricted to elements of a urn:jboss:domain:1.0 type.

So, I'm leaning toward globally unique but am hoping someone has a better idea.

I'm enjoying what the forum software did to my last post; quite artistic!

TBH, in a server-group

<container name="remoting-public">
<container name="web-public"/>

feels clunky too; much more so than

<web-container name="public">
<remoting-container name="public"/>

Perhaps we should have a list of known container types, plus some sort of extension-container. They all inherit from a base type that has a name. Their children is a single xs:any, so different subsystems can drop in their config elements as a child. Then the reference elements in server-group look like my last snippet above.

Re: a connectors elements and then containers having a ref to a connector; I agree it just doesn't seem worth it.

Even worse, the connector would have a ref to a socket-binding (brian checks if that's what we agreed on...) which has a ref to an interface. Indirection city!

Re: ordering, LOL, you should be more upfront in your Pro and Con list. "Con: more work" would have gotten a much better response than "Con: added memory".

The way I see it, how the first line of a container config looks like (whether it's a unique name e.g. 'web-container' or general 'container' or what the name constraints are) is something that should come from the structure and requirements for the content of the container configurations.

Maybe I am wrong but I don't see the first line as important. It just has to be simple. Whatever way we choose for the container configuration (type-specific or general), there will be a simple way for the first line.

See the "Remoting in domain.xml" thread at http://community.jboss.org/thread/153974?start=15&tstart=0 for some thoughts that bear on this discussion. Derived from that, David and I were chatting in #jboss-as7 today:

dmlloyd: bstansberry: maybe the containers configuration should go right under the subsystem declaration in the profile.
[11:55am] dmlloyd: at least, they seem related.
[11:55am] bstansberry: under == child?
[11:55am] dmlloyd: yeah
[11:56am] bstansberry: i like that too, except the same subsystem can appear in multiple profiles
[11:56am] dmlloyd: the pro (and con) is that you can use different configs for different profiles
[11:56am] bstansberry: but not the same config for different profiles
[11:56am] dmlloyd: unless we do some kind of profile inheritance scheme or something
[11:56am] bstansberry: it is nice though that the whole mapping to server group issue disappears
[12:03pm] dmlloyd: yeah, I didn't even think of that

I then posted this (bogus) content to pastebin:

    <extension prefix="xx" module="org.foo:blah"/>

    <subsystem name="webserver" extends="web">
       <web:container name="jboss.web">
            .....
            </virtual-server>
       </web:container>
    </subsystem>
    <profile name="something">
        <subsystem name="ejb"/>
        <subsystem name="webserver"/>
        <subsystem name="jms"/>
        <subsystem name="xx:fancy"/>
    </profile>

[12:04pm] dmlloyd: didn't we have, at one point, an extends="" for profiles?

[12:05pm] bstansberry: yes, and we stiil do
[12:05pm] bstansberry: lots of stuff got dropped from slides today
[12:05pm] bstansberry: space
[12:05pm] dmlloyd: right
[12:05pm] bstansberry: anyway, that pastebin isn't right; just starting to noodle
[12:06pm] dmlloyd: yeah I see that you have subsystem outside of profile, and extends on subsystem
[12:06pm] bstansberry: that's the vague part
[12:06pm] bstansberry: extends on profile just lets you add another subsystem without having to redeclare
[12:06pm] dmlloyd: right
[12:07pm] bstansberry: extends on subsystem is.... vague
[12:07pm] dmlloyd: so I'm thinking you put the container config inside <subsystem> inside <profile>
[12:07pm] dmlloyd: then use profile extension to avoid redeclaring all the stuff
[12:07pm] dmlloyd: or to explicitly redeclare all the stuff, if that's what you want
[12:07pm] dmlloyd: then a server group gets a profile, and that's it
[12:08pm] dmlloyd: all container configs come with it
[12:08pm] bstansberry: yeah, you could do that; if you wanted to reuse something a lot you create a fake profile with one subsystem
[12:08pm] bstansberry: extends="web ejb jms" ?
[12:08pm] bstansberry: valid?
[12:08pm] bstansberry: multiple inheritance
[12:09pm] • bstansberry feels a bit like he's solving a problem that doesn't exist
[12:10pm] dmlloyd: no reason not to support MI, later overrides earlier
[12:10pm] dmlloyd: that makes it easy to say "this profile is that one plus that one"
[12:10pm] dmlloyd: I can see people wanting to express that
[12:10pm] bstansberry: yeah
[12:11pm] bstansberry: now, reason for extends on subsystem was...
[12:11pm] dmlloyd: vague?
[12:11pm] bstansberry: there's some sort of mapping from a subsystem name to a module
[12:11pm] dmlloyd: right, <extension>
[12:11pm] dmlloyd: somehow
[12:12pm] bstansberry: well, that's for extension modules
[12:12pm] bstansberry: i'm thinking about our standard ones
[12:12pm] dmlloyd: our standard ones should be available without mapping them to modules in the domain.xml
[12:12pm] bstansberry: <subsystem name="random_name_for_this_webserver_config" extends="war">
[12:13pm] bstansberry: is a way to bring in that mapping since random_name_for_this_webserver_config isn't going to be unknown
[12:13pm] dmlloyd: I'm thinking that the named configs would be profiles.  "subsystem" means "bring in this subsystem to this profile, configured thusly"
[12:15pm] bstansberry: emuckenhuber: yes
[12:15pm] bstansberry: dmlloyd: good point; the name is pointless
[12:15pm] bstansberry: it's really more of a type
[12:16pm] bstansberry: <subsystem type="web"> <subsystem type="xx:fancy">

So, from this discussion we end up with something like:

    <!-- The ee6-web1 profile extends the stock 'web' profile that ships with as 7 -->
    <profile name="ee6-web1" extends="web">
        <subsystem type="web">
           <web:container name="jboss.web">
                ....
           </web:container>
        </subsystem>
        <subsystem type="ejb">
           <ejb:container .... />
        </subsystem>
    </profile>

    <profile name="messaging">
       <subsystem type="messaging">
           <messaging:kerfluffle .../>
       </subsystem>
    </profile>

    <profile name="custom" extends="ee6-web1 messaging"/>
    
    .....
    
    <server-groups>
        <server-group group-name="main-server-group" profile="custom">
          <!-- No need to map subsystem configs onto the server group; 
               they come via the profile attribute -->
        </server-group>
    </server-groups>

There is still a not-quite-right feel about the extends="web" on the ee6-web1 profile. The idea there is we have a stock "web" profile that lists all the subsystems for an EE 6 web profile. But it would not include the configuration elements; the user would have to supply the configurations as is done in ee6-web1 above. So what the "extends" attribute does is save the user having to list other subsystems that don't require any configuration. Some of those could come in without being listed because it's known, for example, that "ejb" depends on "jndi". But what if a web profile includes a subsystem that takes no config *and* isn't depended on by any other subsystem.

Perhaps a stock "web" profile doesn't belong in the domain model itself. Maybe it's something that belongs in a management tool, CLI etc. That is, user executes a command asking for a domain.xml to be created based on a "web" profile; tool generates one with a set of default subsystem configs. The magic defaults aren't in the domain model, they are in the tool, and what is generated can change from release to release.

More nuggets:

dmlloyd: bstansberry: Nihility mentioned the possibility of using substitution groups for added type safety.
[12:32pm] dmlloyd: we could have a substitution group for a complex type "container", which is contained within <subsystem> and then only substitution candidates for that element would be used
[12:33pm] dmlloyd: not sure if that's a good strategy or not because I've never experimented with that personally.

and, unrelated to the above:

Nihility: bstansberry, dmlloyd instead of extends you could do an include
[2:35pm] Nihility: <profile name="ee">
[2:36pm] Nihility:     <include-profile name="web"/>
[2:37pm] Nihility:       <include-profile name="ejb"/>
[2:37pm] Nihility: </profile>
[2:37pm] bstansberry: yes that's cleaner
[2:37pm] bstansberry: i don't like attributes that take a list

'extends' looks confusing. And to be able to re-use subsystem configuration in different profiles and also being able to have multiple subsystem configurations of the same type, why not move subsystem out of of the profile? E.g.

{code:xml}<subsystem name="myweb1" type="web">
  <web:container ... />
</subsystem>
 
<subsystem name="myweb2" type="web">
  <web:container ... />
</subsystem>
 
<subsystem name="ejb" type="ejb">
  <ejb:container ... />
</subsystem>
 
<subsystem name="messaging" type="messaging">
  <messaging:kerfluffle .../>
</subsystem>
 
<profile name="ee6-web1">
   <include subsystem="myweb1"/>
   <include subsystem="ejb"/>
</profile>
 
<profile name="messaging">
   <include subsystem="messaging"/>
</profile>
 
<profile name="custom">
   <include profile="ee6-web1"/>
   <include profile="messaging"/>
   <include subsystem="other"/>
</profile>{code}

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

{code:xml}<web:subsystem name="myweb1">
  <web:container ... />
</web:subsystem>
 
<web:subsystem name="myweb2">
  <web:container ... />
</web:subsystem>
 
<ejb:subsystem name="ejb">
  <ejb:container ... />
</ejb:subsystem>
 
<messaging:subsystem name="messaging">
  <messaging:kerfluffle .../>
</messaging:subsystem>
 
<profile name="ee6-web1">
   <include subsystem="myweb1"/>
   <include subsystem="ejb"/>
</profile>
 
<profile name="messaging">
   <include subsystem="messaging"/>
</profile>
 
<profile name="custom">
   <include profile="ee6-web1"/>
   <include profile="messaging"/>
   <include subsystem="other"/>
</profile>{code}

Message was edited by: Alexey Loubyansky

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

Which is fine, I don't think that notion was well thought through anyway. But, I want to make sure we have a strategy for helping people use and extend some pre-defined profile configurations, without having to manually write the xml or cut-and-paste. What do people think about having tools/utilities that can generate a standard web profile configuration? Any other solutions?

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 ?

Lets be careful that we don't end up in a situation where each project has to suck in a massive "common" dependency which serves no purpose.

We need to make sure that each project can evolve its container definitions without having to change its dependencies on the domain definition -- or even worse change domain itself in order to activate things.

In short the domain SPI for integrating container configurations must be minimal and stable - and hopefully we will only see a 1.0.0.Final release for the next may years.