org.apach.fop.Version line 33 (ver 328820) assumes that Version.class.getPackage() will return the package info of the class however it may return null if it was loaded from an incomplete class loader that doesn't implement definePackage correctly by loading the manifest info from the jar file. Whilst the proper solution is to fix these class loaders it would be prudent to gracefully handle this situation. The attached patch attempts to do so. ==START PATCH== Index: src/java/org/apache/fop/Version.java =================================================================== --- src/java/org/apache/fop/Version.java (revision 331635) +++ src/java/org/apache/fop/Version.java (working copy) @@ -30,7 +30,11 @@ * @return the version string */ public static String getVersion() { - String version = Version.class.getPackage().getImplementationVersion (); + String version = null; + Package jarinfo = Version.class.getPackage(); + if(jarinfo != null) { + version = jarinfo.getImplementationVersion(); + } if (version == null) { //Fallback if FOP is used in a development environment String headURL ==END PATCH==
Patch applied: http://svn.apache.org/viewcvs?rev=331991&view=rev Thanks for catching that. One request, though: Please attach patches as a file to Bugzilla issues. Bugzilla tends to add additional line breaks to the patch if included in comments. It was no problem in this case (just one additional line break), but with bigger patches this will become a problem.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed