This statement nailed!
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...
The app in question was deployed prior to the new portlet
self-registration logic you added to the container servlet hence it
never tried to register itself. Thanks for your insight Randy.
[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]
--
"Great minds discuss ideas. Average minds discuss events. Small minds discuss
people." - Admiral Hyman Rickover
*******************************************
* Scott T. Weaver *
* <[EMAIL PROTECTED]> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEdit, Website Content Management *
* <http://www.openedit.org> *
*******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
