Hibernate OGM / JAX-RS / JAX-WS redeployment issue on WildFly8.2: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel

I’ve been struggling with failing redeploys on WildFly8.2 while I’m developing my app. If the app is deployed, on first server start it starts up fine, but then if I redeploy some code changes I get this NoSuchMethodException in the asm library, suggesting I’ve got some conflict of versions of the asm library used by my app:

Caused by: java.lang.NoSuchMethodException: org.objectweb.asm.MethodWriter.visitLabel(org.objectweb.asm.Label)
 at java.lang.Class.getMethod(Class.java:1773) [rt.jar:1.8.0_20]
 at org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:85)
 ... 28 more

Luckily I came across this post with the same error, putting me on the right direction about the possibility of my app being packaged with a conflicting version of asm. Looking at a ‘mvn dependency:tree’ on my app, I could see asm being pulled in from my use of Hibernate OGM and Jersey as transitive dependencies.

Despite trying to add excludes to not get asm included in the packaging of my app, I eventually gave up and decided to just remove my luckily minimal use of Hibernate OGM. I think the issue was caused my OGM’s deployment of modules onto the WildFly server, one of which was asm. After I had removed OGM from my app, removed the modules, I was back to speedy redeploys of my app.

I’m sure there’s a way to get OGM to deploy happily, or maybe I had just ran across an asm version conflict with other libraries my app is using (Jersey?), but I don’t have time right now to deal with it. Another project for another day 🙂

Local javac path issues on older OpenShift WildFly8.2 based project

I have an app that I created a few months back on OpenShit based on the WildFly 8.2 cartridge. Locally in Eclipse the project builds and compiles fine, but executing mvn directly or in Netbeans (which also builds using your mvn pom.xml), it fails with an error regarding a path to javac:

-------------------------------------------------------------
COMPILATION ERROR : 
-------------------------------------------------------------
Failure executing javac, but could not parse the error:
/bin/sh: ${env.OPENSHIFT_WILDFLY_DIR}usr/lib/jvm/jdk1.8.0_05/bin/javac: bad substitution
1 error

This is obviously setup for building specifically in the OpenShift environment with this property defining the path to javac:

<maven.compiler.executable>${env.OPENSHIFT_WILDFLY_DIR}usr/lib/jvm/jdk1.8.0_05/bin/javac</maven.compiler.executable>

There’s a few posts and discussions about this (e.g. here and I suspect this is related), but I’m guessing the version of the pom.xml I have is older and been changed recently. I created a new OpenShift WildFly based project to compare the created pom.xml, and these two properties are no longer in the pom.xml file:

<maven.compiler.executable>${env.OPENSHIFT_WILDFLY_DIR}usr/lib/jvm/jdk1.8.0_05/bin/javac</maven.compiler.executable>
<maven.compiler.fork>true</maven.compiler.fork>

Removing them fixes my local builds, and pushing the code to OpenShift still seems to build ok too.

Mounting Linux ext partitions on OS X

I wanted to check some files on an SD Card formatted in ext that I had used on my Pi and wanted to check if I had left some files in the home dir before I reimaged it. OS X doesn’t support ext formatted drives by default, but you add support using OSXFuse.

  • Install Fuse for OS X
  • Install the ext plugin for Fuse
  • Find the partition you want to mount with: diskutil list
  • Make a mount point – not sure on Mac OS X where is the best place, but I added /mnt/sdcard
  • Mount with:


    [code]sudo fuse-ext2 /dev/disk1s2 /mnt/sdcard[/code]

  • (replace with the /dev/ to your device)

I’m not sure if it’s best practice on the Mac to mount with sudo, but this worked for me for what I needed to do. Fuse mounts on ext are r/o by default, but there is experimental r/w support that can be enabled, check the docs.

Done!

node.js process.cwd() “no such file or directory” starting http-server

When starting the node.js http-server, I got this error:

[code]Error: ENOENT, no such file or directory
at Error (native)
at Function.startup.resolveArgv0 (node.js:720:23)
at startup (node.js:63:13)
at node.js:814:3[/code]

From the post here, it seems this error can occur if you attempt to start the server in a dir that’s already been deleted. In my case I had renamed a folder that contained the folder where I was attempting to start the server. cd’d up a couple and into the new/renamed folder, and problem solved.