This implementation, (WarInfusionPAM), eliminates the requirement to have the Tomcat manager web application in place and all of the associated configuration options. Instead, this PAM places WAR files, (or expanded webapp directories and context.xml file sin the case of Tomcat4), in the container target webapps directory. The assumption is that the container will support "auto", "live" or "hot" deployment of some sort. When the portlet application webapp is loaded, it uses the JetspeedContainerServlet.init() invocation to register the portlet application in the webapp with the PAM implementation. Hopefully, there will no longer be a need to specialize deployment implementations per container.
I have left the preexisting deployer option in place, (ApplicationServerPAM), so you should be able to roll back the PAM implementation if you run into problems. You will need to comment out the WarInfusionPAM bean and uncomment the ApplicationServerPAM and TomcatManager bean entries.
There is one option that can be set in the spring configuration of WarInfusionPAM to control whether the PAM interacts with the webapps directory using expanded webapps directories or with war files. By default, it uses expanded webapps if a context.xml file is found in the webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the boolean field value in jetspeed-spring.xml forces the selected mode.
At the moment, there is a problem with undeploy/redeploy on Windows platforms. I believe this is due to file read locks on the WEB-INF/lib jar files, possibly others. I am currently working on a solution and/or workaround for this problem.
Randy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
