I claim f8916a839c5a7bfe6d0de100a33cf23de33de6e4 in the remoting fixes that. Any chance you can try a new remoting jar to see if you can connect via JNLP without overriding the encoding?
There's a corresponding change in the server for a proper fix, but you wouldn't need that since your master runs in an ASCII-compatible encoding. 2013/6/12 Kohsuke Kawaguchi <[email protected]> > XML without prolog is parsed as UTF-8, so I think that part is OK. > > I'm spotting a few places in JNLP handshaking that relies on > ASCII-compatible encoding, so I wonder if that's causing it. In any case, I > think we need more detailed error messages. > > Another thing I spotted is the BASIC auth header. How is the username and > password supposed to be encoded? > > > 2013/6/12 James Nord (jnord) <[email protected]> > > Looks like jenkins serves up its JNLP pages without an XML prolog (the >> <?xml version="1.0" encoding="UTF-8"?> bit)…**** >> >> ** ** >> >> If you save the file and add an XML prolog for UTF-8 and run from that >> without setting the encoding – does that work?**** >> >> ** ** >> >> /James**** >> >> ** ** >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Dirk Haun >> *Sent:* 12 June 2013 15:03 >> *To:* jenkinsci-users >> *Subject:* Re: Jenkins vs. EBCDIC**** >> >> ** ** >> >> Ah, the default encoding. It seems we *have* to set it to something other >> than EBCDIC so we can even get a connection to our master.**** >> >> The slave is connected via Java Web Start and started like so: >> >> java -Dfile.encoding=ISO8859_1 -jar slave.jar -text -jnlpUrl >> http://<ip-of-master>/computer/sva-zpdt-emul/slave-agent.jnlp -auth >> <username>:<password>**** >> >> Without the -Dfile.encoding (or setting it to EBCDIC), the slave can not >> get a connection to the master.**** >> >> ** ** >> >> Connecting via ssh is not an option, as it's not available on the >> emulator.**** >> >> Any suggestions?**** >> >> ** ** >> >> On Wed, Jun 12, 2013 at 11:14 AM, Kohsuke Kawaguchi <[email protected]> >> wrote:**** >> >> This should work out of the box, because we take the encoding of the >> slave into account for obvious reasons.**** >> >> ** ** >> >> the "Execute Shell" feature uses the CommandInterpreter class, which uses >> the FilePath.createTextTempFile method to create a shell script. This file >> takes contents as String, then uses the encoding of the slave when it does >> "new FileWriter(f)". So it should write the shell script in EBCDIC.**** >> >> ** ** >> >> Does your slave JVM have a proper default encoding configured?**** >> >> ** ** >> >> ** ** >> >> 2013/6/12 Dirk Haun <[email protected]>**** >> >> We're trying to use Jenkins to build our software on OS/390 (using the >> Hercules emulator, not real hardware, but still). This OS uses EBCDIC as >> its native character set, not ASCII. We've successfully managed to check >> out from our SVN repository (yay!), but now we would need to run commands >> to build the software. And this is where we run into problems ...**** >> >> The problem is that commands that we type into the text field of the >> "Execute shell" build step need to be translated from ASCII to EBCDIC when >> run on the OS/390 side. We confirmed that this is the problem by manually >> translating a simple command to EBCDIC and typing those characters into the >> text input field - the command was then executed.**** >> >> However, a lot of EBCDIC characters have non-printable ASCII equivalents, >> so this is not an option in practice (besides it being a pain in the back >> to maintain).**** >> >> Is there any any plugin that can handle this situation?**** >> >> Alternatively, is there a plugin that would simply let us run a script >> that's already on the OS/390 side? Please note that again, there's the >> problem of character set translation - this time with the file name; but >> since the SVN plugin does work as expected, maybe some part of Jenkins is >> already doing the right thing.**** >> >> We're stuck at this point, so any help is appreciated. Thank you.**** >> >> bye, Dirk**** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> **** >> >> >> >> **** >> >> ** ** >> >> -- >> Kohsuke Kawaguchi **** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> **** >> >> ** ** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> **** >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Kohsuke Kawaguchi > -- Kohsuke Kawaguchi -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
