.jar.index files generated after start EAP instance (6.0.x) are stored to filesystem. After an update of a such EAP instance to EAP-6.1.0-ER4, these files are left on disk. These files after update are obsoleted and with high probability out of sync with current state of JAR content. Any tool which is relying and using these files can use out-dated info afterwards. This issue is related to new feature BZ#920349. I think it could be enough how to fix this issue to place a Release Note item about necessary manual .jar.index deletion like: for i in `find /usr/share/jbossas -name .jar.index`; do echo Deleting $i...;rm -f $i; done
I've realized right now, EAP-6.1.0 has different module directory layout comparared to EAP-6.0.x (due to Layered product feature impl.), so in addition these files become orphans. And based on https://issues.jboss.org/browse/MODULES-152?focusedCommentId=12760822&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12760822, these files have to be removed manually only, otherwise they are read during booting-up, even they are totally out-dated.
Based on my comment #1, I'm not sure if current behavior (reading totally obsoleted orphans .jar.index) doesn't involve more complex issue, so this is the reason why I'm going ti upgrade the severity of this BZ and propose it as possible blocker. If this issue isn't so hard as it looks now for me right now, feel free to lower it and you can follow by my suggestion from problem description (resolve it as RN notice only).
Impact of this issue (if I correctly understand meaning of creation/reading .jar.index files) can be in a such behavior - if EAP-6.1.0 brings new feature in separate package name, but in the same JAR file (it produces new line for .jar.index), this new feature is totally hidden for class-loaders, because .jar.index announces old state (without this new package). And due to not yet implemented https://issues.jboss.org/browse/MODULES-152, this out-dated index isn't recreated after upgrade to EAP-6.1.0.
Hi, the orphaned jar indexes will never be ready. For a module to be read it needs to be referenced by something ad have a modules.xml which will then point to a jar file. If the jar file is found then the modules system will use VFS to open it and that will get the index variation to e opened as well. In any case, we can remove the orphaned files. This was already being done (see JBPAPP6-1793) and it was inadvertently broken by the directory layout change of modules. I have already applied the fix (clean modules, not the modules/system/layers/base but I have lowered the severity as this is just about some unused but innocuous files left after an update.
Verified during EAP-6.1.0-ER5 test cycle, fixed for RHEL6, result for RHEL5 is in progress.
Verified on RHEL5 during ER5 test cycle. Fixed there as well.