Skip navigation

Everything looks cool so far on my comic site so far. No issues with ComicPress plugin I’m using there. It just looks terrible, as I’m using the out-of-the-box theme. I hope at some point I’ll be able to start looking at learning to theme WordPress sites.

But enough about that!

This past weekend I finally got fed up with the shitty drivers available for the shitty broadcom BC4311 series wireless network adapter that my shitty Dell Inspiron 1521 has.

I have tried a few more Linux distros via LiveCD:

Ubuntu 11.04 64-bit – Something about the color scheme of this distro really turns me off, the reddish-purple just makes me angry. That and the fact that my Broadcom doesn’t work, despite trying the troubleshooting items I find online.

Mint 12 64-bit – I so want version of Linux to work because of its emphasis on aesthetics. Alas, its build on Debian, just like Ubuntu, so my wireless doesn’t work here. I doubt my craptop would support a decent looking UI anyway.

Mandriva 2011 – I know next to nothing about this distro, but I am impressed with the UI and how easily I got my wireless to work.

I almost went with Mandriva, until I remembered each distro can come with different frontend/UI/desktop environment (I don’t know what the graphical part of the OS is technically called). Going back to my fav distro, I found that Mint is available in a LXDE version! Knowing what a POS my ancient laptop is, I opted to take up the ‘L’ part of the LXDE environment. Its supposed to be pretty light, so that would definitely help out my aging Athlon 2800 system. I fired up the live cd and everything looked nice. Much better than the unintuitive, unattractive KDE desktop I had spent the past month or two with.

Still no wireless support until I found this ->

After trying the items on this blog, I got wireless working on LiveCD! Bingo!

I promptly clicked the “Install Linux Mint” icon. Everything has been working great since then. A huge improvement over my experience with Fedora 16 and Fedora 16 KDE.

Now, if they’ll only come out with a 64-bit version…

Well I’ve blown away my instance of comicCMS.

Why, you may ask?

Last night I attended my first meetup, and got some exposure to WordPress outside of my current ideas about what WordPress should be used for. I learned that there are tons of plugins for WordPress, and a quick search turned up some webcomic plugins that’ll do the same thing comicCMS was doing. And since its in WordPress, it’ll be furthering my goal of becoming a front-end developer. (Good lord though, I really gotta start learning PHP.)

Hoping to get a decent webcomic plugin installed and then start uploading the “Rescue Mission” comic again.

I have just about finished uploading all of my comics from a college art project. Once I get them all uploaded and tagged, I plan on publishing them a day at a time.

Finally uploaded something to the ComicCMS that I installed a little while ago. I am at work, so I am not going to spend a lot of time on it. But it does seem easy and intuitive to navigate and post and tag content. It even keeps an order, so my “Rescue Mission” can be displayed in order.

This is definitely more appealing than writing blog posts on Liferay or attempting to get Piwik to track my traffic correctly. I’ll probably be focusing on this for a while. Its easy and fun.

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(
 at com.liferay.portlet.InvokerPortletImpl.init(
 at com.liferay.portlet.PortletInstanceFactoryImpl.init(
...removed for clarity...
 at org.glassfish.deployment.autodeploy.AutoDeployService$
 at java.util.TimerThread.mainLoop(
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] Error registering portlets for NewVaadinProject-portlet Error registering portlets for NewVaadinProject-portlet
...removed for clarity...
 at org.glassfish.deployment.autodeploy.AutoDeployService$
 at java.util.TimerThread.mainLoop(
Caused by: javax.portlet.PortletException: Application not specified in portlet parameters
 at com.vaadin.terminal.gwt.server.ApplicationPortlet2.init(
 at com.liferay.portlet.InvokerPortletImpl.init(
 at com.liferay.portlet.PortletInstanceFactoryImpl.init(
 at com.liferay.portlet.PortletInstanceFactoryImpl.create(
 at com.liferay.portlet.PortletInstanceFactoryUtil.create(
 ... 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="" xmlns:xsi="" xsi:schemaLocation="" version="2.0">
 <name>view-template</name> should be <name>application</name>

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

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.


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.

I have been struggling with getting Liferay to play nicely with our OpenLDAP server for the past two days.

I finally was able to figure out my mistake this afternoon.

Liferay expects ‘user’ entries (objectClass = inetOrgPerson, in my case) to be in the following format:

objectClass = inetOrgPerson

objectClass = organizationalPerson

objectClass = person

objectClass = top

cn =

sn = Beard

givenName = Doctor

mail =

title = Hirsute Physician

userPassword = <whatever encryption you use>

After much struggling and cursing, I found that my trouble was with the An email address is not allowed in this field.

Once I changed the cn to ‘beardy’, I was able to login to my Liferay portal using LDAP authentication, the user was imported to the Liferay database, blah blah blah. Everything works great now.

Probably a simple fix for an experienced LDAP administrator, but for a n00b like me, it was an infuriating minor detail that made all the difference in my portal working versus not working.

…I’ve got to find a way to add code to my blog.


UPDATE (06.28.2012) – I’ve found a decent enough way to do it.

I started a new job this week.

It is with a startup company here in Greenville, SC called Green Cloud Technologies. I am super-excited to be here and away from that crap company Windstream! I’ve had a few changes in my career growth as a result of this job change. First, they didn’t have any equipment for me when I started so I am currently using my own PC to work on. This is the same PC that I was teaching myself Linux on. However, I couldn’t very well learn and do everything needed for my job AND learn to do it on Linux at the same time. I’d never get anything done. So I purchased a copy of Windows 7, 8 Gb of DDR2 RAM and brought my PC to work.

That said, my focus on learning has shifted. I am no longer concerned with learning Linux, as all the tech at Green Cloud is new to me. Liferay, Glassfish, Vaadin, Git,…as I said before, I don’t have the mental bandwidth (or equipment now) to learn to use those and Linux. So I guess I’m probably going to start posting stuff on here about my findings with my new technology stack.

I’m currently working on an entry on how I got my Eclipse environment set up with Liferay. If you are using the Liferay IDE plugin with anything other than the Tomcat bundle, you are in for some headaches.

So after I stopped the FTP upload from my inappropriate account , I needed to delete the 726 megs of “illegal” uploads.
I remembered the ‘rmdir’ command, but that only works on empty directories. I remember this fact as soon as I was given the ‘rmdir: failed to remove `Pictures/’: Directory not empty” response on the command line.
I once again turned to my buddy Duckduckgo and found the answer.
I needed use the remove command with the recursive parameter ‘-r’.
About two seconds after I entered the ‘rm -r Pictures/’ command, the folder and all of its contents were gone. All four hours of uploading gone in the blink of an eye.
It is two weeks later and I am at about 10.7 GB uploated of my 25Gb total. The 512kbps upload of my AT&T DSL is really not doing it for me right now. Still not enough motivation to switch to Charter though. Maybe in 5 more months when they try to jack up my rates again.

So I decided to take advantage of the free 50Gb storage space that DreamHost offers all of its webhosting customers today.
Unfortunately, I didn’t understand that I needed to use a special user account that Dreamhost provides for me for this activity. So I am currently uploading approximately 25Gb of pictures to my account on just a normal user account. I may have my account revoked by the end of the day, who knows.
The situation isn’t too dire just yet, as evidenced by the linux command I just learned.
I logged in to my account from work to see how much data had been uploaded so far. I found the folder, but had no idea how to actually see any detail on the folder’s size. Performing a quick DuckDuckGo search has taught me to use the ‘du’ command to see the size of a folder.
So I ran ‘du -sh /Pictures’ and was greeted with the following response:
616M    Pictures/
The -s parameter means to ‘summarize’. This provides only the disk usage of the specified argument, in my case, the size of the ‘Pictures’ folder. Without this parameter, I would be given an itemized list of the disk size of all of the folders within this folder.

The -h paramenter means to make the output ‘human-readable’. Namely, converting the raw ‘616543’ kilobyte size to ‘616M’. Very handy since I hate mental math.

So its not too bad now, but I gotta get home and stop this from getting worse. Good thing its lunch time.
I can stop the process and start uploading using the appropriate account now.

Well I’m off to stop a runaway FTP upload. Times like these that I really wish I had set up my laptop for remote contol…

%d bloggers like this: