geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <>
Subject Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
Date Fri, 26 Oct 2007 19:07:16 GMT
On Oct 26, 2007, at 12:55 PM, David Jencks wrote:

> On Oct 26, 2007, at 9:34 AM, Paul McMahan wrote:
>> This jetspeed integration is coming along nicely!  Very promising  
>> work.
>> Instead of introducing a MBE that automatically configures the  
>> webapp for jetspeed based on the presence of WEB-INF/portlet.xml  
>> can we look into allowing jetspeed to handle its own deployment  
>> via placement in its hot deploy directory?   When a war is placed  
>> in that directory jetspeed processes the portlets internally and  
>> then handles deploying the war to the app server.   i.e. the  
>> portal recognizes the WAR as a special kind of app and handles the  
>> extra deployment steps, not the application server.
> I think that what Prasad is doing is a better way :-) (which is why  
> I suggested it).  How would a portlet app plugin work with hot  
> deploy?  imho magic hot deploy directories are really out of line  
> with the whole geronimo modularity philosophy and I would support  
> removing the hot deploy functionality we have (well, I know that  
> wont happen, but I'd still support it).

I really didn't mean to focus on the issue of hot vs. cold  
deployment.   I'm mainly wondering whether or not, in general,  
Geronimo should try to encapsulate or otherwise replace Jetspeed's  
deployment functionality.  In addition to hot deploy, Jetspeed also  
provides a pretty complete maven plugin for managing the portal and  
deploying portlet applications.   I bet it also provides some type of  
admin UI for deploying portlet applications.

As a Jetspeed user I would expect the existing deployment mechanisms  
to all continue working in Geronimo.  As a Geronimo developer I would  
like to take advantage of Jetspeed's deployment functionality as much  
as possible and avoid sensitivities to changes in their architecture  
going forward.  Utilizing Jetspeed's hot deploy directory is only one  
idea for how to accomplish these goals, maybe not the best one.   
OTOH, using a MBE to subvert Jetspeed's normal deployment processes  
seems contrary to those goals.  But maybe I am misunderstanding how  
you suggested to implement this.

> I was hoping that the pluto portlet app deployment would work in  
> the same way with an MBE.

While the portlet spec is pretty complete for application design  
there currently is no specification for deployment within a portal.   
In the absence of a spec Pluto implemented deployment in a pretty  
clever way that is heavily based on standard webapp deployment and  
therefore very portable across servlet containers without extra  
configuration.  So an MBE for Pluto isn't necessarily required, but I  
can see where a MBE for translating portlet.xml entries into web.xml  
might be helpful (GERONIMO-3252).   Meanwhile there is a Maven plugin  
for that.

>> I have a hunch that trying reverse that paradigm or somehow  
>> wrapper the deployment responsibilities of jetspeed from within an  
>> MBE could prove to be confusing to jetspeed users, difficult to  
>> implement correctly, and very sensitive to the jetspeed version.    
>> And like Donald pointed out it would interfere with other portal  
>> apps that might be deployed in Geronimo like Liferay, uPortal,  
>> Pluto (the admin console), etc.
> I think we should look into selecting the portal to deploy to based  
> on something in the geronimo plan if we really need to support  
> multiple portals running at once.  If we don't, building a portlet  
> app into a plugin for a specific portal could be handled by  
> specifying the desired portal MBE car in the plugin's pom.

The admin console needs to be lightweight and portable so it is based  
on Pluto.  The Jetspeed MBE (as currently designed) would interfere  
with the deployment of admin console extensions.  Adding something to  
the Geronimo plan to activate the Jetspeed MBE instead of just  
looking for a WEB-INF/portlet.xml sounds like a reasonable  
solution.   Let's pursue that approach.

Maybe it's unavoidable, but if possible I hope we can avoid creating  
plugins that are sensitive to the Portal vendor.   e.g. for one  
portal app I hope we don't require four plugins:


Best wishes,

View raw message