You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Andy Pruitt <ap...@coghillcapital.com> on 2003/10/15 02:14:44 UTC

Patches to allow JBoss deployment

The current portalImpl source goes directly through the file system to
access its configuration files.

When running on an unexploded WAR (such as on JBoss), or on Tomcat with
an Ant deployed war, Pluto will be unlikely to be able to reach these
files directly through the file system.  The right thing to do is to use
the 

ServletContext#getResource method.

I've included some patches that make the switch.  

The biggest impact is on the PortletDefinitionRegistryService; this can
no longer discover portal apps by thumbing through the file system.
Discovering the portal apps is kind of tough because you don't know the
deployment order; the other apps could be already deployed or not yet
deployed when pluto starts.  

The solution I came up with is to add a PortletAppBroadcaster that
allows the Loader to listen for webapp deployments and undeployments.
There is a new servlet, PortletAppDeploymentServlet, that broadcasts the
availability of the portlet app at startup.  It should be added to the
portlet app web.xml as:

    <servlet>
        <servlet-name>PortletDeployment</servlet-name>
        <display-name>PortletDeployment</display-name>
        <description>announces the deployment of a new
PortletApplication</description>
 
<servlet-class>org.apache.pluto.portalImpl.services.portletdefinitionreg
istry.PortletAppDeploymentServlet</servlet-class>
        <load-on-startup>0</load-on-startup>
    </servlet>



The PortletAppBroadcaster will need to stay in the parent classloader,
so will need to either live at the EAR level or go in something like the
Tomcat shared directory.  It also needs to be excluded from the WAR
classloader, most likely by not including it in the portalImpl jar.  A
JNDI based solution might also make sense, but it looks like the Tomcat
JNDI service doesn't support JNDI events, and I'm not so sure that it
would reduce the class loading complexity anyway.

IF YOU WANT TO RUN ON JBOSS-TOMCAT (tested under 3.2.1):
1) Drop these files in your src tree.
2) Build an ear with your application.  Include the Pluto JAR and WAR
files in the EAR, and have the Pluto webapp and your webapp reference
the JARS via the manifest; do not include the Pluto JARS in the
individual wars.  This will force the Pluto classes into the parent
classloader of all WARS.  
3) Deploy to JBoss normally.

I've got some classpath issues right now on JBoss Jetty, but will post
if/when I overcome.