Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4202390F.40803@binary-designs.net>
Date: Thu, 03 Feb 2005 09:45:35 -0500
From: "Scott T. Weaver" <scotts-jetspeed-list@binary-designs.net>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
MIME-Version: 1.0
To: Jetspeed Developers List <jetspeed-dev@jakarta.apache.org>
Subject: Re: [J2] New PAM/Deployer
References: <420144E0.4030100@wispertel.net>
    <42014B2F.70509@binary-designs.net> <4201513A.8070305@wispertel.net>
 <34117.38.116.134.159.1107410055.squirrel@secure.wispertel.net>
In-Reply-To: <34117.38.116.134.159.1107410055.squirrel@secure.wispertel.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

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
>
>
>
>  
>


-- 
"Great minds discuss ideas. Average minds discuss events. Small minds discuss people."  - Admiral Hyman Rickover

*******************************************
*           Scott T. Weaver               *
*         <weaver@apache.org>             *
*     <http://www.einnovation.com>        *
* --------------------------------------  *
*   Apache Jetspeed Enterprise Portal     *
*     Apache Pluto Portlet Container      *
*                                         *
* OpenEdit, Website Content Management    *
*     <http://www.openedit.org>           *
*******************************************


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