Skip navigation

Tag Archives: Liferay

Friday Fix: Liferay’s SASS parser on CentOS 6

In working with a Liferay theme recently, I came across a curious bug involving jRuby and CentOS 6. It manifested itself in a rather confusing SASS parser error (the details of which I don’t have anymore). To add to this confusion, I had just switched from using the traditional Ant-based Liferay plugins build to using the Maven liferay-theme-archetype. After spending almost two days trying to figure out what was going wrong with my project, and a lot of help from our NetOps genius, I stumbled across the answer. It was a library problem that existed only on Liferay systems running on CentOS 6.

Fortunately the fix is simple, as it’s just a property override.

Add the following lines to your portal-ext.properties file and bounce your server. Everything should be ready for deployment after that.

scripting.jruby.load.paths=
classpath:/META-INF/jruby.home/lib/ruby/site_ruby/1.8,
classpath:/META-INF/jruby.home/lib/ruby/site_ruby/shared,
classpath:/META-INF/jruby.home/lib/ruby/1.8,
classpath:/gems/chunky_png-1.2.1/lib,
classpath:/gems/compass-0.11.5/lib,
classpath:/gems/fssm-0.2.7/lib,
classpath:/gems/sass-3.1.7/lib

Restrict all Liferay traffic to be encrypted

Our CTO came to me recently with the results of a PCI audit. One area of non-compliance that the audit discovered was the need to have users log in only through a SSL encrypted gateway. I set about finding a way to accomplish this with Liferay. Thankfully, it was a pretty easy change and didn’t require any custom log in code (as I initially feared.)

At first, I just happened to come across a relevant property in my portal-ext.properties file.

servlet.always.encrypt=false

On my local machine, I changed this value to true, restarted the server, and all traffic on my local server redirects to the ssl encrypted version on port 8181!

“Hooray”, I thought. “I’m done!” I talked to our Ops team to get the changes made in our other environments and he promptly burst my this-is-too-easy bubble. “Why is it encrypting our marketing site? We shouldn’t be encrypting everything, just the stuff we need protected.” Damnit! Now I have to find an alternative. Fortunately for me, the same Ops guy found the relevant properties to include in our portal-ext.properties file:

#require https for login
web.server.http.port=8080
web.server.https.port=8181
company.security.auth.requires.https=true

This is exactly the technique we needed. Our site doesn’t encrypt any public-facing page (unless you are already logged in) and all logged-in traffic is SSL-encrypted. Liferay team really did me a solid by making this so easy to configure. Thanks girls & guys of Liferay!

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!

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.

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.

LDAP cn trouble with Liferay

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 = beardy@liferay.com

sn = Beard

givenName = Doctor

mail = beardy@liferay.com

title = Hirsute Physician

userPassword = <whatever encryption you use>

After much struggling and cursing, I found that my trouble was with the cn=beardy@liferay.com. 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.

Switching gears

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.

%d bloggers like this: