In GlassFish 4.0, the initial deployment of a simple web application (after a fresh installation, start domain and deploy) triggers the writing out of the domain.xml twice: the profile collected for GlassFish 4.0 have two invocations of DomainXmlPersistence.save (2 invocations) which took about 5.4% of overall deployment time; whereas in the profile collected for GlassFish 3.1.2, there is one invocation of DomainXmlPersistence.save which took about 3.4% of the time.
In GlassFish 4.0, the first (extra) invocation happens in web container initialization:
In appserver/web/jspcaching-connector/src/main/java/org/glassfish/jspcaching/integration/GlassFishTldProvider.java, postConstruct method
WebContainer webContainer = cfg.getExtensionByType(WebContainer.class);
Then this invokes
./nucleus/admin/config-api/src/main/java/com/sun/enterprise/config/modularity/parser/ModuleConfigurationLoader.java, createConfigBeanForType method which triggers the domain.xml writing.
While this is part of the config modularity feature (aka zero config), based on the discussion with Tom, this should not produce a write of the domain.xml (these changes from config modularity should be just put in memory until there is another transaction that actually changes them).
So we should investigate how we could elimiate this extra domain.xml writing.
The second invocation is expected which happens at the end of the deployment to add the application related entries to the domain.xml.
The other related thing I observed for server start up: in GlassFish 4.0, after I start domain with a fresh installation, the domain.xml.bak will be created. Whereas in GlassFish 3.1.2, I don't see domain.xml.bak get created after the domain is started. Tom confirmed he is seeing the same thing and we don't want to write the domain.xml when we start the server. So we should investigate how we could elimiate this domain.xml writing also.