[
https://issues.apache.org/jira/browse/OPENJPA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Sutter updated OPENJPA-385:
---------------------------------
Attachment: OPENJPA-385.patch
Updated version of the patch.
> IndexOutOfBounds exception when parsing ".class" files
> ------------------------------------------------------
>
> Key: OPENJPA-385
> URL: https://issues.apache.org/jira/browse/OPENJPA-385
> Project: OpenJPA
> Issue Type: Bug
> Components: lib
> Affects Versions: 1.0.0, 1.0.1, 1.1.0
> Reporter: Kevin Sutter
> Assignee: Kevin Sutter
> Fix For: 1.0.1, 1.1.0
>
> Attachments: OPENJPA-385.patch, OPENJPA-385.patch
>
>
> When finding and parsing files via the classpath, we're hitting a situation
> where an invalid .class file is in the classpath. Although the files in
> question have the .class suffix, they do not have valid .class format. Not
> only are we blowing up via the serp utilities, but neither jad nor javap can
> recognize the files either. Here's the call stack that is produced:
> Exception in thread "main" java.lang.ClassFormatError:
> COM/ibm/db2os390/sqlj/custom/DB2SQLJCustomizer.class
> at
> org.apache.openjpa.lib.meta.ClassAnnotationMetaDataFilter.matches(ClassAnnotationMetaDataFilter.java:89)
> at
> org.apache.openjpa.lib.meta.ZipFileMetaDataIterator.hasNext(ZipFileMetaDataIterator.java:79)
> at
> org.apache.openjpa.lib.meta.MetaDataIteratorChain.hasNext(MetaDataIteratorChain.java:76)
> at
> org.apache.openjpa.lib.meta.ClassArgParser.mapTypeNames(ClassArgParser.java:277)
> at
> org.apache.openjpa.meta.AbstractCFMetaDataFactory.scan(AbstractCFMetaDataFactory.java:713)
> at
> org.apache.openjpa.meta.AbstractCFMetaDataFactory.getPersistentTypeNames(AbstractCFMetaDataFactory.java:583)
> at
> org.apache.openjpa.meta.MetaDataRepository.getPersistentTypeNames(MetaDataRepository.java:1190)
> at
> org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes(MetaDataRepository.java:1207)
> at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:1002)
> at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:977)
> at org.apache.openjpa.jdbc.meta.MappingTool.main(MappingTool.java:918)
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> serp.bytecode.lowlevel.ConstantPoolTable.readByte(ConstantPoolTable.java:106)
> at
> serp.bytecode.lowlevel.ConstantPoolTable.readUnsignedShort(ConstantPoolTable.java:114)
> at
> serp.bytecode.lowlevel.ConstantPoolTable.readUnsignedShort(ConstantPoolTable.java:184)
> at
> org.apache.openjpa.lib.meta.ClassAnnotationMetaDataFilter.matches(ClassAnnotationMetaDataFilter.java:67)
> ... 10 more
> As you can see, the file in question is actually coming from the db2jcc.jar.
> Although I could pursue why these files do not have the correct format, I'm
> proposing that we become more lenient in our "matches" logic. Right now, we
> are throwing this IOOB exception. This seems too harsh, especially since we
> just return "false" for any other indication that the resource is not an
> "interesting" class file with appropriate annotations. In my mind, this
> invalid class file should just be treated as if it didn't have the .class
> suffix.
> So, instead of the current exception throwing processing, I would like to
> change to just log a trace message. We already log an Info message for all
> of the files that we do process. And, logging an info message for a bad
> class format might just cause confusion (much like this exception throwing).
> Thus, I would like to just log a trace message with the appropriate
> information and return "false" on this matches() invocation.
> Any problems with this approach? I've looked at the caller's of this method
> and nobody is expecting to get the ClassFormatException or IOOB exception
> (unexpected runtime exception), so just logging and eating the exception and
> returning false looks safe.
> Kevin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
