在谷歌应用引擎上像冥王星或jetspeed一样的Portlet容器？

我正在尝试在谷歌应用引擎上构建一些“portlet服务器”。 （作为开源）

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

有没有人试图运行jetspeed或在谷歌应用引擎内部使用pluto的应用程序？

基于我目前对portlet和谷歌应用程序引擎的了解，我预计会出现以下问题：

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

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

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

在这里有人对portlet和app引擎的组合有任何经验吗？

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

Answer 1

我简要地看了一下 – 你最大的问题是Portlet规范建立在但是过度使用了servlet规范的一些关键部分 – 特别是它通常需要支持跨上下文调用。

虽然可以设计一个包含多个portlet和servlet容器的Web应用程序（通常用于管理portlet，或者在Liferay的情况下，它们的堆栈大部分都是这样），但这并不容易。

实际上，如果考虑在AppEngine上做门户类型的东西，我会更密切地关注托管OpenSocial小部件（如果你真的想要标准），可能在Shindig中运行，或者在外部托管。 这也可以使您获得JSR-168兼容性，因为有许多（不是很好的）桥接小部件来托管小部件，并且它不是一个硬编写的适配器。