[jboss-jira] [JBoss JIRA] Closed: (JASSIST-34) Throw a more descriptive exception when a class file does not start with 0xCAFEBABE

[Shigeru Chiba (JIRA)]

     [ http://jira.jboss.com/jira/browse/JASSIST-34?page=all ]

Shigeru Chiba closed JASSIST-34.
--------------------------------

    Resolution: Done

I changed the message of the IOException thrown when a class file
does not start from 0xCAFEBABE.  However, reporting the name of
the class file etc. is an issue of the EJB3 deployer.  Because Javassist
just receives an InputStream for reading the contents of the class file,
there is no way for Javassist to know the name of the class file.

> Throw a more descriptive exception when a class file does not start with 0xCAFEBABE
> -----------------------------------------------------------------------------------
>
>                 Key: JASSIST-34
>                 URL: http://jira.jboss.com/jira/browse/JASSIST-34
>             Project: Javassist
>          Issue Type: Bug
>         Environment: Jboss 4.0.5 GA with EJB3 deployer and IBM DB2 JDBC driver v3.3.54
>            Reporter: Josh Devins
>         Assigned To: Shigeru Chiba
>         Attachments: server.snipped.log
>
>
> I have deployed an application that is using the IBM DB2 JDBC driver jar version 3.3.54. With the EJB3 deployer installed (since we have EJB3s), some class file in the DB2 jar apparently does not start with 0XCAFEBABE, or "the magic hex code". The EJB3 deployer is using Javassist to examine all of the class files in the jar, but when it hits one of these wonky IBM class files, Javaasisst is throwing an IOException with message "non class file". This is rather useless as the EJB3 deployer then rethrows this IOException as a RuntimeException. I get no info about what class failed, what jar file it was in, etc. Perhaps this is an EJB3 deployer issue, but I believe that Javassist should at least throw a more descriptive exception, and not even an IOException. Or better yet, the EJB3 deployer should not just die and rethrow the RuntimeException, just skip the file!
> Stepping through the JBoss and Javassist code with my debugger was the only way to figure this out. You can look at the attached stack trace from the server log for the exact files and line numbers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira