Skip navigation

Category Archives: Code

Anything dealing with any kind of source code that I may interact with. Personal projects, bug fixes, workarounds for IDEs, experiments with different frameworks, stuff like that.

File paths in Java

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.

Added blog security

I don’t have a lot of money, and this blog is more of a hobby than anything, so I haven’t bought any SSL-encryption for this domain.

Thanks to lifehacker though, I have learned that two-factor authentication is catching on with several popular services, not just Gmail. To that end, I just installed the Google Authenticator plugin on this blog for a little bit of added security. It certainly doesn’t bullet-proof my site, but it does make it a little bit more secure than it was previously.

Simple minute addition in Google spreadsheet

I am working on building an after-work schedule, but didn’t want to do everything manually on paper. A quick Google spreadsheet would be perfect for this. It will keep all my data organized and automatically compute time changes so I can experiment to find the most efficient and practical schedule for myself.
However, after creating my outline, I found out that there isn’t a simple technique or formula available in Google Docs for adding time (or even dates for that matter). But I did manage to find a partial answer on StackOverflow. Google stores it’s dates as floating point values that appear to represent hours. This means that multiplying the number of hours in a day (24) by the number of minutes in an hour (60) will give me the floating point  value that represents the number of minutes I need to add.

So here’s what I did:

how to add minutes to a Google Doc spreadsheet

Adding minutes to a Google spreadsheet

The formula looks like this:

=<original time>+(<# of minutes to add>/(<number of minutes in an hour> * <number of hours in a day>))

In more simple terms:

<time next task begins> = <time previous task begins> + (<number of minutes task takes to complete>/<total minutes in a day>)

How to find AlloyUI version

I am currently working on some front-end items for our Liferay portal. I have chosen to give Liferay’s AlloyUI javascript framework, which is built on top of Yahoo’s YUI framework, a shot.

For some unnecessary reason, I wanted to find out what version of Alloy I was using. I say unnecessary because the Alloy framework hasn’t been updated since 2010! See? This is a disturbing trend I’ve noticed with Liferay’s components. Like, why are its web services written for Axis 1.4?! It was released in 2006, that is positively ancient! One of those “if its not broken, don’t fix it”-type deals, I suppose. …going down a rabbit hole here.

…getting back to the topic at hand. Ever since I watched a screencast on, the now dead, encosia.com, I have been using firebug (and now Chrome’s Developer Tools) to tweak my CSS and javascript on the fly. It also introduced me to using the browser console to actually interact with and modify a web page. The console is also useful for retrieving javascript variables, such as a framework’s version number.

I tried the obvious first:

> AUI.version

“3.4.0”

It worked, but that’s the version of YUI that Liferay 6.1.0 comes with. Not the version of AlloyUI. It took a little bit of exploring, but I managed to figure it out.

> AUI.Env.versions

Which, inside Chrome’s console, gave me:

Alloy v 1.5.0

Alloy v 1.5.0

Not perfect, but its clear to see the YUI version of 3.4.0 and the AUI version of 1.0.1.

And now you know a perfectly useless fact about AlloyUI!

A Dozen Cats Set To Be Adopted Killed By Shelter Computer Glitch

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…

Odd JSTL error & solution

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.

New non-meetup meetup

Attended a cool meeting of coders last week.

A group called OpenUpstate.

Looking forward to more meetings.

Default Liferay Vaadin project broken

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!

Ant + Eclipse + Liferay Plugins = ECJ error

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: