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

[Koen Aers]

Great work indeed!

I had been juggling with additional paths in modules myself for a couple of hours yesterday. Then I gave up on that, hooked up the debugger to find the compromising line of code. But sleep caught up on me before I found it…

Nice to see how a night of sleep can solve nasty problems ;-)

Cheers,
Koen

Op 13-apr.-2012, om 05:13 heeft Lincoln Baxter, III het volgende geschreven:

> Success. You nailed the problem - I implemented it like so: https://issues.jboss.org/browse/FORGE-531
> 
> I owe you a beer.
> 
> THANK YOU!
> ~Lincoln
> 
> On Thu, Apr 12, 2012 at 9:32 PM, Lincoln Baxter, III <lincolnbaxter at gmail.com> wrote:
> I've actually spent most of today working on this issue, so if this fix works, I'm probably going to die from relief.
> 
> On Thu, Apr 12, 2012 at 6:49 PM, Thomas Frühbeck <fruehbeck at aon.at> wrote:
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> 
> 
> 
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> 
> 
> 
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120413/5bfa9426/attachment.html