java.util.logging is a joke

pointing the logging system to a properties file works with -Djava.util.logging.config.file=logging.properties
HOWEVER
if you have this contents for example:

handlers=java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

it will give the error:
"Can't set level for java.util.logging.ConsoleHandler"

This is simply because there is a SPACE after "level=FINE ".  Really!?  That's terrible.  Back to log4j or maybe logback.

Undoing a subversion checkin

These two methods are equivalent for undoing a checkin you screwed up:

svn merge -c -12345   is the same as  svn merge -r 12345:12344

svn merge -c 12345   is the same as  svn merge -r 12344:12345

http://blog.johang.se/2009/03/revert-commit-in-subversion.html

http://mybravenewworld.wordpress.com/2007/11/13/subversion-how-to-revert-a-bad-commit/

so after my bad merge I did:

C:\development\trunk\project>svn merge -c -12465 .

which brought the code on my machine back to where it was before the bad commit

then I committed changes as normal

then I did:

C:\development\trunk\project>svn merge -c 12465 .

to check out the changes that I actually wanted

Jersey JSON error after upgrading

We are stuck in the past with a lot of our libraries which causes headaches.  One example was that we were still using Jersey 1.0.3, which was causing problems when upgrading to Glassfish 3.1 from 2.1.  Upgrading all the project poms to Jersey 1.5 (which is bundled in Glassfish 3.1 at the moment, where 1.8 is almost done...) wasn't too bad, and I centralized the version number in the process.  The app deploys fine, but then we ran into this error:


javax.ws.rs.WebApplicationException: com.sun.jersey.api.MessageException: A message body writer for Java class blah, and Java type class blah, and MIME media type application/json was not found

All it took to solve this problem was to add jersey-json to the dependencies:

<dependency>
    <groupId>com.sun.jersey</groupId>
    <artifactId>jersey-json</artifactId>
    <version>1.5</version>
</dependency>

Credit to http://stackoverflow.com/questions/6027097/how-to-produce-json-output-with-jersey-1-6-using-jaxb

Running javascript inside a sandbox in a jvm

I'm putting a couple of pieces together here that weren't in one place.  When introducing Rhino javascript engine into our code, we wanted to lock down its access.  Java 6 hides the internal Rhino context well enough that I couldn't figure out how to get at it.  So to restrict access to a given set of classes when running untrusted Javascript inside the JVM you need to start your own Rhino context up, then hook in the filter.

The useRhinoDirectly() method gives a Rhino context in which we can set up a class filter:
http://stackoverflow.com/questions/4639892/whats-the-difference-between-java-6s-built-in-version-of-rhino-and-the-rhino-pa

Building the class filter is easier standing on someone else's shoulders.  This example blocks access to static methods:
http://riven8192.blogspot.com/2010/07/java-rhino-fine-grained-classshutter.html
(Not sure which Text class this was using, but String.split() seemed to do the job.)

Most awesome error message ever

Trying to list the contents of a keystore I got the most awesome error message ever:

$ keytool -list -keystore keystore.jks

keytool error: gnu.javax.crypto.keyring.MalformedKeyringException: incorrect magic

uh, what?

$ which keytool

/usr/bin/keytool

Also notice it has "gnu" in the class name.  The path /usr/bin wins over the later path /opt/jdk1.6.0_21/bin which is the keytool I actually wanted since I'm using Sun and not GNU.

Wicket deployment vs. development mode with Maven build

pom.xml:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <configuration>
                ...
                <webResources>
                    <webResource>
                        <directory>${basedir}/src/main/webapp/WEB-INF</directory>
                        <includes>
                            <include>web.xml</include>
                        </includes>
                        <targetPath>WEB-INF</targetPath>
                        <filtering>true</filtering>
                    </webResource>
                </webResources>
            </configuration>
        </plugin>

   ...
  <profiles>
      <profile>
          <id>dev</id>
          <properties>
              <wicketconfig>development</wicketconfig>
          </properties>
          <activation>
              <activeByDefault>true</activeByDefault>
          </activation>
      </profile>
      <profile>
          <id>release</id>
          <properties>
              <wicketconfig>deployment</wicketconfig> <!-- variable in web.xml -->
          </properties>
      </profile>
  </profiles>


web.xml:

    <filter>
        <filter-name>WicketApplication</filter-name>
        <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
        <init-param>
            <param-name>applicationClassName</param-name>
            <param-value>com.rootAppClassNameGoesHere</param-value>
        </init-param>
        <init-param>
            <param-name>configuration</param-name>
            <param-value>${wicketconfig}</param-value>
        </init-param>
    </filter>