谷歌应用程序引擎上有像 pluto 或 jetspeed 这样的 Portlet 容器吗?

发布于 2024-08-27 22:16:42 字数 738 浏览 10 评论 0原文

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

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

有没有人尝试过运行 jetspeed 或内部使用 pluto 的应用程序 在谷歌应用程序引擎上?

根据我目前对 portlet 和 google 应用程序引擎的了解,我 预见到这些问题:

从部署的角度来看,包含 portlet 的 war 文件或多或少是一个 完整的网络应用程序(是的,我知道如果没有门户它就无法真正工作 服务器)。 war 文件可能包含它自己的 web.xml 等。 这使得在应用程序引擎上的部署相当困难,因为应用程序是 彼此不可见,因此所有包含档案的 portlet 都需要 包含在已部署的“基于应用程序引擎的门户服务器”的 war 文件中。

“portlet”(至少在 liferay 中)作为永久 servlet 启动 进程,基于位于同一位置的 portlet.xml 和 web.xml 加载的每个 portlet 存档。我认为这可能是有问题的 应用程序引擎,因为一切都在一个大的“网络应用程序”中,所以可能很难 访问每个存档中的 portlet.xml。

在我看来,这阻碍了 100% 的兼容性。

这里是否有人对 portlet 和 portlet 的组合有任何经验? 应用程序引擎?

您认为修改 jetspeed、pluto 或任何其他 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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

恬淡成诗 2024-09-03 22:16:42

我简要地研究过它 - 最大的问题是 Portlet 规范建立在 servlet 规范的基础上,但覆盖了 servlet 规范的一些关键位 - 具体来说,它通常需要支持跨上下文调用。

虽然可以设计一个包含多个 portlet 和 servlet 容器的单个 Web 应用程序(通常是为管理 portlet 完成的,或者在 Liferay 的情况下是其堆栈的大部分),但这并不容易。

事实上,如果考虑在 AppEngine 上做门户类型的事情,我会更仔细地考虑托管 OpenSocial 小部件(如果您确实想要标准),也许在 Shindig 中运行,或者在外部托管。这还可以让您获得 JSR-168 兼容性,因为有许多(不是很好的)桥接 portlet 来托管小部件,并且它不是一个很难编写的适配器。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文