Scott: More comments below....
> Scott.... > > Thanks for the feedback. I think I understand the scenario. I take this back. I am not sure how an app can be both unknown to J2 and be the subject of a redeploy event/PAM invocation. Can you elaborate? Is there a deployer bug underlying all of this? > 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. I have added a similar test to this in DeployPortletAppListener. Please review and let me know if it is equivalent from your perspective. Basically, I am claiming that if someone is invoking *PAM.redeploy(), they are expecting an unregister and a subsequent deploy. >> >> 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. Not really. If you drop in an infused app into the container's webapps directory, it will be registered via the JetspeedContainerServlet on init. This is one of the advantages of this approach. >> 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. Again, this confuses me, (sorry I am being so dense here). If an app is simply in the container's webapps directory, as opposed to the jetspeed WEB-INF/deploy directory, how did it ever get involved with the deployer? >> 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. A previously deployed and registered app left in webapps will be registered automatically once by jetspeed on startup and once again by the app itself on JetspeedContainerServlet init. I think this situation is less than optimal since a race condition could surface between these two registration attempts... but I doubt that it is causing you problems at this point since it seems rare. Bottom line is that I do not see how the pam application left in webapps but not in the jetspeed deploy directory is causing problems. Perhaps you have an old version of the pam webapp that was not infused in the webapps directory? Still, that does not explain the redeploy PAM invocation... >> Adding the above logic seemed >> to fix this for me. Like I said above, I echoed this modification in the deployer portlet app listener. Hopefully, this will be an equivalent patch. I'd still like to understand more about your custom deployment so that I can make sure other bugs like this are found. Thanks again Scott... talk to you in the morning. :) Randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
