Skip navigation

Tag Archives: java

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 spoke with a recruiter recently, in an attempt to get a feel for the marketability of Ruby skills in my area. He hadn’t heard of any Ruby jobs that were available, but he did have one that called for Groovy on Grails. I have heard of this technology in the past, but didn’t know what it was. After a bit of research it seems to be language and convention-over-configuration framework that runs on the JVM, very similar to Ruby. So this has gotten me wondering if focusing on Ruby would be a mistake. Judging by the number of resources I encountered for each during my brief investigation, I’d say that Groovy doesn’t seem to be anywhere near as popular as Ruby. But if there is a job market for Groovy over Ruby in my area, perhaps I should be looking there instead.

Of course, it would be foolish to change my entire career path on such a minor and anecdotal conversation. If I get out of this missed deadline hole I’ve dug for myself at work, I’ll have to research the topic more seriously. I’m new to both, so I’m thinking that I’ll still lean toward the tech with more free tutorials and resources available. I have such a backlog of codeschool lessons and youtube videos to watch, I don’t think I’ll ever catch up.

In related news, I have decided against developing on Dreamhost’s version of Ruby/Rails. They are extremely old (Rails 3.03, anyone?) and I can’t upgrade them on the shared hosting I have. I’ll look at getting some dedicated Ruby hosting once I have something worth sharing.

I despise working with file paths in Java. I can never remember where, in the project’s folder structure, the jvm considers root. And it gets even more complicated once you start running your applications in a server container. However, I did find a quick way to determine where a running JVM considers root.

import java.io.File;

...

File f = new File("dummy");
 _log.info("file is at " + f.getAbsolutePath());

This should print out the absolute path to where this File object would be saved. You can use this as a starting point and do any sort of relative filepathing you need to from here.

Somehow, I broke my Fedora installation this weekend.

After having a great time getting started on my Gravatar project this past Saturday, I settled in for some Labor Day programming yesterday. However, as soon as I tried to open Eclipse, I was given an error message telling me that the command ‘java’ was not in the PATH variable (or something like that)

I have no idea what the hell happened between Saturday and Monday, my laptop was shutdown between those times.

At first, I thought it might be some leftover quirks from the time that Fedora shut itself down when my battery died (the fact that it didn’t warn me is pretty crappy). I ran some fsck’ing on a few mounts. But I don’t know what I’m doing there, so I wasn’t surprised when that didn’t work.

I decided to go for the obvious and just fix the PATH variable. This required me to figure out where this damn variable is in Linux. I also wanted to uninstall Oracle’s JDK 7 as I thought that might have been a part of the problem. First, linuxquestions.org helped me uninstall all java packages with the ‘yum upgrade -y’. I don’t know what it does, but it set me back to using openjdk7. Then a stackoverflow post helped immensely by showing me where my PATH variable was and how to alter it.

After I added the openJDK filepath to my PATH variable, I logged out and logged back in. ‘java’ at the command line works again and Eclipse opens without a problem.

Issue resolved.

So I mentioned yesterday that I am attempting to make my first Vaadin app using Eclipse and the Liferay IDE plugin. This post is a word of warning to those trying to do the same thing. The default Liferay Vaadin project is broken; it will not deploy.

To get started, I simply used the Eclipse, “New Liferay Portlet” wizard. So the project skeleton gets build without a hitch. The trouble happens when I attempt to deploy this app in its current default configuration.

Check this out…

INFO: 15:50:43,968 INFO [PluginPackageUtil:1099] Reading plugin package for NewVaadinProject-portlet
WARNING: Error in annotation processing: java.lang.NoClassDefFoundError: org/springframework/transaction/PlatformTransactionManager
WARNING: Error in annotation processing: java.lang.NoClassDefFoundError: org/springframework/transaction/PlatformTransactionManager
INFO: 15:50:48,083 INFO [PluginPackageUtil:1099] Reading plugin package for NewVaadinProject-portlet
INFO: 15:50:48,245 INFO [PortletHotDeployListener:614] Registering portlets for NewVaadinProject-portlet
SEVERE: =================================================================
Vaadin is running in DEBUG MODE.
Add productionMode=true to web.xml to disable debug features.
To show debug window, add ?debug to your application URL.
=================================================================
INFO: 15:50:48,284 ERROR [PortletBagFactory:313] javax.portlet.PortletException: Application not specified in portlet parameters
javax.portlet.PortletException: Application not specified in portlet parameters
 at com.vaadin.terminal.gwt.server.ApplicationPortlet2.init(ApplicationPortlet2.java:40)
 at com.liferay.portlet.InvokerPortletImpl.init(InvokerPortletImpl.java:246)
 at com.liferay.portlet.PortletInstanceFactoryImpl.init(PortletInstanceFactoryImpl.java:216)
...removed for clarity...
 at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:209)
 at java.util.TimerThread.mainLoop(Timer.java:512)
 at java.util.TimerThread.run(Timer.java:462)
SEVERE: =================================================================
Vaadin is running in DEBUG MODE.
Add productionMode=true to web.xml to disable debug features.
To show debug window, add ?debug to your application URL.
=================================================================
INFO: 15:50:48,286 ERROR [HotDeployUtil:114] com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering portlets for NewVaadinProject-portlet
com.liferay.portal.kernel.deploy.hot.HotDeployException: Error registering portlets for NewVaadinProject-portlet
 at com.liferay.portal.kernel.deploy.hot.BaseHotDeployListener.throwHotDeployException(BaseHotDeployListener.java:46)
 at com.liferay.portal.deploy.hot.PortletHotDeployListener.invokeDeploy(PortletHotDeployListener.java:118)
 at com.liferay.portal.kernel.deploy.hot.HotDeployUtil._doFireDeployEvent(HotDeployUtil.java:111)
...removed for clarity...
 at org.glassfish.deployment.autodeploy.AutoDeployService$1.run(AutoDeployService.java:209)
 at java.util.TimerThread.mainLoop(Timer.java:512)
 at java.util.TimerThread.run(Timer.java:462)
Caused by: javax.portlet.PortletException: Application not specified in portlet parameters
 at com.vaadin.terminal.gwt.server.ApplicationPortlet2.init(ApplicationPortlet2.java:40)
 at com.liferay.portlet.InvokerPortletImpl.init(InvokerPortletImpl.java:246)
 at com.liferay.portlet.PortletInstanceFactoryImpl.init(PortletInstanceFactoryImpl.java:216)
 at com.liferay.portlet.PortletInstanceFactoryImpl.create(PortletInstanceFactoryImpl.java:139)
 at com.liferay.portlet.PortletInstanceFactoryUtil.create(PortletInstanceFactoryUtil.java:40)
 at com.liferay.portal.deploy.hot.PortletHotDeployListener.initPortletApp(PortletHotDeployListener.java:590)
 at com.liferay.portal.deploy.hot.PortletHotDeployListener.doInvokeDeploy(PortletHotDeployListener.java:309)
 at com.liferay.portal.deploy.hot.PortletHotDeployListener.invokeDeploy(PortletHotDeployListener.java:115)
 ... 38 more
INFO: WEB0671: Loading application [NewVaadinProject-portlet] at [/NewVaadinProject-portlet]
INFO: NewVaadinProject-portlet was successfully deployed in 4,452 milliseconds.
INFO: [AutoDeploy] Successfully autodeployed : C:DEVbundlesliferay-portal-6.1.0-ce-ga1glassfish-3.1.1domainsdomain1autodeployNewVaadinProject-portlet.war.

A basic, right-out-of-the-box project will not deploy correctly?! Wow, a bang-up job guys!

Fortunately, I didn’t have to spend too much time debugging this, as a coworker of mine is a few months further into his Vaadin training than I am and was able to find a solution rather quickly.

The problem lies in the default configuration of the portlet.xml file. Open the file and change the following line:

<?xml version="1.0"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0">
 <portlet>
 <portlet-name>CreateUser</portlet-name>
 <display-name>CreateUser</display-name>
 <portlet-class>com.vaadin.terminal.gwt.server.ApplicationPortlet2</portlet-class>
 <init-param>
 <name>view-template</name> should be <name>application</name>
 <value>CreateUser.CreateUserApplication</value>
 </init-param>
 ...
 </portlet>
 </portlet-app>

Just run the Ant deploy target after this change, and the project should auto-deploy successfully!

%d bloggers like this: