Yesterday I was chasing my tail after installing the latest 7.1.0.Final release of JBoss AS.

I overlayed the install with some additional batch files which aim to start a specific configuration of a standalone
server instance. There is a good chance that I stopped the process before it had fully completed, because I
observed an error and wanted to rectify it. Nevertheless, it appears that it has uncovered a problem that
could cost someone an indefinite amount of time to realise how to resolve it.

When subsequently running my batch file, and even the domain.bat, they failed with both the console and the log showing an exception
indicating that the configuration had parse errors for the jsr77, modcluster and messaging extensions.
2012-02-17 10:31:33,983 ERROR [org.jboss.as.controller](Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:161)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:187)
at org.jboss.as.server.ServerService.boot(ServerService.java:261)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155)
... 1 more
Caused by: javax.xml.stream.XMLStreamException: Failed to load module org.jboss.as.jsr77
at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154)
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:304)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:126)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:100)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:117)
... 4 more
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS014744: No META-INF/services/org.jboss.as.controller.Extension found for org.jboss.as.jsr77:main
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146)
... 10 more
Caused by: java.lang.IllegalStateException: JBAS014744: No META-INF/services/org.jboss.as.controller.Extension found for org.jboss.as.jsr77:main
at org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:191)
at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68)
at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126)
at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)

I managed by commenting out certain extensions to narrow the issue down to just 3 extensions (stated above).

Later I installed another instance of JBoss AS 7.1.0.Final and the domain.bat started fine.
I did a directory comparison between the two installs and noticed that the only difference was the index
files within the module directory structure: all were zero bytes.

When I compare the 7.1.0.Final release archive with that of 7.1.0.CR1b, I notice that the Final is now shipping with
some, but not all, module index files.

I lost the original exceptions through correcting the files. The above exception was created simply by zeroing an index file.

If a zero byte index file is present for an extension, it would help if a warning could be raised, or perhaps even the index file was rebuilt.