Sunday, May 10, 2009

JSF: Refresh Bean AND get different Language bundle per host (Properties)

Hi again,

two small gadgets for you:

1. Get and default bean attributes for different websites or different languages

Sometimes you have the same portlet-code for different websites. I use multiple properties files and select the same within the bean with the following code:

private void initBeanData() {
FacesContext fCtx = FacesContext.getCurrentInstance();

ResourceBundle bundle =
ResourceBundle.getBundle( this.getBundleByHost() , fCtx.getViewRoot().getLocale());
_name = bundle.getString("name_default");
_entryText = bundle.getString("text_default");
}




FacesContext fCtx = FacesContext.getCurrentInstance();
String host = ((PortletRequest)fCtx.getExternalContext().getRequest()).getServerName();
if (host.contains("localhost"))
return "LocalBundle";
...



2. Refresh (backing) Bean

After submitting some input I asked myself how to refresh the backing bean? After some research I found a LOT of people having the same problem.
That seems pretty funny in the meanwhile to me as I realized now how easy that is. Maybe there are some people like me that didn't get it the first time. ;)

Here is the code:

public void reset(ActionEvent actionEvent) {

this.initBeanData();
}


(For the init method: see above :) )

Then of course you have to call the method as always from the view (here: JSP):

Saturday, May 9, 2009

Portal default languange (spanish)

Short note:

There still seems to be a bug at setting the default language for a specific instance/company.

The known trick (thanks to luca) is to change the entry

"languageId"


in the database table

users_


for the user with the flag

defaultUser = 1


In addition I just learned that for spanish the code "es_ES" does not work - however the code "es" does work.

Maybe it helps somebody.

Friday, May 1, 2009

Error at uploading logo: Caused by: java.io.IOException: Unable to retreive rendered image from input stream with type na

Small update:

Today I tried to use the standard "logo" functionality of liferay (Control Panel-> Communitiey-> manage pages -> settings -> logo)

Strangely I got the following confusing errors after uploading a logo (JPG - created with Adopbe Photoshop):


com.liferay.portal.SystemException: java.io.IOException: Unable to retreive rendered image from input stream with type na
...
Caused by: java.io.IOException: Unable to retreive rendered image from input stream with type na


If I remember correctly I used JPG before (created by GIMP) and it worked. Anyway - I changed the format to GIF and then it worked.

If anybody has a better advice / explanation please let me know. :)

Wednesday, April 29, 2009

Migration to liferay 5.2.2.: ServiceContext, JAVA_HOME, 7cogs, Cannot allocate memory

Migration to 5.2.2 continued:

Ok friends - here are some of the pitfalls I encountered. I hope it helps some of you who read this.

1. JAVA_HOME

Coming from JBoss it was quite a surprise to me to get the good old "JAVA_HOME not defined" error message. So I had to search where to set point it to in my linux (ubuntu 6.06) based virtual private server environment.

Finally I found out that the following path seemed to be a good one:
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun

(Note: The full command to set the parameter is "export JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun" )

2. java.io.IOException: java.io.IOException: Cannot allocate memory

Also an old friend. The main trick was just to lower the memory that java would get.
So I set in the setenv.sh file the following:

JAVA_OPTS="$JAVA_OPTS -Xmx192m -XX:MaxPermSize=128m -Xms128m -Dfile.encoding=UTF8 -Duser.timezone=GMT -Djava.security.auth.login.config=$CATALINA_HOME/conf/jaas.config -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false"
(Note: The little linux command free -m helped a lot identifying the problem)


3. The new ServiceContext approach

Finally after the server started running I realized some errors in my own code (yes - the great JSF portlets :) ) due to simplifications of the liferay API.

Liferay has moved some repetitive context related attributes into an own ServiceContext class

In detail I changed my code from

BlogsEntryLocalServiceUtil.addEntry(liferayUser.getUserId(),
themeDisplay.getPlid(), this.getName(),
this.getEntryText(), now.get(Calendar.MONTH), now
.get(Calendar.DAY_OF_MONTH),
now.get(Calendar.YEAR), now.get(Calendar.HOUR), now
.get(Calendar.MINUTE), false, true, trackbacks,
tags, true, true, themeDisplay);
to the following:

ServiceContext serviceContext = ServiceContextFactory.getInstance(BlogsEntry.class.getName(), req);

BlogsEntryLocalServiceUtil.addEntry(liferayUser.getUserId(), this.getName(), this.getEntryText(),
now.get(Calendar.MONTH), now.get(Calendar.DAY_OF_MONTH), now.get(Calendar.YEAR), now.get(Calendar.HOUR), now.get(Calendar.MINUTE),
false, true, trackbacks, serviceContext);


4. Removal of 7cogs example data

As you might have noticed the new version of liferay comes along with some example data. That is a great idea - especially for beginners. Also it shows the new features of the WOL-portlet. ("World of Liferay" :) )
Unfortunately it is a bit tricky to remove the sample data afterwards. Even after removing the hooks - the data stays in the DB of course. And unfortunately it overwrites your default "instance" (that is your first website / company id)

So what I did is:
  1. Restore my VPS backup :)
  2. Remove the 7cogs folder before the first server start

I hope my migration posts help you. As always: I'm happy about all feedback and follow up questions.

"Migration" from 5.1.0 (JBoss 4.2) to 5.2.2 (Tomcat 5.5) - general steps

Hello everybody,

finally I did it: I managed the "migration" from 5.1.0 to 5.2.2.

As some of you might now the change to 5.2. is quite a major change for liferay.
Funnily the final reason for me to migrate was a quite small change: In 5.2.2. finally Blog-Entries get a HTML Title and a friendly URL. This is quite important from an SEO perspective.
(By the way: Big thanks to the liferay community - I triggered this feature by myself by writing a forum post about it - and it has been implemented quite quickly afterwards!)

Why do I write "Migration" in quotationmarks?
After some bad experiences while trying to migrate from 4.3.5 to 5.1.0 (over 4.4.2) I came up with a new "migration" strategy: I install a fresh new bundle and make the necessary changes in the file system. This seems to work with much less problems to me.

Here are the general steps I use to follow:

Step 1: The new installation

  1. point to database (+ potentially install driver) - now in portal-ext.properties
  2. config mail service - now in portal-ext.properties
  3. configure the start script (for tomcat: setenv.sh)

Step 2: Do the post installation steps

  1. Transport additional webcontent (In my case I had some html and applets in a folder. This needs to go into the ROOT folder)
  2. Finalize the portal-ext.properties file (Normally you have to take everything that is in the _legacy_ properties provided by liferay. This goes especially for authorizations - you can't login if you are migration from an old version due to some algorithm changes)
  3. (optional) In my case I have to change the port to 9080 - so I have to modify the web.xml file of tomcat
  4. provide "authentication"files for google or yahoo webmastertools

Said and done. :)

No honestly: Of course it cost my about two days again - but this time especially due to some tomcat specific things I wasn't used to - and some changes in 5.2.2.
But I will describe this in the next post.

Tuesday, March 3, 2009

Problem: Could not initialize class HibernateUtil / org.slf4j.LoggerFactory not found

Hi all,

after testing the "upgrade" to the long awaited version 5.2.2 (I can describe the procedure as well if you are interested) I got some nasty problems with hibernate.

For the portlet "EasyComments" hibernate3 worked fine so far - but suddenly I got the following errors:

Could not initialize class HibernateUtil
....
at HibernateUtil.closeSession(session);
Annoyingly there was not more to take from the standard out of tomcat (nor from the logs). Only an additional catch blog in the HibernateUtil class showed the real problem:

org.slf4j.LoggerFactory not found

and later:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder"

So it seems that hibernate is using slf4j internally.
Adding the following jars solved the problem:

slf4-api-1.5.6.jar
slf4-simple-1.5.6.jar

The files can be found here:
www.slf4j.org

And finally all worked again.


Saturday, January 31, 2009

By the way: [DriverManagerConnectionProvider:41] Using Hibernate built-in connection pool (not for production use

.... one addition to my last hibernate post:

The main reason why I tried the c3p0 solution first (besides me not being an experienced mysql admin) was the following message in the output of my local Tomcat test-instance:

[DriverManagerConnectionProvider:41] Using Hibernate built-in connection pool (not for production use!)

(See my last post how to configure c3p0 for liferay portlets:

Portlets for liferay portal with java jsf: Meanwhile: Hibernate / mySQL Problems: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes....)