像谷歌应用程序引擎上的pluto或jetspeed portlet容器？ [英] Portlet container like pluto or jetspeed on google app engine?

问题描述

我试图在Google应用引擎上构建一些portlet server。
（作为开源代码）

我想使用JSR168 / 286标准，但我认为应用引擎的
限制将会使它处于棘手和不可能的状态之间。

有没有人试图运行jetspeed或者在Google app引擎中使用pluto内部
的应用程序？

根据我目前对portlet和谷歌应用程序引擎的了解，我是
预计这些问题的：

带有portlet的war文件从部署的角度来看或多或少是一个
完整的webapp（是的，我知道，如果没有门户
服务器，它并不能正常工作）。 war文件可能包含它自己的web.xml等。
这使得应用程序引擎上的部署变得相当困难，因为应用程序是
，彼此不可见，所以包含归档文件的所有portlet都需要为
包含在部署的基于应用引擎的门户服务器的war文件中。
$ b

portlets（至少在liferay中）作为永久servlet
进程，基于它们的portlet.xmls和web.xmls，它们位于相同位置，用于
加载的每个portlet归档。我认为这可能在
应用程序引擎中存在问题，因为所有内容都位于一个大的Web应用程序中，所以从
从每个存档中访问portlet.xmls可能会非常棘手。

在我看来，这可以防止100％的兼容性。

在这里，任何对Portlet和
app引擎？

您认为修改jetspeed，pluto或任何其他portlet容器以便能够在应用引擎上运行
它是可行的？

解决方案

我已经简要地看了一下 - 您最大的问题是Portlet规范是建立在某种关键servlet规范中的各个位 - 特别是它通常需要支持跨上下文调用。

尽管可以设计一个包含多个portlet和servlet的web应用程序容器（通常是为管理portlet完成的，或者在Liferay的大部分堆栈中），这并不容易。

实际上，如果在AppEngine上查看门户类型的东西，我会更加关注托管OpenSocial小部件（如果您确实需要标准），可能在Shindig中运行，或者在外部托管。这也可以让你获得JSR-168的兼容性，因为有很多（不是很好的）桥接portlet来托管窗口小部件，并且它不是一个很难写入的适配器。

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?

解决方案

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.

这篇关于像谷歌应用程序引擎上的pluto或jetspeed portlet容器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！