Programmer's Cookbook

The dockbar is a Struts portlet, so it isn't something that you can control in a theme. Instead, you can modify the JSP that the portlet view uses.

View Files
/webapps/ROOT/html/portlet/dockbar/init.jsp
/webapps/ROOT/html/portlet/dockbar/view.jsp

Whether or not to display the dockbar is controlled in the theme. So in theory you could create your own portlet or vm file to display a completely custom dockbar. The theme file portal_normal.vm, and in the default portal_normal.vm you will see this.

#if($is_signed_in)
  #dockbar()
#end

The dockbar portlet is referenced in the ROOT application (/webapps/ROOT/WEB-INF/) as portlet name/number 145. Snippets of these references are below.

liberay-portlet.xml

<portlet>
   <portlet-name>145</portlet-name>
   <icon>/html/icons/default.png</icon>
   <struts-path>dockbar</struts-path>
   <use-default-template>false</use-default-template>
   <show-portlet-access-denied>false</show-portlet-access-denied>
   <show-portlet-inactive>false</show-portlet-inactive>
   <private-request-attributes>false</private-request-attributes>
   <private-session-attributes>false</private-session-attributes>
   <render-weight>50</render-weight>
   <add-default-resource>true</add-default-resource>
   <system>true</system>
</portlet>

portlet-custom.xml

<portlet>
   <portlet-name>145</portlet-name>
   <display-name>Dockbar</display-name>
   <portlet-class>com.liferay.portlet.StrutsPortlet</portlet-class>
   <init-param>
       <name>view-action</name>
       <value>/dockbar/view</value>
   </init-param>
   <expiration-cache>0</expiration-cache>
   <supports>
       <mime-type>text/html</mime-type>
   </supports>
   <resource-bundle>com.liferay.portlet.StrutsResourceBundle</resource-bundle>
   <security-role-ref>
       <role-name>power-user</role-name>
   </security-role-ref>
   <security-role-ref>
       <role-name>user</role-name>
   </security-role-ref>
</portlet>

Labels: Liferay

Recently I had a request to move some hard-coded error messages from the source files to an external properties file. At first I ran into some issues since we were using parameters, but spring's taglib allows for that so here goes:

Spring config

<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename" value="com.harryfwong.shared.messages">
</property>


com/harryfwong/shared/messages.properties

error.testingParameters=Are you passing in Parameters: {0}, {1}?


displayError.jsp

<%@ taglib uri="http://www.springframework.org/tags" prefix="spring"%>
<spring:message code="error.testParameters" argumentseparator=";" arguments="param1;param2">
</spring:message>


Labels: arguments, Java, JSP, Messages, ResourceBundleMessageSource, Spring

I suggest using Java CSV Library, it is very easy to use. If you use Maven 2, you can use this to load it as a dependancy.

<dependency>
  <groupId>net.sourceforge.javacsv</groupId>
  <artifactId>javacsv</artifactId>
  <version>2.0</version>
</dependency>

The code below reads in a CSV file, parsing one line at a time, splitting each line into the vals array.

CsvReader rdr = new CsvReader("simeFile.csv");
while (rdr.readRecord()) {
    String[] vals = rdr.getValues();
    ...
    System.out.println(vals.length);
    // process here
}

Spring Security was only recently released, so the docs are fairly poor. So if you have been looking everywhere for the DB schema to use with <jdbc-user-service/>, look no further.

Here are the generic table create statements. The foreign-key columns are marked, which you can either ignore or translate them for your specific DB.

create table users (
  username varchar(32) primary key,
  password varchar(64) not null,
  enabled bit not null
)
 
create table authorities (
  username varchar(32) not null, [FK]
  authority varchar(64) not null
)
 
create table groups (
  id number(10) primary key,
  group_name varchar(64)
)
 
create table group_members (
  group_id number(10) not null, [FK]
  username varchar(32) not null [FK]
)
 
create table group_authorities (
  group_id number(10) not null, [FK]
  authority varchar(64) not null
)

You can generate MD5's using Java's own MessageDigest class. This class will generate the MD5 value as a set of bytes. Typically this isn't what you want. In most cases you will want to create a hex string from the bytes, so it looks something like this, "007868b95b02a639bed49adea41f266e". You can rectify this by downloading the commons-codec library, and running the bytes through the Hex class.

The code below does just this.

import java.security.MessageDigest;
import import org.apache.commons.codec.binary.Hex;

...

String myString = "The string to create a digest from";
String md5String = null;

try {
  MessageDigest digest = MessageDigest.getInstance("MD5");
  digest.update(myString.getBytes());
  md5String = new String(Hex.encodeHex(digest.digest()));
}
catch (Exception e) {}

This is one of those things that I had an admin write up for me, and something I always always forget. So I am posting here so that I don't lose it, and perhaps it will help someone else out.

1. Go to your home directory

2. Execute: ssh-keygen -t dsa

This may take a minute or so to run. Take defaults when prompted.

3. cd to ~/.ssh directory

4. Copy id_dsa.pub to target ~/.ssh directory on target server with a temporary name (i.e. .keys)

5. On the target machine rename the temp file to "authorized_keys", but make sure that it doesn't already exist.

6. Make sure that the file authorized_keys is chmod'ed to 600.

7. Try it out

Labels: ssh

Creating a new plugin (a.k.a. Mojo) is really dead simple, although the Maven site seems to make it complicated.

Start by running Maven at the command line to create a new plugin project.

mvn archetype:create \
  -DgroupId=com.blogspot.progcookbook.mojo \
  -DartifactId=maven-coolass-plugin \
  -DarchetypeGroupId=org.apache.maven.archetypes \
  -DarchetypeArtifactId=maven-archetype-mojo

The groupId will typically be the same for all of your plugins. I like to use my reverse domain name followed by ".mojo". The artifactId naming is very important. Besure to use the format "maven-<PLUGIN_NAME>-plugin".

The plugin name is used to execute individual goals. So if my plugin is named "coolass" and the goal is "runit", then I would type "mvn coolass:runit" at the command line to execute the goal.

After you run the command above, it will create a sample project with one class called MyMojo.java. Rename it as needed and make a copy for each "goal" supported by your plugin.

The goal name will need to be defined in XDoclet style tags just above the class name in the file. Here is the class definition in the sample MyMojo.java file.

/**
 * Goal which touches a timestamp file.
 *
 * @goal touch
 * 
 * @phase process-sources
 */
public class MyMojo

Here the goal is "touch", so the way this works is that running "mvn coolass:touch" will run the execute() method in this class. Rename the goal as needed.

In the sample file you will see a single member variable named outputDirectory. Note the XDoclet style annotation above it.

    /**
     * Location of the file.
     * @parameter expression="${project.build.directory}"
     * @required
     */
    private File outputDirectory;

The @parameter annotation makes this configurable in the pom.xml, and the expression defines the default value. Add and remove parameters as needed, using @required when you want to force the issue.

The last step is to install your new plugin in your local repository.

mvn install

There are more details, but this is enough to get you up and running. Check out the Maven Plugin Dev Center for more details.

Labels: Java, Maven

There are many different tools to deploy files or directories of files from server to server. There's tar, rsync, remote copy ... a bunch of things. Whichever method you use, it's in your best interests to make a backup.

To help you keep track of the backups you make at any time, use "date" along with "tar" to create timestamped files:

tar -cvfX filename_`date +%Y%m%d_%H%M%S`.tar *

example:

# find .
./somedir
./somedir/a.txt
./b.txt
./c.txt

# tar -cvfX filename_`date +%Y%m%d_%H%M%S`.tar *
a build.sh 0K
a c.txt 0K
a somedir/ 0K
a somedir/a.txt 0K


# ls *.tar
filename_20070103_101105.tar

Now, if you need to back out the tar file you explode you can just go get your previously dated version.

Have you ever opened up a text file in a VI editor and you see this character at the end of this line: ^M

For example...

<?xml version = "1.0" encoding = "windows-1252"?>^M
<web-app>^M
  <description>Empty web.xml file for Web Application</description>^M
  <context-param>^M
    <param-name>DBUrl</param-name>^M
    <param-value>jdbc:oracle:thin:@ora:1521:ora</param-value>^M
  </context-param>^M
  <context-param>^M

In many instances, these characters don’t cause a problem (e.g. your browser, an editor) but they do cause problems for CSV or XML files or anything that needs to be parsed, because they will not be validated correctly.

They occur because some programs are not consistent in the way they insert the line breaks so you end up with some lines that have both a carrage return and a ^M and some lines that have a ^M and no carrage return. It is often encountered between editors on DOS and *nix. For example if you use a text editor on your windows machine, it may not produce line breaks the same way VI would produce them on a *nix server. I had heard one time that this can also happen when FTPing a file from your machine to a *nix server when using ASCII mode and that that the safest way is to zip up files and FTP as binary – but I couldn’t find anything to substantiate that.

The solution to removing these in VI is to run the following substitution

:s/^M//g

***NOTE***: you have to enter the "^M" as "CTRL-V CTRL-M" and not "CARET M". This "^M" is a special character that needs special handling. The substitution above will remove all the ^M characters and replace them with nothing.

Also, if you don’t want to use VI, you use shell + perl to remove these characters on from the command line. Again, you can’t cut/paste these commands because you need to type ^M as “CTRL-V CTRL-M” as described above.

# recurse a directory, removing ^M from all files
find . -type f -exec perl -pi -e "s/^M//g" {} \;

# remove ^M from a specific file
perl -pi -e "s/^M//g" somefile.txt

# remove ^M from a bunch of files
perl -pi -e "s/^M//g" */*.java *.txt