portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wat...@wispertel.net
Subject Re: [J2] New PAM/Deployer
Date Thu, 03 Feb 2005 05:54:15 GMT

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. :)


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message