portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: [J2] New PAM/Deployer
Date Wed, 02 Feb 2005 22:16:26 GMT

Thanks for the feedback. I think I understand the scenario. 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.


Scott T. Weaver wrote:

> Seems to be working for me.  However, I had to modify the redploy() 
> method in FilSystemPAM as such:
>            // It might be the case were things have become 
> unsynchronized and the target app for redploy
>            // actully needs the full deploy treatment.            if 
> (registry.namedPortletApplicationExists(paWar.getPortletApplicationName())) 
>            {
>                doUnregister(paWar.getPortletApplicationName(), false);
>                String paName = paWar.getPortletApplicationName();
>                DirectoryHelper deployedDir = new DirectoryHelper(new 
> File(webAppsDir + "/" + paName));
>                PortletApplicationWar existingWar = new 
> PortletApplicationWar(deployedDir, paName, "/" + paName);
>                existingWar.removeWar();
>                existingWar.close();
>                sysDeploy(paWar, DEPLOY_WAR);
>            }
>            else
>            {
>                deploy(paWar);
>            }
> 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.  
> 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.
> 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.  Adding the above logic seemed 
> to fix this for me.
> Randy Watler wrote:
>> I have committed a new PAM/deployer implementation that uses the 
>> deploy-tool component to infuse portlet application war files for J2. 
>> This is being done in an attempt to simplify the deployment process 
>> and make it more reliable. Please bear with me on this change... I 
>> need feedback from all of you on how the new approach fairs in your 
>> environment.
>> This implementation, (WarInfusionPAM), eliminates the requirement to 
>> have the Tomcat manager web application in place and all of the 
>> associated configuration options. Instead, this PAM places WAR files, 
>> (or expanded webapp directories and context.xml file sin the case of 
>> Tomcat4), in the container target webapps directory. The assumption 
>> is that the container will support "auto", "live" or "hot" deployment 
>> of some sort. When the portlet application webapp is loaded, it uses 
>> the JetspeedContainerServlet.init() invocation to register the 
>> portlet application in the webapp with the PAM implementation. 
>> Hopefully, there will no longer be a need to specialize deployment 
>> implementations per container.
>> I have left the preexisting deployer option in place, 
>> (ApplicationServerPAM), so you should be able to roll back the PAM 
>> implementation if you run into problems. You will need to comment out 
>> the WarInfusionPAM bean and uncomment the ApplicationServerPAM and 
>> TomcatManager bean entries.
>> There is one option that can be set in the spring configuration of 
>> WarInfusionPAM to control whether the PAM interacts with the webapps 
>> directory  using expanded webapps directories or with war files. By 
>> default, it uses expanded webapps if a context.xml file is found in 
>> the webapps directory, (i.e. jetspeed and jetspeed.xml). Setting the 
>> boolean field value in jetspeed-spring.xml forces the selected mode.
>> At the moment, there is a problem with undeploy/redeploy on Windows 
>> platforms. I believe this is due to file read locks on the 
>> WEB-INF/lib jar files, possibly others. I am currently working on a 
>> solution and/or workaround for this problem.
>> 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

View raw message