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

[Oliver Mensinger (JIRA)]

    [ http://jira.jboss.com/jira/browse/JASSIST-34?page=comments#action_12394963 ] 
            
Oliver Mensinger commented on JASSIST-34:
-----------------------------------------

We addressed this issue to the IBM DB2 support which is now officially known as APAR LI72814 for DB2 9.1 and LI72819 for DB2 9.5. The fix is supposed to be included in fixpak 5, respectively fixpak 1 for DB2 9.5. 
Until then you may want to request the special build (JDBC driver) 3.6.67 from the IBM DB2 support.

> 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