Ate, Thanks for the information. I was not sure how the new deployment model fully worked. I will try it out with the PALM.
Thanks, Hema On Sat, 26 Mar 2005 23:27:42 +0100, Ate Douma <[EMAIL PROTECTED]> wrote: > The new deployment model may seem more limited at first but actually its not. > > The real change is that deployment really now is handled by the web/app > server you > are using. What J2 deployment manager does when you drop a war in the deploy > folder > is nothing more than rewriting the web.xml (if needed) so that the required > JetspeedContainerServlet is present. Then it simple *moves* the war file into > the > configured webapp folder of the web/app server. That will take over from > there. > If you have autodeploy enabled in your server it will happen automatically > after that. > > Note: you don't have to drop your war in the deploy folder if it is already > properly > configured (infused J2 web.xml). You can do this yourself by hand (just look > at the > changes J2 makes, there are only a few), or use the JetspeedDeploy tool, > which is > a component in the components/deploy-tool folder. The JetspeedDeploy tool can > be used > standalone to infuse your war offline. > A infused war can simply be dropped in your web/app server webapp folder > and/or deployed > any other way your web/app server requires. For the same reason, you can > (hot) deploy > an expanded *and infused* war yourself using the web/app server functionality. > > Undeploy is now something which has to be performed by your web/app server as > well. > For Tomcat, J2 can already handle this for you through the new PALM portlet > (if you > configured it correctly like in the default configuration as it comes with > J2). > But, you can do this directly from the Tomcat manager itself or through some > other > way your web/app server supports. > > What undeployment *not* does is unregistering the portlet application. This > isn't > always wanted either because you lose possible stored preferences when you do. > But, the PALM portlet allows you to do this too through its "delete" function. > Because the delete function is web/app server independent its always > available. > > So, I hope you agree the new deployment model really brings more flexibility > to > the way you can deploy your application. Only undeployment now requires a > little more > effort (but then, how often do you really do a terminating undeployment). > Another benefit of this solution is the much shorter startup time you might > have > noticed already (at least, after the initial deployment has been done). > > Regards, Ate > > Hema Menon wrote: > > How can we undeploy an application with the new deployment model? > > Previously you could delete the deployed war from the deploy directory > > which would then unregister the application. With the new model, the > > deployed WAR is removed from the deploy directory upon deployment. So > > how can I undeploy an application? > > > > Also, previous versions would allow you to have a war that is unpacked > > to be added to the deploy directory. It appears that it is necessary > > to have the application packaged as a WAR to be deployed. If the > > unpacked directory is added, the application is not deployed, a > > warning of "Unrecognized file" is displayed. I guess, it is now > > necessary to have the application deployed as a WAR, which is OK, I > > guess. > > > > Thanks, > > Hema > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Hema Menon > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hema Menon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
