Comment 1: As I stated in another thread, I think we should eliminate any per-container-type collection elements like <web-containers>.
Previously we had agreed that there is pretty much no valid reason to ever run more than one container of a given type in a single server instance. However we still need the ability to express multiple containers of a given type at the domain level, so that we do not restrict users to one single container configuration per type across the whole domain.
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 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)?
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.
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.
Question 5: What's the best way to express that a given container is the default configuration for that container type?