Recently in tips and tricks Category

After my "Pluggable mobile device detection" presentation during Liferay Europe Symposium a lot of people asked about the mobile device emulator I was using. The truth is, it's not a real "emulator" but a simple combination of html page and a Firefox user script. However, it does the trick and for most people seems to be good enough (at least for a start). So, I made a promise to share it and finally found the time to blog about it.

One of the problems with GWT (which is even more noticeable in portal environment) is preserving it's state between page reloads. In a GWT-only application (or single portlet on the page case) one can give user no other option but using only GWT controls to practically avoid page reloads. In most cases however this is not really possible nor wise thing to do. In portlet environments in particular, reloading the page is a very commmon thing to do, giving all portlets a chance to refresh their content after some action has taken place. The thing is, GWT portlets will, by default, render their initial state, which may not be what user expects.      

For example, consider the GWT Chatroom portlet I was using in my previous posts Liferay GWT portlet - how to make it "instanceable" and use GWT RPC and Liferay GWT portlet - replacing GWT-RPC with JSON. Imagine user has entered a chatroom. Then she clicks on some other portlet on the page. The page is reloaded and Chatroom portlet returns to it's initial state. The user will have to enter the room again every time she clicks on another portlet. Let's see how this can be fixed.

Every once in a while somebody asks about writing Liferay portlets in GWT. It seems a lot of people are successfully using GWT with Liferay but surprisingly I couldn't find any complete tutorial on the subject. There are a of course tutorials explaining the basics but what they concentrate on, is how to build single-instance and client-side-only portlets. This is good enough to get you started but chances are sooner or later you'll need to place two instances of the same GWT portlet on the same page and/or implement GWT RPC to make use of the Liferay services.

I've reached that point myself sometime ago and unfortunately had to solve the problem myself. Then I wrote sample portlet called gwt-chatrooms-portlet to demonstrate the solution and hopefully save you some time. So here is a step by step tutorial how to create GWT portlet for Liferay 6.0.5 which:

• allows many instances to be placed on the same page
• uses GWT RPC for client-server communication

I guess every Java developer dealing with JAVA/XML serialization/deserialization knows about XStream. I was using it for years until yesterday. What happened yesterday? I found out XStream dos not work out of the box with GAE. Well is's not exactly XStream's fault. A lot of stuff does not work properly with GAE due to its limitations and odd security restrictions. But my hope to quickly find patch/workaround, went away as soon as I realized the problem was reported to XStream over an year ago (http://jira.codehaus.org/browse/XSTR-566) and there is still no good solution. 

This way I was forced to look for alternatives. And I found Simple! Conceptually it's a very similar to XStream. Serialization is really simple to use and revolves around several annotations and a single persister object. I got the impression it's noticeably faster than XStream. It's feature list is quite long (it even claims to be bean version tolerant) but so far I've used the standard stuff like converters, transformers, persister, etc.

However since "Simple"

• does not depend on 3rd party libraries
• is available in central Maven repository
• works out of the box with GAE
• is capable of doing everything XStream is doing  

it's about to become my number one XML serialization/deserialization tool. At least until I discover it's dark sides.

Don't know about you but I can't imagine debugging enterprise class applications without having "tail -f /path/to/log.file" running in dedicated console window. During development and testing phases (assuming work is done "in house") there is usually no problem with this approach as the whole team have access to servers' log files. This is not always the case with staging and production environments though. These days a lot of companies execute strong security policies which sometimes means that application is only accessible via HTTP. In such case, depending on how you SLA looks like, "log files provided on demand via e-mail or FTP" may not be an option. 

Facing this kind of problem in recent Liferay based project, made me think about creating a portlet capable of displaying log files. Something like WWW based version of "tail -f". This is how Tailgate was born (for those of you looking for solution here is download page). The rest of this post will concentrate on explaining why it was not "a max 2h of coding" as I thought in the begging.

What would you do if a customer demands to "integrate" his Liferay based corporate portal with Google Analytics, Geminus, ClickTale, Crazy Egg,  and whole bunch of other analytics tools available out there?

As you probably know, such services typically provide some piece of javascript (code or file) which needs to be added to every page of monitored web site. Each service also provides unique customer code/key (which is either already part of the javascript provided or needs to be placed in specific place). Regardless of whether using all of them at the same time is a smart thing to do, there are a few technical problems to solve:

• How to add custom code to every portal page
• How to deal with unique codes/keys through development, testing, staging, production phases
• How to minimize the impact of changing/removing custom code in production environment

It seems to get more and more cloudy in the IT world these days . It's a matter of time before the rain (of applications) starts. When this happen one will need the proper tools, to be able to add his/hers own few drops.

So I though it's about time to start experimenting with Google Web Toolkit. What I like the most about GWT is it's "hosted mode". The fact that Java code changes reflect the GUI right away and one don't have to wait for generate, compile, build, deploy, ... steps to complete is really speeding up the development process.

Since 99% of my projects use Maven the first thing to look for (after reading GWT tutorials) was a GWT maven plug-in. No surprise here - there is one (http://mojo.codehaus.org/gwt-maven-plugin). The GWT docs and gwt-maven-plugin docs gives a lot of information how to create and build GWT applications.  Unfortunately the released version of  gwt-maven-plugin (1.0 at the time of writing) does not support hosted mode.

If an ATG based web application is available under few subdomains (domain.com, www.domain.com, shop.domain.com) keeping track of session cookies across subdomains may be a challenge. Session tracking cookies (like jsessionid) usually do not have domain property set, which means they are sent back to exactly the same host they came from. So if visitors switch to another subdomain while navigating through the application they would most likely end up having a new session. Depending on what information session holds, the number of visitors and how many simultaneous sessions the server can handle, this may or may not be a problem.

Welcome to my new blog powered by Movable Type. Finally got it up and running but it took me a few hours. Cutting the long story short, here is a note of what problems I had and how they were solved.

Some time ago a set of files ware committed to CVS repository and tagged (lets say with TAG1) . These files have changed a few times since then. Today I needed to tag the latest versions of all files that have ever been tagged TAG1 with TAG2.