110 likes | 244 Vues
This document explores the implementation strategies for maintaining backward compatibility in uPortal 3, focusing on the ChannelAdapterPortlet. It addresses historical context, compatibility challenges, and recommends collaborative approaches for developers to ensure seamless integration with previous uPortal versions. Key topics include lifecycle management, parameter processing, and leveraging existing services from uPortal 2, as well as proposals for enhancing channel portability and reliability. The aim is to foster a robust framework that supports the transition for hundreds of sites currently in production.
E N D
Peter Kharchenko pkharchenko@unicon.net Adam Rybicki arybicki@unicon.net IChannel Support in uPortal 3
Agenda Downward compatibility Implementation options ChannelAdapterPortlet
History • When uPortal 2 was being designed, there were no uPortal 1 sites in production. • When uPortal 2 was released, there were fewer than 5 sites in production. • We now have hundreds of sites in production.
How others support downward compatibility? • Tomcat will not disable support for “old” servlet and JSP versions. • EJB 3 greatly improves ease of development, but no container vendor will abandon support for 2.1 or older. • Commercial vendors will not abandon their proprietary (pre-JSR-168) interfaces. • IChannel is an example of a mature interface, which in some respects may be superior to ‘168.
What level of compatibility? • To be 100% compatible with 2.x, the uPortal 3 implementation would have to include the entire 2.x framework. • Many channels out there. How many rely on internal framework classes? • Probably the least portable channels were developed by developers most familiar with the framework itnernals. • Proposal: ask the community to send us all of their “import org.jasig.portal.*” lines of code. • How will common framework services be accessed by uPortal 3 portlets?
Alternatives • ChannelAdapterPortlet • provides channel lifecycle, serialization • Standalone uPortal2 instance • tweaked to deliver standalone channels • Internal request dispatching • WSRP • Native support for channels in uP3 • ChannelAdapterPortlet would be cleaner • Other ideas ?
ChannelAdapterPortlet • Maintains channel instances • Similar to ChannelManager in uP2 • Takes care of • Channel lifecycle • Parameter processing • Serialization • Caching • Provides access to framework services
ChannelAdapterPortlet • Instance management • IChannel: one instance per portlet window • can be maintained in portlet session • IMultithreadedChannel: one instance • will rely on channel to clean up internal maps based on the events sent by adapter
ChannelAdapterPortlet • Channel lifecycle • init() – setStaticData() • processAction() – pre-setRuntimeData() • render() – setRuntimeData()+renderXML() • portal events • Parameters • processing is straightforward • no more baseActionUrl • Make all URLs actionURLs?
ChannelAdapterPortlet • Access to uP2 interfaces, support classes and services • uP2-api.jar + uP3 implementations • Basics: • Channel interfaces • ChannelRuntimeData, ChannelStaticData • IPerson • Further: • IAuthorizationPrincipal • ICC Registry, JNDI context (wait for IPC)
ChannelAdapterPortlet • Static services • GroupServices, AuthorizationService, EntityNameFinderService • RDBMServices • XSLT utils • CAR support • CarServices • Packaging/deployment