[EMAIL PROTECTED] wrote:
Jeremy Boynes <[EMAIL PROTECTED]> wrote on 09/22/2005 12:54:20 PM:
>
> 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.
>
> 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.
The current Admin Portlet app assumes one instance of the Pluto
portal. You might be able to deploy more than one Pluto instance in a
servlet container but each would have its own admin interface with
separate registry files.
>
> * 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 :-)
Currently, a page in Pluto's portal holds all the portlets from a
single portlet application bundled in the same war. I hope we can add
the ability to dynamic modify the layout of those portlets in Pluto
1.1 once they are deployed, but that is currently not in scope for
Pluto 1.0.1. Dynamically adding a new portlet to a page or mixing
portlet applications on a page would require a more sophisticated portal.
That is only a restriction of the admin portlets. You can deploy
different portlets from different apps on the same page if you create
the page definition xml by hand.
>
> * 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
One way is to use PortletRequest.isUserInRole() to do access control.
You can combine an isUserInRole() check with an
ActionResponse.sendRedirect() call to redirect the user to a 'no
access' page or just modify the portlet response to hide sensitive
material. BTW, there is the capability within portlet.xml to map roles
coded in the portlet to actual roles in the deployment environment.
This kind of access control should be done on the portal level and not
in the portlet itself IMO.
>
> 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.
>
Our portal is a lightweight implementation. I see it as more of a
portlet development environment rather than a production deployment
environment. I think meeting your requirements is more in scope for J2
at this time.
/Craig
Stefan
