Scott....
Thanks for the feedback. I think I understand the scenario. Let me look at it for a bit here... I am wondering why we are in the redeploy() case at all if the application was not previously known to J2? Initially, this seems like a deployer issue to me rather than a PAM shortcoming.
Randy
Scott T. Weaver wrote:
Seems to be working for me. However, I had to modify the redploy() method in FilSystemPAM as such:
// It might be the case were things have become unsynchronized and the target app for redploy
// actully needs the full deploy treatment. if (registry.namedPortletApplicationExists(paWar.getPortletApplicationName()))
{
doUnregister(paWar.getPortletApplicationName(), false);
String paName = paWar.getPortletApplicationName();
DirectoryHelper deployedDir = new DirectoryHelper(new File(webAppsDir + "/" + paName));
PortletApplicationWar existingWar = new PortletApplicationWar(deployedDir, paName, "/" + paName);
existingWar.removeWar(); existingWar.close(); sysDeploy(paWar, DEPLOY_WAR); } else { deploy(paWar); }
reason being that it appears that if an app is deployed in the app server but not in jetspeed, the app is never registered to jetspeed. I added a simple check that if we were trying to redeploy an app that exists in the container but not in jetspeed we just do a full deploy instead.
Does this make sense? I was having issues redploying my custom portal that uses the "pam" app for the LocaleSelector however, the deployment of the portal DOES NOT remove the pam app from tomcat, hence the issue I have outlined above rearing its head. Adding the above logic seemed to fix this for me.
Randy Watler wrote:
I have committed a new PAM/deployer implementation that uses the deploy-tool component to infuse portlet application war files for J2. This is being done in an attempt to simplify the deployment process and make it more reliable. Please bear with me on this change... I need feedback from all of you on how the new approach fairs in your environment.
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
