On contextIntialized we verfiy that the portlet app is installed, if not, register it.
Okay that is the easy part. The hard part is undeployment since the context listener only has a contextDestroyed and no contextRemoved.
Here is one option:
1. contextRemoved ALWAYS undeploys portlet apps when fird meaning that contextInitialized will ALWAYS be deploying on start up. Benefits:
- Not fancy but simple.
- Will automatically solve our portlet.xml update problems, since forcing the webapp to redeploy in the container should theoretically call contextRemoved. At least I THINK is it would.
Drawbacks:
- can we depened on the container to call contextRemoved when undeploy and redploy actions are taken?
- we have very little control over the lifecycle of the apps but that might be a good thing ;-)
- we cannot discern between the first part of a redeploy and undeploy, hence we don't know if we need to remove preferences or not.
IMOHO, and I have said this before, is to leave all the prefs intact, even on undeploy. I know I received static on this because this abuses data integrity rules. However, I think we could implement a maintenance portlet that the admin can use to both backup, export and delete prefernces on a per-portlet basis
This is how I see the app functioning:
Run a query to show orphaned prefs in a list. From that list allow the admin to select the actions to take on those prefs:
1. keep: does nothing, leaves the prefs in the DB.
2. export: exports the prefs to the standard java.util.prefs xml format that can to downloaded immediately from the admin portlet
3. delete: Removes all prefs completely for that portlet
4. export-and-delete: Does 2 then 3.
5. remap: allows the admin to remap the prefs to another portlet.
6. remap-and-delete: Does 5 the 3.
I have always liked this approach as it is the safest in terms of preserving user preferences, even in the stickiest situatiuons.
Ate Douma wrote:
Scott T. Weaver wrote:
Randy Watler wrote:
David/Scott,
I like this solution... it is MUCH cleaner codewise than trying to deal with
the various application servers/environments. I'll give it a try sometime
tomorrow.
A few questions for the uninformed:
- I am assuming that the various portlet apps would never actually invoke
the JetspeedContainerServlet... is that right? If so, perhaps it would be
better to use a listener/ServletContextListener hook: this might be easier
to infuse in the web.xml.
I like the listener/ServletContextListner idea.
- All of this works because Jetspeed-commons resides in a shared classI would like to see it work like this:
loader, right? Is that functionality part of the Servlet Container spec...
must be, no?
- Are you imagining this as strictly a build time tool or are you thinking
we could encorporate the logic in the deploy-tool to the existing File based
PAM and deploy complete war files into webapps at runtime?
1. Run and "infusing" deploy tool that all it does is mod the web.xml and add the correct entries for the J2 servlets.
2. Leave it up to the user to deploy the newly infused war to the container of their choice.
3. When app sucessfuly deploys, the listener/servlet (which ever the choice is) does the registeration.
+1
I will ponder more while I get some sleep...
Randy
-----Original Message----- From: David Sean Taylor To: Jetspeed Developers List Sent: 1/18/05 1:55 PM Subject: JS2 deployment
Randy,
Since you are working on deployment issues, thought I share this with you.
We (Scott and I) would like to consider a new (old) method to deployment. This method would hook into the servlet init, and register the portlet application to Jetspeed during servlet initialization. If you set the app to init at startup, then your PA will get registered during app server startup.
This means that we will no longer need specific code for application deployment to each app server. In theory, this may solve our race condition issues.
Start with a look at the JetspeedContainerServlet in the commons directory. It has a "registerAtInit" init parameter.
I added this functionality a while back as a solution to register with Jetspeed during servlet init - so that we don't have to worry about deployment issues specific to app servers. In the long run the current method won out, but we are now reconsidering this method.
Finally, there is also a command line utility for registering portlet applications. See the deploy-tool component, and the uberjar goal
Give it a spin and let us know what you think,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "Great minds discuss ideas. Average minds discuss events. Small minds discuss people." - Admiral Hyman Rickover
******************************************* * Scott T. Weaver * * <[EMAIL PROTECTED]> * * <http://www.einnovation.com> * * -------------------------------------- * * Apache Jetspeed Enterprise Portal * * Apache Pluto Portlet Container * * * * OpenEdit, Website Content Management * * <http://www.openedit.org> * *******************************************
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
