CC: jetspeed-dev, as I find the discussion relevant for a lot of portal use cases.
El jue, 22-09-2005 a las 09:54 -0700, Jeremy Boynes escribió: > Craig Doremus wrote: > > Jeremy, > > > > I have not seen the Geromino console, so I am not sure what you mean by > > "making it more dynamic", but a recent change to the Pluto portal might > > help you. I have added a hot deployment feature to the Pluto Admin > > application. There is a binary Snapshot of Pluto 1.0.1 with this feature > > available at: http://cvs.apache.org/dist/portals/pluto/v1.0.1/. > > > > The servlet controller that underlies the Pluto portal > > (org.apache.pluto.portalImpl.Servlet) was modified to dynamically > > re-read Pluto's registries > > (portletentityregistry.xml,pageregistry.xml,portletcontexts.txt) when it > > is invoked with a 'hot deploy' parameter. > > > > The long term vision is that someone will be able to include a > management portlet with their application and when it starts that > portlet automatically appears in Geronimo's console allowing admins to > control the applications as well as the server. > In a recent jetspeed discussion on IRC, regarding how to deal with demo pages for the handful of different demos we have, we were able to articulate a similar requirement: - We want to have a portlet application (war) to include one or more portal pages. - We want to have the portal able to "mount" those pages in a given mountpoint (configurable by the portal admin) in the site map Jetspeed uses PSML as a format to express the structure of a portlet page (which portlets are referenced and how are they decorated and layed out in the browser page). My bet is that you will need something similar: - to enable easy discovery/demo of the included functionality in a war - to "automount" conforming wars in a certain point in the space in the site. > There are a few challenges to overcome before we get there: > > * letting the portlet container know the new portlet is available > I think the hot deploy stuff would help there. There may be an > additional challenge in that multiple portals may be running and > we need to make sure the portlet ends up in the right one. > jetspeed has hot deployment using a directory in the portal, so if there are several portals in the servlet container, it is a matter of dropping it in the proper place. But I'm not sure jetspeed2 supports currently several instances in the same container. Anyone knows? > * adjusting the aggregation to include the new portlet > I think we may need additional metadata with the portlet that would > determine where it should go. This is slightly different to a > traditional portal where the user determines where it goes - although > that should work too :-) > This is where the idea of the war specifying a set of pages which show the included portlets and servlets integrated should work. For simple portlets it would be simple to just add them to a certain page, but in the general case of a set of interacting portlets it is better that the war specifies a full page or a set of pages. > * controlling access to the portlet > Given these are for administration, we would need some form of access > control to determine who can see the portlet at all, what information > a user can view and what they can modify > JSR-168 gives a coarse access specification in portlet.xml As far as I can tell, there is nothing standard beyond this, i.e., the portlet itself should use JAAS and java security. > I've been assuming that most of this type of functionality is portal > related rather than container related and that we would probably end up > including J2. However, I don't think we need all the functionality from > J2 and I have been concerned that we would end up bloating Geronimo just > to have snazzy console functions that people don't use. > We are making an effort to simplify jetspeed: - make most of the demos optional, and with them the set of dependencies, and re-structure them so that the learning curve is simpler. - build demos in portals-bridges, so that building a portal just "uses" demo .wars coming from the different bridges builds I mean, a page where different demos are listed and a way to drop them in the autodeploy directory, plus a set of auto-mounted demo pages would go far in this area, while keeping the core jetspeed simple. Most of the "bloat" now existing is due to the mixup of different technologies (jsf,struts,jsp,velocity,perl,php,python...) to be shown/demoed/tested in early development stages. Now that we have pushed the bridging functionality outside, it is possible to factor out most of those dependencies to where they belong (the app/demo area, not the portal area). Not all of this effort is done, we still need to move the demo webapps themselves to portals-bridges. > With that in mind, I have been wondering if there is a use for a kind of > stripped down portal that does this kind of thing but does not offer the > capabilities of something like J2. Is that something that the Pluto > folks would be interested in or would it be more aligned with J2? > Not sure. I'd like to see how far the portletAPI can be stretched. I guess we need more work in defining the different requirement sets/use cases, and work from there. J2 has done a big effort to be less monolithic and more modular. In fact, the whole page aggregation process is done using portletAPI +internal hooks. As part of the Google Summers of Code grant that I was mentoring, (ajax rendering in jetspeed), I wrote a layout.py prototype portlet in jython, using the *I should commit it asap to portals-bridges* ;) python bridge that does the whole page aggregation, much like it is done now in velocity. This means that the architecture is clean enough so that a layout portlet can be written using just context references to a couple of jetspeed objects and the portlet API. This, for me, was a strong demonstration that the current architecture is sound, and logically isolated. Regards Santiago > -- > Jeremy -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation
signature.asc
Description: This is a digitally signed message part
