Adding a JMS Queue to Wildfly 8.x

The messaging subsystem in Wildfly is enabled in the standalone-full.xml config (not standalone.xml).

To add a new queue, search for <subsystem xmlns=”urn:jboss:domain:messaging:2.0″>, and then within the <hornetq-server> section, add a new <jms-destinations> if it doesn’t exist already, and define your queue name and JNDI lookup:

<jms-destinations>
    <jms-queue name="exampleQueue">
        <entry name="jms/queue/example"/>
        <entry name="java:jboss/exported/jms/queue/example"/>
    </jms-queue>
</jms-destinations>

 

James Gosling at JavaOne 2014 vs JavaOne 2009

JavaOne 2014 wrapped up today, and was another great year, with plenty of awesome sessions. James Gosling played an active part in the Q&A during the Community Keynote this morning, and also gave a retrospective of the development of Java. He was wearing one of his Nighthacks Diner shirts, which I think we’re given out as a special prize at a JavaOne several years back (based on the painting by Edward Hopper, ‘Nighthawks Diner’). I seem to remember the design on this particular shirt, so did some digging in my photos from JavaOne conferences in the past, and here you go:

This is from JavaOne 2009 – I believe James was visiting some of the exhibitions in the Exhibition Hall:

 

And from this morning during the Community Keynote:

Eclipse error: Access restriction: The type ‘xyz’ is not API

Eclipse has some pretty bizarre error messages that really don’t tell you exactly what the error is or how to fix it. This weekend I saw this one for example:

Access restriction: The type 'xyz' is not API (restriction on required library ...)

A quick Google told me what this actually means is that I have a line of code using a JDK API that is not in the currently selected runtime for the current project, but does exist in other available runtimes.

For example, when setting up a project with a Maven pom.xml, if you don’t explicitly specify what JVM version you want for the project, you get Java 5 by default.

There’s a couple of different ways to change the JVM version using Maven, but the approach I prefer is by adding properties (because it’s more concise than configuring the Maven compiler plugin):

<properties>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.source>1.8</maven.compiler.source>
</properties>

Alternatively if you’re not using Maven, just change the JRE System Library in the project settings on the Java Build Path/Libraries tab (remove the one that’s currently there and add the version that does have the APIs that you’re using, most likely a later version).

Migrating Legacy AdMob to Google Play Services / Google Mobile Ads SDK

I developed my first Android app a few years back and at the time it was using Admob for mobile banner ads. Google bought AdMob a while back, and the time has come where Legacy AdMob usage is being retired this month (August 2014) and so you need to upgrade to the Google Play Services based Google Mobile Ads SDK.

First. Wow. I have to say, the steps and docs for how to do this seem to be spread over many different places. I’m not sure if all of these places actually walk you through the same steps just written in a different way, but it’s taken me a while to work out what I actually need to do. Some useful refs:

If you logon on the AdMob site, it will prompt you to complete a data migration step and update some account info – take care of that first here.

Info about legacy AdMod shutting down is here. Additional info in the FAQ.

Steps for moving to the Google Play Services based advertising seems to be covered here. I’m currently working through these steps for one of my apps, if I come across anything useful to share then I’ll post another update later.