GlassFish 3.1 - Required v3 Config Changes

Experiment

1. use a stock v3 setup
2. add a config element
3. RESULT: It does not get added to the habitat. It is getting filtered out.

After many many hours of debugging I finally tracked down this issue. The v3 domain xml parser is highly specialized. It wants to see a server element with the name of the instance (default="server"). The code assumes that there is one and only one config element. In fact if it sees ANY config element before the server element it will assume that that is the config element that the server refers to and it will immediately start a second parse. This is bad. If you simply add an unrelated config element at the top of domain.xml it will trigger the second parse unnecessarily.

I located the place where config elements get thrown away:
DomainXmlReader.filterOut() returns a "true" when the config element is anything other than the config that the one-and-only server is referencing. The "true" means – throw this element away and don't parse the sub-tree.

Next Steps

So – no big deal:

1. DomainXml needs to be changed to allow multiple different config elements.
2. DomainXml needs to get the "second-parse" logic fixed up a little.

From Jerome:

what you need to do is not fix it but enhance it so :

1. you have control which config is parsed (I think it's already in place but verify).
2. introduce a mode where we indeed load all configs (for the DAS maybe).
3. introduce a mode where we bring extra config on demand (should not be hard to tell the stax parser to re-parse a particular config and add it to the domain instance).

1 and 2 are required. 3 is nice to have
As of March 20, 2010 steps 1 and 2 are complete.

Note: The "server-name" comes from ServerEnvironmentImpl.getInstanceName()

How Config Should Work in 3.1

I had some time to investigate how the config needs to work in V3. In 3.0 the server got its configuration from 2 sources:

• server element server-server
• config element that server is referring to server-config

Clustering adds two more xml elements to the above 2 namely

• cluster element cluster-cluster
• config element that cluster is pointing to cluster-config

The order of precedence from high to low is:

1. server-server
   • server-config*
   • cluster-cluster*
   • cluster-config*

My solution:

Add ducktype code that will fill-in the server-config object with values from the other elements.

Question: What if one of the component elements changes – then the main config object needs to possibly change its state? Add Listeners???