portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Dullaart <marcel.dulla...@gmail.com>
Subject Re: [J2] New PAM/Deployer
Date Thu, 03 Feb 2005 07:00:18 GMT
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), watler@wispertel.net
<watler@wispertel.net> 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: jetspeed-dev-unsubscribe@jakarta.apache.org 
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org 
> 
>

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


Mime
View raw message