Portlet container like pluto or jetspeed on google app engine?

Question

I am trying to build something "portlet server"-ish on the google app engine. (as open source)

I'd like to use the JSR168/286 standards, but I think that the restrictions of the app engine will make it somewhere between tricky and impossible.

Has anyone tried to run jetspeed or an application that uses pluto internally on the google app engine?

Based on my current knowledge of portlets and the google app engine I'm anticipating these problems:

A war file with portlets is from the deployment standpoint more or less a complete webapp (yes, I know that it doesn't really work without a portal server). The war file may contain it's own web.xml etc. This makes deployment on the app engine rather difficult, because the apps are not visible to each other, so all portlet containing archives need to be included in the war file of the deployed "app engine based portal server".

The "portlets" are (at least in liferay) started as permanent servlet processes, based on their portlet.xmls and web.xmls which is located in the same spot for every portlet archive that is loaded. I think this may be problematic in the app engine, because everything is in one big "web app", so it may be tricky to access the portlet.xmls from each archive.

This prevents a 100% compatibility in my opinion.

Is here anyone who has any experience with the combination of portlets and the app engine?

Do you think it's feasible to modify jetspeed, pluto or any other portlet container to be able to run it on the app engine?

Skipbomb

Answer 1

I've looked at it briefly - your biggest problem is that the Portlet spec builds on but over-rides some key bits of the servlet spec - specifically it typically requires support for cross-context calls.

While it is possible to engineer a single web-app that contains multiple portlets and the servlet container (often done for admin portlets, or in Liferay's case much of their stack) it's not easy.

In reality, if looking at doing portal type stuff on AppEngine, I'd look much more closely at hosting OpenSocial widgets (if you really want standards), perhaps running in Shindig, or hosted externally. This can also get you JSR-168 compatibility, as there's a number of (not great) bridge portlets to host widgets, and it's not a hard adaptor to write.

Luau

I share your concerns regarding the problems with the portlet spec. Currently I am thinking about defining my own "gloudlet" spec for modules that run inside my container. I'm going to design it similar to JSR286 but within the boundaries of the app engine constraints. BTW: If people want to help me exploring and building of the standard/framework/tools: code.google.com/p/gloudy is the project that I have started for it. – Skipbomb

Honestly, I'm not sure that's a useful level of abstraction. The portlet spec IMHO represents an architectural dead-end (ironic considering how much portal/portlet work I've done). I think client-side compositing is the way that entire spec will go, with SSO-like shared application sessions & attribute-based authentication filling in all of the other interesting aspects of what portlets do. I would seriously consider incorporation of widgets (either standardized, or just simple) over trying to evolve another modular HTML snippet architecture. – Luau

What do you mean with "client side composition"? AJAX based fetching of widgets? But where would you get the definition of a "page" from? I am trying to build the framework for building complete sites. I don't think that widgets would do the trick here. – Skipbomb

The portlet spec goes a lot further than just page - it's a @pretty set lifecycle. I'd probably either use JSP or velocity to bootstrap my view, or if you want end-user customization prob store a JSON TREE REPRESENTING LAYOUT – Luau