Ad Terras Per Aspera

I’ve decided to switch to the Simple Logging Facade for Java (SLF4J) plus Logback to bridge java.util.logging (JUL), Log4J, and Apache Commons Logging all into one log output.

Problem is, JUL won’t shut up. Frameworks that log to JUL output the log to the console, and then SLF4J repeats it right after. However, putting this code in before running SLF4BridgeHandler.install() seems to fix it:

java.util.logging.Logger root_logger = java.util.logging.LogManager.getLogManager().getLogger("");

java.util.logging.Handler[] root_handlers = root_logger.getHandlers();

rootLogger.removeHandler(root_handlers[0]);

Now I get one single log output alone.

I want to use Sun’s Java.net Maven repo with Ivy, and this is not documented well anywhere.

In ivysettings.xml (Ivy will automatically use it) put:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ivysettings>
<ivysettings>
  <settings defaultResolver="chained" />
  <property name="java.net.maven.pattern"
    value="[organisation]/jars/[module]-[revision].[ext]" />
  <resolvers>
    <chain name="chained" returnFirst="true">
      <ibiblio name="ibiblio" m2compatible="true" />
      <ibiblio name="java-net-maven2"
        root="http://download.java.net/maven/2/"
        m2compatible="true" />
      <ibiblio name="java-net-maven1"
        root="http://download.java.net/maven/1/"
        pattern="${java.net.maven.pattern}"
        m2compatible="false" />
    </chain>
  </resolvers>
</ivysettings>

Now you can make an ivy.xml with dependencies like <dependency org="com.sun.grizzly" name="grizzly-http" rev="2.0.0-SNAPSHOT"/> and have it work right.

By default, the admin console can be accessed by the outside world. I prefer to have it accessible to localhost only (so I can ssh tunnel it only).

Open the admin console, and on the menu, Configuration -> Network Config -> Network Listeners -> admin-listener, and edit the IP to state 127.0.0.1, hit save, then restart Glassfish.

Although Jersey supports eating JAXB’ed classes fine, sometimes you want to manually alter the data, such as including a processing instruction for XSL stylesheets. There probably should be a less verbose way to do this.

The object should be an @XMLRootElement annotated object.

@GET
@Produces("application/xml")
public static StreamingOutput outputXMLwithXSL() {
  return new StreamingOutput() {
    public void write(OutputStream output) throws IOException,
    WebApplicationException {
      Object object = yourJAXBObject();

      JAXBContext jc = null;
      try { jc = JAXBContext.newInstance(object.getClass()); }
      catch (JAXBException e) { e.printStackTrace(); }

      Marshaller m = null;
      try { m = jc.createMarshaller(); }
      catch (JAXBException e) { e.printStackTrace(); }

      PrintStream ps = new PrintStream(output);
      ps.println("<?xml version=\"1.0\" encoding=\"UTF-8\"?>");
      ps.println("<?xml-stylesheet type=\"text/xsl\" href=\"your.xsl\"?>"); 

      try { m.setProperty(Marshaller.JAXB_FRAGMENT, true); }
      catch (PropertyException e) { e.printStackTrace(); }

      try { m.marshal(object, output); }
      catch (JAXBException e) { e.printStackTrace(); }
    }
  };
}

Sometimes you’re developing an app along with a new database schema to go with it, but you get this: Schema "null" cannot be resolved for table "XXXX".

Window -> Preferences -> Validation, JPA Validator, turn off for Build.

This probably shouldn’t be on by default anyhow, people are most likely going to build new apps from scratch than build new apps to fit old databases; and even if they do build from old, Eclipse’s JPA Tools has a build entities from tables function.