Running Liferay 6.2 on Raspberry Pi 2

Liferay Pi2After developing Social Apps Proxy for the Java based Liferay platform just over a year ago, I have been looking for an inexpensive way to host a demo environment. I found the Raspberry Pi2 at £25 was ideal for this, so I will share my experience in configuring this. The general opinion of the web seems to be that the Pi2 and its 1GB RAM in particular is simply too under resourced to run Liferay, but these posts were often made before the release of Java 8 for ARM processors which makes a huge difference, especially when combined with ZRAM which I will cover later. I have Apache2, Liferay Portal 6.2 and MySQL 5.6 all running smoothly on a single Pi2 with about 200-300MB RAM free!

You are probably wondering what kind of performance to expect…

Liferay starts up in just under 10 minutes, and after a page has been requested at least once, it is served in about 1 second. That’s without any Apache / CDN type optimisation. Not bad I think!

I will explain all necessary steps to get Liferay running, but I will cover the Apache2 installation & configuration in a future post focussed on preparing a Liferay Pi2 stack for Internet facing applications.

All Linux commands are explained so no need to have prior Linux knowledge.

Continue reading

Social Apps Proxy – Winning app in the Liferay Marketplace App Contest

MPAC-Winner-Badge-White-2Last month I entered and won this year’s Liferay Marketplace apps contest with my latest Liferay Portal app! There were some really good entries and it must have been a tough contest to call. Social Apps Proxy was my entry. It’s an app for drastically simplifying the building of other Liferay Portal apps that need to integrate with the social graph of its users. For example it can be used to retrieve recent mentions of the user on Twitter. That’s about 10 lines of code to achieve, and the full source code for this can be found here.

Social Apps proxy can be downloaded here.

Social Apps Proxy - Now available

Social Apps Proxy – Now available

James Falkner (Liferay community manager) wrote a good blog on the contest results.

In reality I started building the app some time before the contest was announced, because I wanted to combine my knowledge of a few different technologies that I had been working with in recent years. Namely XForms 1.1, OAuth 1.0a, and all things Liferay Portal!

The link to XForms 1.1 may seem obscure, but it was possibly my experience with XForms 1.1 that triggered the idea to build the app in the first place. XForms 1.1 has no native support for consuming OAuth services or parsing JSON data commonly returned by such services. It is however a superb framework for rapidly building complex forms using its model driven approach and excellent support for consuming HTTP services. So the idea was to create a HTTP proxy server which would do all the OAuth and JSON parsing (transforming it to XML) stuff on its behalf without it even being aware! Liferay Portal’s plug-able architecture provided a great opportunity to put a face on the proxy server for easy configuration and deployment. And from a user experience perspective, allowing users to managing their OAuth tokens for a whole website (web domain) hosted on Liferay Portal instead of using something specifically put together for an individual form (or portlet) is going to be more aligned with the user’s expectations of OAuth itself.

Integrating XForms with Liferay Portal is not something I will go into detail with, but Orbeon Forms is the XForms 1.1 implementation I am most familiar with and it comes with out of the box Liferay Portal integration. I’m sure other XForms implementations can also be integrated quite easily and Social Apps Proxy will work with those too!

So does that mean that Social Apps Proxy requires a XForms 1.1 implementation to be useful? Not at all. Any kind of app that can be deployed as a portlet to Liferay Portal can use Social Apps Proxy. Once installed, all portlets will automatically receive a special token as a render request attribute which indirectly links the app to all of the user’s OAuth tokens. Using the special token the app can request any OAuth resource as if it requires no OAuth token. Whenever this requires user authorisation the Social Apps Proxy will provide a special HTTP response with an authorisation URL which the portlet should simply send the user to.

So what’s next?

I’m going to be at a few upcoming Liferay conferences; The North America Symposium, London Solutions Forum, and the DevCon in Germany. It would be great to discuss how Social Apps Proxy could be improved so if you’re going to be at any of those events then great. Or you can simply leave a comment, it would be great to hear from you either way!


Upcoming Liferay meetup in Exeter on 24th June

In recent years I’ve really enjoyed being part of the Liferay Portal open source community. For some time I have felt I should contribute something back beyond proving assistance to other members via message boards and such. For me, in order to participate offiline I have had to do a fair bit of travelling to London, Bristol, Worcestershire, Stockholm and Wiesbaden (Germany). I have enjoyed every meetup, but part of me wishes there was more of a community here in the South West of UK. To hopefully help build this I’ve organised a meetup in Exeter with talks that should be of interest to those with little or no exposure to Liferay Portal as well as the seasoned expert.

You can RSVP for the meetup here. If you intend to come, it is important you RSVP so I can ensure there is enough food and freebies (!) to go around.

To give you a heads up…

Continue reading

Tip: Removing namespaces from XML elements using XMLBeans

I’m a big fan of Apache XMLBeans as it makes parsing, analysing and creating XML documents valid to XML Schemas incredibly easy. A really nice feature of XMLBeans is auto-typing. You can ask it to parse an arbitrary XML document and it will detect if the structure of the XML validates against a XML Schema that has been made known to it. If it does, then an appropriate subclass of the XMLBeans base class (XmlObject, similar in concept to java.lang.Object) is returned by the parser. The subclass allows you to traverse the document as if it is simply a collection of Java beans. Nice!
Continue reading

The Portal Challenge: Integrating software developed in isolation

I have a strong interest in developing approaches where software is not only developed in a modular way, but also in a way where each module can be mashed up with other modules from other software that was developed in isolation. This interest was first sparked when I encountered the JSR286 Java Portlet specification for portals a few years ago. Portlets are a good candidate for software modules, though in order for them to become this, they need to communicate. JSR286 brought more standardised IPC (Inter-Portlet Communication) to the Java portal world, though it did not go all the way. I feel I have achieved some nice composite applications with reusable portlets by creating strategies on top of the events publishing & processing framework that JSR286 IPC brought. This approach is working well whenever a small team is developing all the portlets, but becomes more challenging when integrating portlets developed by other teams in isolation. By integrating I mean without writing code. This is where I feel the problem with JSR286 IPC resides and it is a major problem in a world where app stores are king and mashups are gaining popularity.

In 2010 I posted in this topic (Achieving a federated single view of the customer) and it remains a challenge. I still feel this is a good approach, but it does require a bit of code to be written for each integration. Can we do better?

Continue reading