Articles, notes and random thoughts on Software Development and Technology
I’m not sure why I haven’t tried this earlier, but by default, when you git push your updates to OpenShift Online, it stops all your cartridges, builds, deploys and then restarts everything, which can take a few minutes.
OpenShift 2.0 supports a hot deploy option to minimize the amount of time that your app is down – details are in the docs here.
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 🙂
Let that statement sink in for a minute – in Windows 10 Insider Preview builds, users have indicated they are:
"34 per cent more likely to be strongly satisfied with the filtered Taskbar"
… and based on that not-so-convincing statistic it’s been decided that the taskbar for a virtual desktop will only show apps running on that desktop (presumably hiding others that are running on other desktops at the time time?).
Gabe Aul at Microsoft describes in this post the latest features in the Windows 10 preview build and how feedback from preview build users is helping Microsoft decide what new features will make it into Windows 10, and which won’t.
And there you have it. Apparently the design of the Ribbon Bar in the latest Office versions was also designed the same way, based on observed/recorded usage patterns of ‘actual users’. If you think the Ribbon Bar is actually a good design then I won’t waste my time arguing with you, but most would probably agree from a usability point of view it’s a horribly cluttered, confused mess of somewhat related options. The Ribbon Bar reminds me of a set of cluttered drawers that are where you stuff your junk that you don’t have anywhere better to put. Each drawer has vaguely related things in it, but good luck trying to find something specific – you open a drawer and spend 10 minutes digging around in there trying to find what you’re looking for. Similarly for the Ribbon Bar – good luck finding that one specific feature.
So at some point if your’re lucky enough (?) to have Windows 10, you might wonder exactly how Microsoft arrived at a decision for why a certain feature is a certain way. And you can be assured that it was designed that way because 34% of preview build users (by a long way as far from a typical user as you can get) decided they were ‘most likely to be strongly satisfied’ if it was that way.
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.