portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T. Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject Re: JS2 deployment
Date Fri, 21 Jan 2005 16:08:00 GMT
I just looked at the servlet conetxt listener and here is my suggestion 
for usage in depolyment.

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. 
 - 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.
- 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 class
>>> 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?
>> I would like to see it work like this:
>> 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: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

"Great minds discuss ideas. Average minds discuss events. Small minds discuss people."  -
Admiral Hyman Rickover

*           Scott T. Weaver               *
*         <weaver@apache.org>             *
*     <http://www.einnovation.com>        *
* --------------------------------------  *
*   Apache Jetspeed Enterprise Portal     *
*     Apache Pluto Portlet Container      *
*                                         *
* OpenEdit, Website Content Management    *
*     <http://www.openedit.org>           *

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message