Bug 952166

Summary:	.jar.index files generated and stored previously (EAP-6.0.x) are left on disk after update to 6.1.0
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Pavel Janousek <pjanouse>
Component:	RPMs	Assignee:	Fernando Nasser <fnasser>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	6.1.0
Target Milestone:	ER5
Target Release:	EAP 6.1.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	920349
Bug Blocks:

Description Pavel Janousek 2013-04-15 10:38:21 UTC

.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

Comment 1 Pavel Janousek 2013-04-15 11:24:48 UTC

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.

Comment 2 Pavel Janousek 2013-04-15 11:49:11 UTC

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).

Comment 3 Pavel Janousek 2013-04-15 11:56:04 UTC

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.

Comment 4 Fernando Nasser 2013-04-15 13:10:56 UTC

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.

Comment 5 Pavel Janousek 2013-04-25 08:55:52 UTC

Verified during EAP-6.1.0-ER5 test cycle, fixed for RHEL6, result for RHEL5 is in progress.

Comment 6 Pavel Janousek 2013-04-29 14:00:15 UTC

Verified on RHEL5 during ER5 test cycle. Fixed there as well.