Deploying a Jersey based web app to WildFly 8 (part 1)

I’ve been resuscitating a personal Amateur Radio related project from a few years back that I previously had hosted on RedHat’s OpenShift. It was previously deployed on WildFly 8, so before I start making changes I want to get it deployed again locally on WildFly 8.

First up I got this error:

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type ServiceLocator with qualifiers @Default at injection point [BackedAnnotatedField] @Inject private org.glassfish.jersey.internal.inject.ContextInjectionResolver.serviceLocator

This error appears to be pretty common. From the suggestions posted in reply to a similar post to WildFly forum here, the suggestion was to include Glassfish dependencies. I never had these included before, so not sure why I need these now, but these did the job:

<!-- kh added for error: WELD-001408: Unsatisfied dependencies for type Set<Service> with qualifiers @Default -->
<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>17.0</version>
</dependency>

<!-- kh: added per: https://developer.jboss.org/thread/240847 -->
<dependency
  <groupId>org.glassfish.jersey.containers.glassfish</groupId>
  <artifactId>jersey-gf-cdi</artifactId>
  <version>2.14</version>
</dependency>

<dependency>
  <groupId>org.glassfish.jersey.containers</groupId>
  <artifactId>jersey-container-servlet</artifactId>
  <version>2.14</version>
</dependency>

The odd thing is if I deploy to WildFly 8.2 I don’t get this error or need these additional dependencies. Anyway, all set for now. I just tested deploying to 17.0.1 with no additional changes needed either.

Revisiting my spotviz.info webapp: visualizing WSJT-X FT8 spots over time

A few years back I built an AngularJS webapp for visualizing JT65/JT9 spots over a period of time, logged as you run the WSJT-X app to decode FT8 signals you receive at your station. At the time I had it deployed on RedHat’s OpenShift, running in a couple of ‘gears’: one for JBoss hosting a REST API backend, a queue and MDB for processing uploaded spots, and one for a MongoDB database to store the collected spot info. Unfortunately the ‘bronze’ basic plan which was an incredible good deal for hosting apps at the time (at around $1 a month if I remember right) was discontinued, and the replacement plans were multiple times the cost, so I discontinued the app and didn’t redeploy it again after that.

At some point thought I was planning on taking another look at deploying it elsewhere, and if I’m going to pick it up again, I might as well take a look at refreshing the architecture. Here’s what the original v1 deployment looked like:

For personal projects I typically build them using some api or technology I want to get more familiar with. I remember at the time I had a need to refresh myself on JAX-WS SOAP based webservices, so the client that is monitoring the WSJT-X log file and uploading to the serverside for processing is a generated JAX-WS client to a webservice deployed in front of a queue; it receives the messages sent from the client and adds them to the queue for processing. If I had to refresh this part there’s no real need for this to be as heavy as JAX-WS and could be simpler with a simple REST api, so that’s probably how I’ll update that part.

I’m interested in something like Apache Kafka can be used to process high volumes of incoming data, so this might be a good refresh for the serverside queue and MDB.

I remember putting a lot of time into building my animated map display of received spots in the AngularJS app. This was back in 2015 I think, so this could probably do with a refresh to at least the latest/current Angular version, which would be a considerable rewrite I think. I’ll take a look.

Anyway, I haven’t run any part of this even locally in development for years, so that will be my first steps, get it up and running, and then start incrementally updating some of the parts.

This project is related to my recent experiments with getting WSJT-X and a SDRPlay RSP2 running on a Raspberry Pi, as a low cost FT8 monitoring station, so now that part is up and running, time to work on the software side again.

Running WSJT-X on a Raspberry Pi using an SDRPlay RSP2

Using the preconfigured/installed Raspberry Pi .img from SDRPlay (here), it’s pretty easy to get WSJT-X up and running once you work out some stuttering audio issues with GQRX or CubicSDR (both installed on the image). I’m using a Raspberry Pi 3 for this experiment, maybe a new RPi 4 would have better results.

First download and install the .deb for the Raspberry Pi from the WSJT-X page here.

Start up either GQRX or CubicSDR and tuning to the standard FT8 frequency for the band you’re listening to, eg. 14.074MHz for 20m.

Here’s GQRX listening on 14.074MHz:

it was good to see that there must already be preconfigured virtual source/sink configured for alsa/pulse audio, so just selecting the available pulse audio as the input in WSJT starts to get you signals on your waterfall. I was fully expecting to have to configure my own source/sink virtual audio cables to pipe the audio from one app into the other, but this seems to be ready to go straight out of the box with the supplied .img:

At this point though I was stuck for a while trying to work out why I was not getting successful decodes, notice all the signals in the waterfall above, but the decodes window on the left is empty. I checked the audio sample rate in GQRX was 48khz, and I checked ntpd was running so my clock time was in sync.

I went round in circles trying to debug this for a while until I listened to the audio being received and realized the audio from GQRX was stuttering, it was only out putting about 1/2 sec audio in every sec. Decreasing the SDRPlay RSP2 sample rate in CubicSDR all the way down to the minimum 250kHz solved the stuttering (slightly higher sample rates worked too, but I didn’t need more than this for listening on a single frequency, and this same approach worked in GQRX too), and now with constant audio with no dropouts, I was getting good decodes in WSJT-X:

Logging my spots out to pskreporter, 40m at 11pm this evening was not great, but had a few spots on the West coast and also out to Cuba:

This is great that you can get an SDRPlay RSP2 running as a receiver on a Raspberry Pi and also run WSJT at the same time. I have a few ideas for how I can use this as a low power setup running 24×7… more details to come as my project takes shape… 🙂

Is the software development industry trapped in a cycle of being ‘perpetually immature’?

A while back an xkcd comic on Voting Software attracted a lot of attention on Twitter for it’s alarmist comparison of the attitudes of the software development industry to other engineering disciplines and in particular, this statement:

“our entire field is bad at what we do, and if you rely on us, everyone will die”

From: https://www.xkcd.com/2030/
Voting Software
From: https://www.xkcd.com/2030/

This was widely shared and quoted on Twitter, and even shared by industry leaders such as Grady Booch:

https://twitter.com/Grady_Booch/status/1027291830101016576

There was one comment in reply to Booch’s tweet that particularly resonated with me:

https://twitter.com/Joerg1968/status/1027417862422573057

“I fear that perpetual adolscence is our curse and our gift – (we’re) always chasing the next shiny thing”

Joerg Muller-Kindt

This thought that as an industry we’re stuck in “perpetual adolescence” caught my attention. As an industry we struggle to advance. What’s unusual when you think back over the past 20 years and even further back looking at the history of our industry, there are developments and ‘movements’ where groups of individuals come together to champion an idea that at first seems to make a positive improvement to our industry as a whole, and then over a few more years the ideas fade away and seem to be forgotten. Some are even occasionally rediscovered again by another group of like-minded individuals years later.

The ‘perpetual adolescence’ of our industry as I see it is not that we’re stuck at a particular point in our industry’s growth and unable to progress, we do progress and advance. This growth however, appears to be in short cycles where we move forward, but then we go back to what we were doing before, and we’re stuck in a cycle of discovery and rediscovery. It’s not as bad as one step forward, two steps back, but it does appear to be something like one step forward, one step back. We’re never continually advancing, occasionally we move forward but we end up going backwards again. The progress of our industry never seems to be continually moving forward. Maybe this is typical of any industry in its infancy.

Examples:

  • The ‘software crisis‘ of the 1970s
  • Structured Analysis and Structured Design
  • Formal methods
  • 4GL development tools focused on developing specific styles of application (e.g. PowerBuilder, and client/server type systems)
  • The hype of Object Oriented languages
  • Fred Brooks seminal article “No Silver Bullet
  • CASE (Computer Aided Software Engineering) tools and code generation – mid 1990s
  • UML, Rational Unified Process (RUP)
  • The Agile Manifesto
  • The cycle of centralized vs decentralized (distributed) systems
  • The hype of Functional languages
  • Strongly typed vs dynamic languages
  • Platform independence vs platform dependence (of languages and technologies)
  • Software development as an engineering discipline or an art, and everything in between
  • Serverless, as the solution to all problems

There’s plenty of other ideas and concepts that could be part of this list, and I’m not highlighting anything in my list to say these ideas good or bad, but when you look back it’s interesting how ideas come and go over time. People come and go too, some noticeably bringing new ideas and passion with them, sometimes rediscovering ideas again from the past. Sometimes as champions leave the industry their ideas no longer have a voice and their ideas disappear with them too.

If our industry is still in its infancy, is this cyclical, repetitive behavior just the industry trying out new ideas to see what sticks? Or is it that the people actively involved in championing ideas come and go too, bringing ideas in and sometimes taking ideas with them when they move on? Does this mean that as an industry as experienced developers leave the industry and new generations of developers come in, are we doomed to continually repeat our mistakes of the past?