期望 Java Portal Server 托管“标准”是否有效？ Java Web 应用程序？
有人建议这可能是一种合理的方法，以便最大限度地减少对现有服务器配置的更改，但它实际上有效/受支持吗？ 无论哪种方式我都找不到任何具体的东西。
实际上，使用 JBoss Portal V2.4.2 服务器时，似乎存在一些类加载问题，因此可下载的 Stripes 示例或标准 Wicket 快速入门应用程序等内容无法运行，但我不确定问题是否存在有特定于服务器的还是通用的 - 有人吗？
注意：这并不是将现有的 Web 应用程序显示/移动到门户中，只是门户服务器是否也应该是有效的应用程序服务器？
It's been suggested that this might be a reasonable approach, in order to minimize changes to an existing server configurations, but is it actually valid/supported? I've not been able to find anything specific either way.
In practice, with a JBoss Portal V2.4.2 server, there appears to be some class-loading issues, so things such as the downloadable Stripes example or a standard Wicket quickstart app don't run, but I'm not sure if the problem there is a server-specific one or a generic one - Anyone?
Note: This isn't about displaying/moving an existing web-app into a portal, simply if a Portal Server should also be a valid AppServer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
JSR 286 (Portlet 2.0) 规范：
因此，期望标准应用程序服务器应用程序在门户下工作并不是没有道理的。
然而，根据定义，门户将在全球类空间中包含更多的库。 向容器添加库总是会带来不兼容的风险，并且需要管理向应用程序公开哪些类/资源以及如何公开（应用程序优先的类加载等）。 我过去曾遇到过第三方库的问题，这些库的依赖项与门户附带的版本冲突。 我不希望依赖管理变得更容易。
正如他们所说，一次编写，到处测试。
JSR 286 (Portlet 2.0) spec:
It is therefore not unreasonable to expect standard app-server applications to work under a portal.
However, by definition, a portal is going to include more libraries in the global class space. Adding libraries to the container always introduces the risk of incompatibility and the need to manage what classes/resources are exposed to your application and how (application-first class-loading, etcetera). I've had problems in the past with third part libraries whose dependencies conflicted with a version that shipped with the portal. I wouldn't expect dependency management to get any easier.
Write once, test everywhere, as they say.
根据我的经验，这是一个有效的建议。 Portlet 应用程序通常也是 Web 应用程序（例如，它们可能包含一个 servlet，以允许通过在其中一个 portlet 中呈现的链接来访问应用程序逻辑），因此它们包含 portlet.xml 和 web.xml，并且需要 j2ee 类和 jsr168类。 WSRP 标准还包含资源链接类型，该类型应该代表远程服务器的普通应用程序服务器。
Websphere 门户服务器也是一个应用程序服务器。
From my experience that is a valid suggestion. Portlet Apps are often also Webapps (they might contain a servlet for example to allow access to application logic also by links to be rendered in one of the portlets), so they contain both portlet.xml and web.xml and need j2ee classes and jsr168 classes. The WSRP standard also contains resource link type with is supposed to represent a normal appserver for the remote server.
Websphere portal server is also an app server.
我使用 JBoss Portal、BEA WebLogic Portal 和 Apache Jetspeed 2 在单个 Web 应用程序中混合了 servlet 和 portlet。
但是，将 servlet 转换为 portlet 可能很困难。 使用诸如 Portals Bridges 之类的桥接技术确实存在，但我很幸运能够避免这样做转换，除了玩教程之外没有直接的经验。
I have mixed servlets and portlets in a single web application using JBoss Portal, BEA WebLogic Portal and Apache Jetspeed 2.
However, converting a servlet to a portlet can be difficult. Using bridging technology such as Portals Bridges do exist but I have been lucky enough to avoid having to do such a conversion and have no direct experience other than playing with the tutorials.
即使应用程序包含 portlet，也没有说明您需要在页面上的某处公开该 portlet。 如果您编写这样的应用程序，只需编写任意数量的 servlet，直接链接到它们，而不是在任何页面的任何位置放置任何虚拟/默认 portlet。
我编写了一个符合 JSR-168 的应用程序，其中包含一个空 portlet 和一个用于检索一些 XML 股票价格数据的 servlet。 几个月来，所有被调用的都是 servlet，该 portlet 在站点的任何地方都看不到。 后来我添加了一个 portlet，它提供了来自 XML feed 的一些附加数据。
Even if the application contains a portlet, nothing says you need to expose that portlet on a page somewhere. If you write such an application, simply author as many servlets as you wish, link to them directly and not place any dummy/default portlet on any page anywhere.
I wrote a JSR-168 compliant app with an empty portlet and a servlet that was used to retrieve some XML stock price data. For several months all that was ever invoked was the servlet, the portlet was never visible anywhere on the site. Later I added a portlet which provided some additional data from the XML feed.
答案是，是的，它是有效的，但是特定的 JBoss Portal V2.4.* 版本似乎存在类加载器问题，因此只有更基本的 Web 应用程序才能正确运行。
The answer is that yes, it is valid, but the specific JBoss Portal V2.4.* versions appear to have class-loader issues such that only the more basic web-apps will run correctly.
我认为问题在于标准 Web 应用程序是否可以从 Portlet 容器呈现为 Portlet。 这不可能。 Portlet 需要基于 GenericPortlet 类并具有特殊的部署描述符。 JSR-168 标准指定了门户的要求。 JSR-286 规范正在制定中。
您唯一能做的就是创建一个 portlet，通过 iframe 为您现有的应用程序提供服务，但这当然是丑陋的。
有一本关于 portlet 的免费书籍，名为“Portlet 和 Apache Portals”，它可能很有用。 另请参阅规范。 这个博客站点很有趣。
I assume that the question has to do whether a standard web application can be rendered as a portlet from a Portlet container. This is not possible. The portlets need to be based on the GenericPortlet class and have special deployment descriptors. There is the JSR-168 standard, which specifies the requirements for the portal. The JSR-286 specification is on the way.
The only thing you could do is to create a portlet that will serve your existing application through an iframe, but this is of course ugly.
There is a free book for portlets called "Portlets and Apache Portals", which could be useful. Consult also the specification. This blog spot is interesting.