geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
Date Sat, 27 Oct 2007 15:32:20 GMT

On Oct 27, 2007, at 6:56 AM, Donald Woods wrote:

> Paul McMahan wrote:
>> 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.
> +1 as I see many situations where the Pluto Admin Console will  
> still be used even when Jetspeed or Liferay are installed.

I haven't looked into exactly how the admin console plugins get added  
to the admin console but if they are geronimo plugins they have  
already gone through the deployment process and there is no chance  
for the jetspeed MBE to see them as the deployment machinery is not  
activated at all when a plugin is installed.

david jencks

> -Donald
>> 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:
>> myapp-jetty-jetspeed
>> myapp-jetty-pluto
>> myapp-tomcat-jetspeed
>> myapp-tomcat-pluto
>> Best wishes,
>> Paul

View raw message