DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22967>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22967 <jar> permits duplicated manifest attributes in violation of the manifest specification ------- Additional Comments From [EMAIL PROTECTED] 2003-09-08 15:48 ------- Thanks, failed to find bug #4683 when searching before. Seems like Java #4842483 is the main justification for leaving the hack in: http://developer.java.sun.com/developer/bugParade/bugs/4842483.html However note that the default Manifest parsing code will anyway ignore all but the last Class-Path attribute. Only an app server (e.g.) which specially recognizes this problem, and parses an (illegal) manifest itself, could merge multiple Class-Path headers. Seems that the extension spec still contradicts the lower-level manifest spec (and reality) in JDK 1.4.2. A complicated compromise would be: 1. Forbid (w/ BuildException) any duplicated attributes *except* Class-Path in the main attrs section, which would be automatically merged (concatenated with space separators). In the case of the Class-Path exception, log a warning that the multiple Class-Path scenario while recommended by some documents in fact contradicts the manifest spec (and doesn't work in the Sun JRE either). 2. Print a warning whenever any attr value (incl. a merged or unmerged Class-Path) exceeds 512 bytes: continue, and generate a valid manifest based on it, but warn the user that the Sun JRE might not accept it. Yucky. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
