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
