Hi all,
I work currently at the University of Helsinki, and we are in progress
of finding and integrating a JSR-168 compliant portlet container into
our portal. Pluto1.1 is one candidate since it looks much cleaner and
nicer than the 1.0.1.
And yes, I do understand that Pluto is a reference implementation - but
bear with me when I do ask some questions that relate to production
enviroments.
Our portal uses Spring Framework - and we are quite fond in doing things
the spring way, since it eases our maintenance work and makes thing more
consistent in style with each other.
Questions:
----------------------------------------------------------------------
- How stable is the internal structure of Pluto 1.1?
Ie. if we start to integrate Pluto now into our portal structure -
will we soon find that there has been a major refactoring and almost
all APIs have changed?
- Is anyone even thinking about using Pluto 1.1 in production
- Are there any major reasons not to do it
- Is there something extremely important missing/hidden that
we should watch out?
- Is there something better to consider for production use?
- Has there been any thoughts on scalability and caching?
Since our portal will have tens of thousands users, we are quite keen on
making sure that each bit scales nicely even when loads grow.
How to do integration?
----------------------
We are interested to use parts of the portal driver and the portlet
container as it is, and this is what I thought that we need to do to
integrate Pluto into our portal.
1) Configurations / configurability
We will most likely take a stab at the way how portal driver is
configured now - and use/create something that is more in line with how
everything else in our portal is configured.
Naturally lots of things - like layouts, user preferences etc. - will
come from the database.
2) Create own implementations of core services:
- PropertyConfigService:
To provide information about portal ( piece of cake )
- PortletRegistryService:
To provide information about available portlet apps and
portlets
- RenderConfigService:
Implement our own url and page management
- PortletPreferenceService:
Based on DBPortletPreferencesService implement our own
DB-based preferences storage-service that integrates with
our other DB schemas
3) Implement our own management layer for user data and user preferences
In the checkout that I have been playing with, I did not notice
anything about providing userdata to portlets from portal / portlet
container. But that is trivial thing to implement.
Is there anything else that we should take care of?
-huima
