I'm sitting here in the Geronimo Tutorial and I just saw the Geronimo Console. Santiago, did this discussion ever go anywhere?
IMHO, we hare in a better position to handle deployable PSML, (both in a site jar file and/or in a portlet-app WAR. I am supposed to work on the PSML deployer here soon... Should we discuss this stuff with the Geronimo team this week? Randy On Sat, 2005-09-24 at 12:19 +0200, Santiago Gala wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
