Jeremy Boynes wrote:
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.
Nice!
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.
This will definately be doable in 1.1. Currently, the admin portlet in 1.0.x is the only way for hot deployment, however, in 1.1 we have talked about detaching this from the portlet and making it native to the portal so that multiple interfaces can connect and issue deployment (and perhaps other management) commands. My personal preference as this point is to have a web service bound to the portal which listens for such requests.
In order to support multiple portals you will simply need to make the request to the correct context.
* 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 :-)
Aggregation in 1.1 has totally changed. 1.1 uses simple jsp tags for portlet inclusion/templating and a registry for determining which portlets belong where upon a page. I don't see any reason why this interface can't be exposed in the same manner as the portlet registry (discussed above).
Currently all information is persisted using services. To date, the only service is a read only xml based service, however, I am working on an rdbms service which utilizes an embeded db. This may be of assistance to you.
* 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
Don't see this as an issue at all. Can you user what the spec provides?
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.
You are correct, as a team we have definately said that the focus of our effort should be the container. That said, there's definately been a push to make our driver a little more rohbuts. I have heard of others who are using pluto as a means for supporting "plugins" within a standard web app -- in other words, not as a traditional portal which provides customization/personalization, but more as an integration framework. I (personally) would definately like to support this type of effort.
IMHO the types of enhancements you've mentioned so far are not so far from the container that we can't support them in pluto.
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?
Quite frankly, that's MY personal vision for 1.1. At the same time, I would not discourage you from using J2. What do other's think?
For me, the ideal world would be Geronimo utilizing pluto for the admin console but providing J2 as a fully functional portal server.
-- Jeremy
