Hi Randy, I will not be able to test the new PAM/deployer until sunday night. I'll inform you about the results of using it on JBoss 4.0.1 then.
Cheers, Marcel On Wed, 2 Feb 2005 22:54:15 -0700 (MST), [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
