If you spotted this post on the Java Posse’s Google Group, then you might have already seen this link to a photo on Twitter from Devoxx 2014. If you were at Devoxx 2014 and attended the live Java Posse session, then you already know this too. Of course, if you regularly listen to the podcasts then you would have noticed that the regular podcast sessions dropped off noticeably last year.
The Java Posse’s final podcast session (#461), recorded from Devoxx 2014 is now live on their feed.
I’ve listened to the majority of their podcasts (and the early Javacast episodes) since the first sessions in 2005, it’s definitely the Java related technology podcast that I’ve listened to and followed the most, and so it’s sad that the guys have finally decided to call it quits and not continue the series any more.
Thanks to the guys for producing the session all these years, you’ll be missed!
So where are they now?
What am I listening too now? I’ve listened to a couple of episodes of the Java Pub House, which is ok, and on my todo list is Java Enterprise Newscast. But I don’t think you can replace The Java Posse. Thanks again guys, and good luck in your other endeavors.
(Page views: 166)
When you generate a JAX-WS client from a locally deployed service, the URL for the endpoint and the WSDL are hardcoded into the generated client code. If you redeploy the service elsewhere (i.e. moving from a local development environment to a test or production environment), then you could regenerate against the new URL for the service, but the JAX-WS api does allow you to programmatically specify the endpoint and wsdl locations.
From this post, the key is to use the BindingProvider to specify a new value for BindingProvider.ENDPOINT_ADDRESS_PROPERTY:
BindingProvider bp = (BindingProvider)port;
By itself though, this gave me an additional exception as it appears the client it still attempting to locate the WSDL. To work around this, you can also pass the new WSDL url location when you instantiate the generated client (this is discussed here). Before using the BindingProvider snippet above, pass the updated urls into the client like this:
EndpointService service = new EndpointService(
SpotCollectorEndpoint endpoint = service.getSpotCollectorEndpointPort();
(Page views: 211)
I’ve used Log4J 1.x for ages, and not even realized that the 1.x code line is not maintained any more, it seems all the activity is on 2.x as the latest maintained version of the framework.
To move from 1.x to 2.x, there’s a few changes:
If you’re using Maven for your dependencies, replace
The API has changed from:
Sample xml config – use filename log4j2.xml instead of log4j.xml (or log4j.properties):
<?xml version=”1.0″ encoding=”UTF-8″?>
<Console name=”STDOUT” target=”SYSTEM_OUT”>
<PatternLayout pattern=”%C – %m%n”/>
<Logger name=”example.logger.name” level=”debug”/>
Additional useful info here.
(Page views: 310)
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:
(Page views: 498)
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:
(Page views: 307)
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):
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).
(Page views: 1017)
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.
(Page views: 351)
Somewhere between Java 6 and 7 it seems I lost track of where your JDK gets installed on Mac OS X. Prior to Java 7, it seems it was installed to:
with symlinks pointing to the exact locations.
I was just setting up a new Eclipse install and was looking for where my 8 was installed – it was clearly installed as ‘java -version’ was telling me I was running 8, but it was no longer in the above location.
/usr/libexec/java_home (which I’ve mentioned before here) was telling me the following:
Hmm, so there you go. Looking in /Library/Java/JavaVirtualMachines/ I had multiple versions of 7 and 8. If you need to point Eclipse to a JRE location for your installed JREs, then from 7 onwards I think this is what you need.
(Page views: 403)
Caused by: com.sun.jersey.api.client.ClientHandlerException:
javax.net.ssl.SSLProtocolException: handshake alert:
unrecognized_name at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle (URLConnectionClientHandler.java:151)
at com.sun.jersey.api.client.WebResource$Builder.post(WebResource.java:5 68)
This exception is from an SSL check in SE7 and above that checks that your SSL certificate matches your domain name. For development, if you’re using a self-signed SSL certificate for testing which does not match your domain name, you can turn off the check and ignore the error with:
(Page views: 633)