Ivan Jozsef Balazs wrote:
Mike London wrote:
You have the string stringToConvert, encode it into a sequence of bytes using the UTF-8 encoding, then create a string from this sequence assuming it is a sequence of bytes using the platform's default charset. Don't we smell some fish around here?
Wade Zhang wrote:If you mean force to two repo be the same version, you can add "-f" to push
Rob Spoor wrote:If you want to replace one character with another, why not use string.replace(delimiterChar, '|')? Or, to replace one string literal with another, use the other replace method. replaceAll is overkill if you don't have a regular expression.
Campbell Ritchie wrote:Back in 1972 a company were given a bill with the due date of 30th June so they paid the first instalment on 30th June, the second on 31st July and the third on 31st August. Or something like that; 1972 was a long time ago. The creditor took them to court for late payment and lost; the court ruled that a bill due on the last day of the month remained due on the last day of the month. The creditors should have known better.
I think that one month after 31st January 2000 was 29th February 2000. Your 2nd March date is actually 31 days later, but that is incorrect, at least I think it is. You are adding January not February. But, yes, this is a corner case and people will disagree with each other. Go and find the old Calendar and Date classes; don't use them, but they had lenient and non‑lenient modes. Details in the Calendar documentation.
Yes, it is a business decision you will have to make. And don't send me a bill due on 29th February; I shall be entitled to pay the second instalment on 31st March
Tim Moores wrote:Like this: https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html. The regular JRE updates will of course ship with the latest data out of the box.
Also see https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html for which JRE version has what timezone data. That page also points to an RSS feed if you want to stay on top of these updates.
Tim Holloway wrote:That's about it.
I recommend you get a copy of Portecle, an open-source java-based GUI tool for keystore manipulation and certificate management. It can make the processes a lot easier.
Note also that a keystore file is self-contained. That means that you can create test keystores and muck around with them outside your production environment, then copy them to production servers when you have what you want.
Ron McLeod wrote:You will need both the private key and the cert issued by the CA (and possibly an intermediate certificate depending on the CA).
Do you have the private key? If it didn't already exist, it would have been created when the CSR was generated.
Tim Holloway wrote:A CSR is a Certificate Signing Request. It's what you send to your registrar for them to sign and return as the actual cert. A keystore stores private keys and certs, not - unless I've forgotten something - CSRs, which as far as I can recall are useless once they've been signed.
However, a cert doesn't carry a port number on it. So you should be able to use the same cert for both ports, assuming that the domain name on the cert matches the domain name for the Tomcat Host.
These days I'm not a big fan of using SSL on Tomcat anyway. Instead I front Tomcat with a reverse proxy like Apache or Nginx and use SSL on the proxy. Note, however, that the Tomcat cert files are in a different format than those used by Apache/Nginx (there is a nice GUI utility that can translate them, though).
Aside from that, even if you want Tomcat to be encrypted, port 8080 is supposed to be the unencrypted port. The standard for its SSL port is 8443.
Liutauras Vilda wrote:g tsuji, have a cow.
Certainly more elegant way to do that in this particular case.