You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by robotdan <dj...@gmail.com> on 2012/03/23 21:19:03 UTC
How to clean up Jetspeed database after undeploy of portal applications
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.708@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
Re: How to clean up Jetspeed database after undeploy of portal applications
Posted by David Sean Taylor <da...@gmail.com>.
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 <dj...@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 <
>> davidseantaylor@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.708@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-unsubscribe@portals.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: How to clean up Jetspeed database after undeploy of portal applications
Posted by Daniel DeGroff <dj...@gmail.com>.
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 <dj...@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 <
> davidseantaylor@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.708@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-unsubscribe@portals.apache.org
>> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>>
>>
>
Re: How to clean up Jetspeed database after undeploy of portal applications
Posted by robotdan <dj...@gmail.com>.
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 <
davidseantaylor@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.708@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-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: How to clean up Jetspeed database after undeploy of portal applications
Posted by David Sean Taylor <da...@gmail.com>.
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.708@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-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org