Did you try Deleting the app? In order to stop and undeploy to function, you will need to setup a user in Tomcat users XML file with manager role that matches the jetspeed.properties below
application.server.manager.name=j2deployer application.server.manager.password=j2deployer On Mar 26, 2012, at 7:18 AM, Daniel DeGroff wrote: > 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 >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-user-unsubscr...@portals.apache.org For additional commands, e-mail: jetspeed-user-h...@portals.apache.org
