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]
