JBossDeveloper

Brian Stansberry wrote:

 

Aren't the children of <containers/> xs:any ##other? Do we want such a thing at the root level?

That contradicts the original idea of the domain schema - to lock the configuration options. If we still want to follow the original idea, we might have xsd:any in some places where the possible content of that xsd:any will be relatively limited in principle, leaving he domain schema as a whole mostly specific wrt to the config options.

David Lloyd wrote:

 

Brian Stansberry wrote:

 

Just to clarify a bit -- we don't want to go too far. Core infrastructure stuff (e.g. threads, logging) should remain in the core namespace.

 

Do we even want to have a containers element at all?  Maybe that should just be directly at the domain level...

From pure structural representation/expression of information and readability point of view, I'd say it depends on what kind of information and how it might intersect and cause confusion will be inside the containers.

If each container is unique from the config point of view and its elements intuitively relate only to this specific container then we might consider moving to a higher level getting rid of the container element.

Another reason to have the container element is if we want to be able to configure more than one container of the same type. (This has been mentioned before on the forums).

I agree it xsd:any as a child of the root element contradicts the original idea, and I'm not comfortable with it for that reason. So I preferred the idea of an xsd:any to be a child of some other element that provides context.

When we process the xml and encounter an unknown element, we talked about calling out to a handler that a subsystem had registered for that element. What happens then? Presumably that handler generates an object that can be plugged into the overall model. Who plugs it in? The handler, anywhere it wants? Or is there a requirement that the object implements/extends some base type, with the base type depending on context?

The latter seems more understandable. However, if in practice the base type that has to be extended ends up being java.lang.Object, what the point? The current domain object model work has an AbstractContainerElement class though, so we are moving toward real base types.

For sure we'll want to be able to configure more than one container of the same type.

The problem with getting rid of "containers" is it's children are probably going to be xsd:any ##any or ##other, as things like the ejb and web containers are the subsystems where projects may want to evolve more rapidly than the community AS.

Is there a better term than "containers"?  Part of the problem I think is just the term, which at a minimum needs to be clearly defined. "Container" is used a lot in JEE, so if our definition strays far from the JEE one we're probably going wrong.

When I look at what we're doing in web-container and remoting-container and what I expect we'll be doing in ejb-container, we're really configuring subsystems.  Remoting isn't a JEE container at all, and with web and ejb you only get a container when you deploy your application; what's contained is the servlets/ejbs and the containers are specific to this servlets/ejbs, with the EE deployment descriptors and annotations playing a major role in defining the container.

This branch of the discussion continues at http://community.jboss.org/thread/154039?tstart=0, specifically the 8th post.