Skip navigation

Tag Archives: error

Right now, I’m spending some of my free time getting up to speed with Spring Boot. Opinionated frameworks like Spring seem like they’d be a great way to build some quick prototypes for some ideas I’ve got bouncing around my head without having to go through the learning curve a whole new language. I’m already overwhelmed enough with my operations (Linux, networking, security, application servers, etc) and Unity automation for work. And now I’m throwing some AWS into the mix for some side work with a friend.

In my experimentation with Spring Boot, I threw together a quick cat fact web service. Running mvn spring-boot:run and accessing the endpoint at http://localhost:8080/getcatfact returns some super-simple JSON with a random cat fact. Yay kitties!

I created another package, based on the Spring Boot tutorial, designed to be a “Hello, World” example. When I run the application, everything starts up fine, and the Cat Fact endpoint still works. But trying to access the http://localhost:8080/greeting endpoint results in a weird “White Label Error Page”. After some internet searching, I found a decent answer. It seems the error is related to having my packages at the wrong level. Spring will search for and load Boot applications at the initial application’s package level and any sub-packages. Since the net.bencarson.catfact and net.bencarson.hello packages were siblings and didn’t share a parent, it was obvious how to fix my problem. I just needed to create a common parent SpringBootApplication and package and move these existing applications underneath.

I created a new class for net.bencarson.services.MyServicesApplication and moved the catfacts and hello packages under the new net.bencarson.services package, the application was still throwing the White Label error for ‘greeting’.

Proper application hierarchy for Spring Boot
Moved the Spring applications under a parent package and application

The final piece I was missing was that I needed to modify my pom.xml. Inside, I had to change the <start-class> element.

<start-class>net.bencarson.services.MyServicesApplication</start-class>

Now the service starts correctly and both ‘catfacts’ and ‘greeting’ endpoints are accessible!

I have spent the past month, attempting to learn my way around the Vaadin framework. Kind of sucks that its Eclipse plug-in is broken, right out of the box. As soon as I installed it, I started getting this error whenever I would launch my IDE.

Could not start XULRunner(version 1.9 or higher required)

Could not start XULRunner(version 1.9 or higher required)

I didn’t, and still don’t, know what the hell XULRunner is. Some library from the Mozilla Developers Network that is currently at version 19.0.2, as of this writing. I think the good folks at Vaadin have abandoned this project; version 1.9 is ancient!

Software rot aside, if you’d like to get rid of this annoying error dialog, you will need to add XULRunner 1.9 to Eclipse’s file path. Here’s how I did it:

  1. Close Eclipse, if it is open
  2. Download XULRunner 1.9.2 from MDN
  3. Install XULRunner by following the instructions here for your operating system.
    1. Be sure to perform the registration step
  4. Open eclipse.ini or your Eclipse shortcut (Windows) and add the following line
    1. -Dorg.eclipse.swt.browser.XULRunnerPath=C:<path><to>xulrunner-1.9.x.x
    2. Here, you can see how I added the line to my Eclipse shortcut link
    3. Adding XULRunner to Eclipse's classpath via shortcut

      Adding XULRunner to Eclipse’s classpath via shortcut

    4. Click ‘OK’ or Save the ‘eclipse.ini’ file
  5. Start Eclipse

Hopefully, at this point, the error will be gone and you can move on to being disappointed by the Vaadin Visual Designer, distraction-free!

As a vegan and a programmer, this article I recently read, horrifies me on a few levels. In my line of work, its so easy to just think about the bugs in my code as harmless, annoyances for customers, or, at worst, maybe some giant company loses some money. Never really thought about how anything I could write could actually lead to the death of anything…

So I’m coding a Liferay portlet that will display one of two forms on it, depending on the type of customer that is viewing the page. In order to implement this, I decided to that the JSTL ‘choose’ tag would be perfect for what I need.


<c:choose>
<c:when test='<%= displayForm.equals("Form1") %>'>
...code for form 1...
</c:when>


<c:when test='<%= displayForm.equals("Form2") %>'>
...code for form 2...
</c:when>
</c:choose>

But when I deploy and run my code, I get this error:

According to TLD or attribute directive in tag file, attribute test does not accept any expressions

After about 30 minutes of searching I found the solution on this page.

I had to change

<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>

to

<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>

After that simple tweak, my forms display correctly.

No idea what this does or why I had to do it. But it worked, so I’m happy.

I am working on a way to programmatically create Liferay users for our upcoming portal release. In order to get my feet wet with the technologies that our team will be using, I want to build a quick and dirty test app that will create a user in Liferay and LDAP. But before I could even get far enough to look into that, I hit two stupid errors. They were easy enough to fix, but annoying nonetheless.

The first involved Eclipse, the Liferay Plugins SDK, and Ant. I created a new Liferay portlet project. I immediately wanted to test this app, to make sure everything was configured correctly and that it would deploy successfully. I was right in wanting to test it because I immediately, and consistently, got the following error upon a build.

Task cannot continue because ECJ is not installed.

ECJ was automatically installed. Please rerun your task.

Total time: 1 second

I have run in to this error on the command line before, except that the error only appears once. It seems that Ant copies the ecj.jar (Eclipse Compiler for Java, I think) to the appropriate directory and builds from there on out are fine.

My issue here stems from my use of the Eclipse IDE. This error occurred on each subsequent attempt to build. A quick search turned up a Liferay page that helped. It recommends copying the ecj.jar to your Eclipse Ant plugin directory. Perhaps its because I’m a control freak, or maybe its because I have been burned by builds in Eclipse before, but I opted for another solution. I followed the page’s directions to get to the Ant settings page:

Eclipse Preferences

Preferences dropdown

From this ‘Preferences’ menu, select ‘Ant’, then ‘Runtime’

Ant Options

Ant Options dialog

Here is where my changes differ from the Liferay instructions. I have a copy of Ant locally that I use for command-line builds. I clicked the “Ant Home…” button and pointed Eclipse to my local Ant installation, instead of using its Ant plugin.

ANT_HOME

Don’t rely on Eclipse’s Ant plugin. As you can see here, I am pointing to my local Ant installation.

Like I said, I guess this makes me a control freak, but I have had so many problems in the past when a system or IDE tried to manage things using its own libraries or plugins. This should also remove any possible discrepancies between any builds I may do on the command line versus Eclipse.

%d bloggers like this: