If anyone can figure this out. I'll buy you a beer. I'm stumped! What I know is that the errors are due to accessing the Configuration ~/forge/config.xml and the local project configuration /project/.forge_settings.xml Good luck! -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

From http://stackoverflow.com/questions/177242/the-encoding-utf-8-is-not-suppo...

I suspect that the class sun.nio.cs.UTF_8 is not visible due to modularization settings. On 2012-04-03, at 3:54 PM, Lincoln Baxter, III wrote: > If anyone can figure this out. I'll buy you a beer. I'm stumped! > > What I know is that the errors are due to accessing the Configuration ~/forge/config.xml and the local project configuration /project/.forge_settings.xml > > Good luck! > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

and more to hint of it being class visibility issue, similar issue on Felix: https://jira.ow2.org/browse/ORCHESTRA-67 Google search on "UTF-8 not supported by the Java Runtime" reports multiple occurrences of this and it seem to be all in context of OSGI and other "class-isolating" runtimes. So yeah - sounds like too much isolation going on. /max On Apr 3, 2012, at 11:40 PM, Marius Bogoevici wrote: > I suspect that the class sun.nio.cs.UTF_8 is not visible due to modularization settings. > > On 2012-04-03, at 3:54 PM, Lincoln Baxter, III wrote: > >> If anyone can figure this out. I'll buy you a beer. I'm stumped! >> >> What I know is that the errors are due to accessing the Configuration ~/forge/config.xml and the local project configuration /project/.forge_settings.xml >> >> Good luck! >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

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

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(a)gmail.com&gt; 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(a)aon.at&gt; 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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Beer? How about a steak! :-)