JRIMETA.DAT Explanation

JRIMETA.DAT is an encrypted binary file maintained by the JRI tools which holds information about the all files located in the $JAVA_TOP.

The active copy of the file is located in the $JAVA_TOP/META-INF directory. There is also a copy in $JAVA_TOP/oracle/apps/media/META-INF and in $COMMON_TOP/html/META-INF.

When a patch containing a java class file is applied, adpatch looks in the JRIMETA.DAT and compares this with the version of the class file contained within the patch. If the patch file is newer then it replaces the actual class file and the JRIMETA.DAT file is updated. adpatch does not look at the actual class file within $JAVA_TOP for comparison with the corresponding file in the patch.

Sometimes the JRIMETA.DAT and the $JAVA_TOP get out of synchronization with each other. This can happen if replacement java class files are copied manually rather than correctly applied via adpatch. This might also happen if the $JAVA_TOP (or part thereof) is copied from one Applications system to another as an attempt perhaps to fix some perceived corruption somewhere in the $JAVA_TOP or other unspecified error. If the two environments do not have an identical build and patching history this is likely to cause an inconsistency between the $JAVA_TOP and JRIMETA.DAT.

Typically, concerns regarding the JRIMETA.DAT manifest themselves when it is noticed that a patch with newer java class files is applied, and the java class files in the $JAVA_TOP are not replaced by the newer files in the patch. It is likely JRIMETA.DAT has reported to adpatch that the files in the $JAVA_TOP are already at the same or a later version as those in the patch.

The following command uses the adjlist utility to report the contents of the JRIMETA.DAT file. The output is written to the adjlist.rpt file:-

$ adjava -mx512m oracle.apps.ad.jri.adjlist -archives $JAVA_TOP -reportfile adjlist.rpt -logfile adjlist.log

If you have AD I or later installed, the following command will produce a more detailed report

$ adjava -mx512m oracle.apps.ad.jri.adjlist -archives $JAVA_TOP -allinfo -reportfile adjlist.rpt -logfile adjlist.log


During patching, updates to the JRIMETA.DAT file are reported in the main adaptch log file as below. In the example shown, the RegUi.class contained in the j4676589_jtf.zip is upgraded from 115.22 to 115.27 after first checking the JRIMETA.DAT:-
------------------------------------------------------------------------------
About to Merge meta data of delta archive 11 and master archive : Thu Aug 30 2007 16:44:55

Loading metadata from archive /oracle/115102/patches/4676589/j4676589_jtf.zip

This delta archive replaces the following elements:

oracle/apps/jtf/um/ui/RegUi [115.22 -> 115.27] {oracle/apps/jtf/um/ui/RegUi.class }
------------------------------------------------------------------------------


If the JRIMETA.DAT reports that all files currently in the $JAVA_TOP are equal to or newer than files supplied in the patch, the main adpatch log will be updated as follows:-
------------------------------------------------------------------------------
About to Merge meta data of delta archive 11 and master archive : Fri Aug 24 2007 10:23:41
Loading metadata from archive /oracle/applprod/patches/ATG4_24082007/4676589/j4676589_jtf.zip
This delta archive does not add to or supersede any elements of the master archive
Done Merging meta data of delta archive 11 and master archive : Fri Aug 24 2007 10:23:43
------------------------------------------------------------------------------

If it is suspected there is a mismatch between the files in the $JAVA_TOP and the JRIMETA.DAT, the following command will report any  inconsistencies:-

$ adjava -mx512m oracle.apps.ad.jri.adjcopy -masterArchive $JAVA_TOP -sync -mode CHECK_ONLY

If this reports errors, the following command will update the JRIMETA.DAT to reflect the versions of files contained with the $JAVA_TOP

$ adjava -mx512m oracle.apps.ad.jri.adjcopy -masterArchive $JAVA_TOP -sync -mode APPLY

The above command should only be used if it is not possible to revert to a previous known, good environment. If it is suspected there is a mismatch between the JRIMETA.DAT and the $JAVA_TOP and this is discovered when patches are being tested (as part of an upgrade for example), it is preferable to return to a known, good JRIMETA.DAT and then  repeat the patches or maintenance and identify where the  inconsistency occurs. The above command only corrects the JRIMETA.DAT to reflect the current $JAVA_TOP - it is more important that the source of the problem is identified and how and why the problem initially occurred. It will usually only be possible to identify the source of the mismatch if there is a known, good situation that can be reverted to.

After the above command has been run, re-apply the patch that failed previously and check to see if the java class files are correctly copied from the patch.

It is not possible to create a new JRIMETA.DAT file from the $JAVA_TOP if the existing JRIMETA.DAT has been lost or irretrievably corrupted.