Enhancing Liferay to make it work on Google App Engine

[Hagen Kuehn, geändert vor 11 Jahren.]

For my upcoming web application project I would like to use Liferay as CMS platform but on the other hand I also would like to take advantage of Google App Engine and Google Apps. Unfortunately, Liferay 6.1 will not work on Google App Engine since it currently requires unfettered file system access. However since Liferay is a very mature product, I'm currently pondering if I should use Liferay and go the extra mile to modify the respective sections of the code, so that files are stored in Google Blobstore instead. Possibly I would approach this in a similar way as this was done with GaeVFS to provide a portability layer that makes Liferay work on either a file system or within Google App Engine.

As I currently have no clue how much work this may involve, I'm thus wondering if you;

1. Can list/ point out the sections of the code/ modules where file access occurs, to "non-deployment" files. Basically all files which are not part of the *.war container.
2. Would it be appropriate to make those changes with EXT or is it even possible to implement some of those enhancement by using Hooks?

[Aad Nales, geändert vor 11 Jahren.]

Hi Hagen,

Did you get anybody to answer this question.

cheers,
Aad

[Hagen Kuehn, geändert vor 11 Jahren.]

Hi Aad,

Unfortunately I haven't received any response, apart from yours. :-(
As I haven't received any feedback I still have no clue how much work such change might imply. Especially when I need to investigate and reverse engineer all myself.

In the light of this, I will start using Liferay on Amazon's Elastic Beanstalk. This allows me to get started quicker. Over time I might then gain enough Liferay insight so that I could make Liferay deployable on Google App Engine.

Regards,
Hagen

[James Falkner, geändert vor 11 Jahren.]

Hagen Kuehn:

For my upcoming web application project I would like to use Liferay as CMS platform but on the other hand I also would like to take advantage of Google App Engine and Google Apps. Unfortunately, Liferay 6.1 will not work on Google App Engine since it currently requires unfettered file system access. However since Liferay is a very mature product, I'm currently pondering if I should use Liferay and go the extra mile to modify the respective sections of the code, so that files are stored in Google Blobstore instead. Possibly I would approach this in a similar way as this was done with GaeVFS to provide a portability layer that makes Liferay work on either a file system or within Google App Engine.

As I currently have no clue how much work this may involve, I'm thus wondering if you;

1. Can list/ point out the sections of the code/ modules where file access occurs, to "non-deployment" files. Basically all files which are not part of the *.war container.
2. Would it be appropriate to make those changes with EXT or is it even possible to implement some of those enhancement by using Hooks?

Liferay can be made to not depend on any permanent filesystem at all, with some configuration changes. We went through this exercise with CloudBees (see their blog entry). I say "permanent" because Liferay does need a "home" directory where it uses Java's ability to access local filesystems (e.g. java.io.File and friends).

Ray Auge has thought about the usefulness of implementing some sort of vfs layer in Liferay - and Google Blogstore sounds like it might fit the bill!

But barring that, you would need to at a minimum look at these areas for filesystem access:

• Liferay DB (this defaults to using HSQL - and depends on filesystem, but can be easily reconfigured to use a different, external, non-filesystem DB )
• Lucene (you can configure Lucene to use a DB instead of the filesystem for its index, but that would kill performance. You can also configure it to use in-memory index which is lost on shutdown, but avoids filesystem access).
• Jackrabbit (this can also be configured to use a DB instead of the filesystem, see the docs)
• Document Library (this can also be configured to use a DB instead of the filesystem)
• disable auto-deploy (this depends on access to the filesystem)

There may be others but I think those are the main ones.