The error I see when trying to stop or undeploy from Portal Application Manager:
I see this in the jetspeed-deployment.log 2012-03-26 09:14:23,530 [http-8510-1] ERROR deployment - IOException: java.net.ConnectException: Connection refused: connect and I see this in the portlet UI: Failed to stop application: /<my-portal-application>. Connection to Application Server is not available. I've noticed that after I cleaned up the tables manually as I described in my post, if I subsequently try to deploy that portal application something doesn't work quite right. The PA doesn't show up in Portal Application Manager, and I get this in the jetspeed-deployment.log 2012-03-26 09:04:18,278 [Timer-3] ERROR deployment - Unable to start portlet application after 10 retries: org.apache.jetspeed.components.portletregistry.RegistryException: Error starting portlet application <my-portal-application> org.apache.jetspeed.components.portletregistry.RegistryException: Error starting portlet application <my-portal-application> at org.apache.jetspeed.tools.pamanager.PortletApplicationManager.attemptStartPA(PortletApplicationManager.java:677) at org.apache.jetspeed.tools.pamanager.PortletApplicationManager.tryStartPortletApplication(PortletApplicationManager.java:244) This probably answers my question if there are side effects from manually editing those tables. On Fri, Mar 23, 2012 at 8:05 PM, robotdan <djdm...@gmail.com> wrote: > I have tried that, it hasn't worked for me. > I am unable to stop or undeploy there, I don't have the exact error > message off hand, I can post it here when I get in front of it again. > > Something like 'can't connect' or something to that effect when I try to > stop the portal application. > Are there any special requirements to be able to stop and undeploy a > portal application through the Portlet Application Manager? > > Is it correct to say that the only way for the portal application to > removed from the Lucene index is to undeploy using the Portlet Application > Manager? > > Would it be possible to piece together an API call with tomcat stopped to > perform a similar function that the Portlet Application Manager is doing > for an undeploy? > I've hunted through the Jetspeed source but haven't anything obvious yet. > > > Thanks. > > On Fri, Mar 23, 2012 at 7:53 PM, David Sean Taylor < > davidseantay...@gmail.com> wrote: > >> Assume you've tried deleting the application from the Portlet Application >> Manager. If the application does not show up in the list of applications >> deployed to your server, then something is out of sync. If it does show up >> there, simply delete the application. Otherwise, probably the easiest way >> to resolve is to simply redeploy the app, and then undeploy it. It seems >> like the application is still indexed in the Lucene index. Deleting or >> Undeploying an app from the Portlet Application Manager will delete the >> index >> >> On Mar 23, 2012, at 1:19 PM, robotdan wrote: >> >> > I'm using Jetspeed 2.2.0 running on Tomcat 6.0.18. >> > >> > Is there is a way in which to undeploy a portal application that causes >> > Jetspeed to perform database cleanup. >> > >> > I found a thread back from 2005 that seems to be asking the same >> question. >> > >> http://mail-archives.apache.org/mod_mbox/portals-jetspeed-user/200507.mbox/%3c42cfefc8....@digizenstudio.com%3E >> > >> > To remove our portal application, we just remove the war file, and >> cleanup >> > any other jars we've laid down in support of our portal application >> during >> > our removal process as was suggested in the above thread. >> > We do this with Tomcat stopped, but I've also tested removing the jar at >> > runtime which causes the exploded war directory to also be removed >> > automatically. Both of these yield the same results. >> > >> > The result being that the Jetspeed database still keeps a record of our >> > portal application in the PORTLET_APPLICATION table. >> > The portlets shipped w/ our portal application still have records in the >> > PORTLET_DEFINITION table - as well as portlet preferences still being >> > stored. >> > >> > The visible problem I have is that these portlets still show up in the >> > Custom Portlet Selector even after we've removed our portal application. >> > We don't want users trying to select portlets that do not exist. >> > >> > I have tested removing records manually from the Jetspeed database, >> which >> > does seem to work, although I don't know if there may be other side >> effects >> > of doing so. >> > After doing this manual cleanup, when I use the Custom Portlet Selector, >> > the portlets from my removed portal application are gone, and if I go >> into >> > the Jetspeed Portlet Application Manager, it is also removed there. >> > >> > Here is an example of the SQL I used to do the cleanup: (where the >> > APPLICATION_ID of 4 corresponds to the portal application that I >> undeployed) >> > >> > DELETE FROM PORTLET_APPLICATION WHERE APPLICATION_ID = 4 >> > DELETE FROM PORTLET_DEFINITION WHERE APPLICATION_ID = 4 >> > >> > Is this up to us to clean up, is there a Jetspeed API, or a better way >> to >> > undeploy - is it even safe safe to directly modify this table w/out >> > Jetspeed knowing? >> > The same probably goes for old records in the PORTLET_PREFERENCE table, >> > those don't really cause us any problems, but it would be nice to clean >> up >> > preferences for users that have been since deleted. >> > >> > I have not had any luck with using the Jetspeed portlets for undeploy of >> > our portal application - and I think even if that worked - that doesn't >> fit >> > our needs because we don't expose that function to our end users. >> > We have command line scripts that add and remove our portal >> applications. >> > >> > Thanks. >> > Daniel >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org >> For additional commands, e-mail: jetspeed-user-h...@portals.apache.org >> >> >
