Search This Blog

Thursday, November 5, 2015

GotoMeeting G2MUpdate hinders sleep mode in Mac OSX

Today I noticed that my iMac constantly wakes up even if there are no applications open. The reason in my case was GotoMeeting, which I installed a few days ago on that iMac. The default installation activates the automatic update preferences. This little checkbox creates a launch agent in your ~/Library/LaunchAgents called com.citrixonline.GoToMeeting.G2MUpdate.plist.
This agents starts each our and searches for updates (a release each hour, wow those guys might be magicians).
To get rid of it do the following

  1. Open GotoMeeting Software
  2. Select preferences within the GotoMeeting app toolbar
  3. Select updates
  4. Deselect the checkbox 


Thursday, October 29, 2015

Color vi editor

To get a colored vi editor create a .vimrc in your root folder with the following content:

syntax on
colorscheme desert





Wednesday, October 28, 2015

Using sublime in MacOSX or Linux terminal

To use SublimeText editor within your console just create a link like

ln -fs /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl    /usr/local/bin/sublime

and from now on you could use Sublime in your console like this

andre ~$ sublime .bashrc 

Wednesday, October 21, 2015

set file.encoding in a JVM

To set the default file.encoding in a JVM you could set it in the JVM startup as -Dfile.encoding=UTF-8 or in JAVA_TOOLS_OPTIONS with the same part. But if you want to set it programmatically after the JVM already started?
A System.setProperty("file.encoding", "UTF-16"); will only set the file.encoding property. All other classes which rely on the defaultCharset, like all Streams and Buffers won't recognize that change. Here is a Junit Test, which shows you how to reset the Charset.defaultCharset field:


package de.kambrium;

import java.lang.reflect.Field;
import java.nio.charset.Charset;

import org.junit.Before;
import org.junit.Test;

public class CharsetTest {

    @Before
    public void setUp() throws Exception {
    }

    @Test
    public void test() throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException {
        dump("Actual system config");
        System.setProperty("file.encoding", "UTF-16");
        dump("Config after System.setProperty(\"file.encoding\", \"UTF-16\")");
        Field cs = Charset.class.getDeclaredField("defaultCharset");
        cs.setAccessible(true);
        cs.set(null, null);
        dump("Config after manipulating defatulCharset field");
    }

    private void dump(String msg) {
        System.out.println(msg);
        System.out.println("****************************************************************");
        System.out.println("file.encoding          = " + System.getProperty("file.encoding"));
        System.out.println("defaultCharset         = " + Charset.defaultCharset());
        System.out.println("****************************************************************");
        System.out.println("");
    }
}


Output will look like this

Actual system config
****************************************************************
file.encoding          = UTF-8
defaultCharset         = UTF-8
****************************************************************

Config after System.setProperty("file.encoding", "UTF-16")
****************************************************************
file.encoding          = UTF-16
defaultCharset         = UTF-8
****************************************************************

Config after manipulating defatulCharset field
****************************************************************
file.encoding          = UTF-16
defaultCharset         = UTF-16
****************************************************************

JUnit in eclipse

Running JUnit in eclipse shouldn't be a problem. I run into a

java.lang.NoSuchMethodError: org.junit.runner.Description.getClassName()Ljava/lang/String;

while using a bunch of projects in eclipse. Reason for that error was a project, which has an older version of Junit in his build path. Removing the old ref solves the problem.

Tuesday, April 28, 2015

Script for grabbing a root ca cert of a website

If you are using self signed certs or you are using certs, which are not part of the standard cacerts of your JDK you need to get the root ca cert from the desired website. To do so you might use the following script:

#!/bin/bash
ADDRESS=$1
echo -n | openssl s_client -connect $ADDRESS:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ./$ADDRESS.cert 



now you should have a cert file, which you could easily add to your cacert file of the jdk with this command:


keytool -importcert -alias startcom -file $ADDRESS.cert -keystore cacerts -storepass changeit

cacerts is located in JAVA_HOME/jre/lib/security (i.e. Mac OSX /Library/Java/JavaVirtualMachines/jdkX.X.X_XX.jdk/Contents/Home/jre/lib/security/cacerts)

This command adds your cert to the cacerts of the jdk and allows any java app using the jdk to connect via ssl to the desired website. Downsite of this trick is if you move to another server or workstation you might always need to patch the cacerts with your cert. 
So the best way is to prepare a keystore with your add on certs and add it to the Java System property

-Djavax.net.ssl.keyStore=/tmp/mykeystore.jks
or even in your Java Code by using System.setProperty. This will ensure that your java prog uses trusts the certs you want to trust.