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 > >
