Re: [forge-dev] Open challenge: UTF-8 not supported by the Java Runtime? Says who?

Hey, I think I found the reason for this message and have a somewhat silly remedy. Reason: - in com.sun.org.apache.xml.**internal.serializer.Encondings a properties file is looked up by classloader to evaluate supported Charsets - the classloader selected is not the root classloader but Forge's one, who doesnt find the properties file - funny enough the comments indicate, that the authors were not to sure about the necessity of an error message in this case :-) if (is == null) { SecuritySupport ss = SecuritySupport.getInstance(); is = ss.getResourceAsStream(** ObjectFactory.findClassLoader(**), ENCODINGS_FILE); } Properties props = new Properties(); if (is != null) { props.load(is); is.close(); } else { // Seems to be no real need to force failure here, let the // system do its best... The issue is not really very critical, // and the output will be in any case _correct_ though maybe not // always human-friendly... :) // But maybe report/log the resource problem? // Any standard ways to report/log errors (in static context)? } REMEDY: - I made a module containing a jar with only this property file - and made forge-api take it as dependency: <module name="javax.api" /> + <module name="sun.encodings" export="true"/> </dependencies> Tar with module attached. And voila: no error message anymore because the classloader can access this dreaded file. I'm sure, that someone more knowledgeable is able to find a better solution, but as first fix it may help. What do you think? Regards, Thomas Am 12.04.2012 18:02, schrieb Burr Sutter: How is this coming along? > > We are now having to put "ignore all the UTF-8" messages in our videos& > written documentation. > > > > _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev