[PLUTO-511] Separate Pluto implementation from required interfaces in shared class loader

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0-refactoring, 2.0.0
• Fix Version/s: 2.0-refactoring, 2.0.0
• Component/s: portlet container
• Assignee: David Sean Taylor
• Reporter: David Sean Taylor
• Created: 15/Oct/08 23:44
• Updated: 23/Oct/08 00:00
• Resolved: 23/Oct/08 00:00

Description

Having the Pluto implementation in the shared class loader was causing collisions with web application references of supporting jar files in common with Pluto's implementation. These kind of errors can often be very difficult for end users to track down. As good citizens in a web application, we are following the pattern we used in Jetspeed by only putting standards jars and APIs in the shared area. For example, On Tomcat 5.5, this is the $TOMCAT_HOME/shared/lib directory. The refactoring accomplishes this by separating the Pluto implementation from required interfaces in shared class loader, and moving the container implementation and all dependency jars into the Pluto class loader.

In the process of fixing this issue, further improvements to the build to simplify Pluto usage:

• combine the 2 descriptor jars all into the pluto-container-impl to decrease the number of jars required to use the Pluto implementation. See https://issues.apache.org/jira/browse/PLUTO-509 for related work.
• use service interfaces to access all aspects of the Container
• move Pluto's servlet entry point, PortletServlet into the API jar, as it is required to be placed in the shared area (note this servlet is ignored by Jetspeed)

Two jars required in shared: pluto-container-api, pluto-taglib (although this could be placed in a web app as well)
For typical portals (not Pluto driver), one jar required in portal implementation: pluto-container

Issue Links

• blocks: PLUTO-481 Pluto 2.0 Refactoring Initiative