Separate Pluto implementation from required interfaces in shared class loader
-----------------------------------------------------------------------------
Key: PLUTO-511
URL: https://issues.apache.org/jira/browse/PLUTO-511
Project: Pluto
Issue Type: Bug
Components: portlet container
Affects Versions: 2.0.0, 2.0-refactoring
Reporter: David Sean Taylor
Assignee: David Sean Taylor
Fix For: 2.0.0, 2.0-refactoring
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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
