Re: [uportal-dev] Deprecated code removal (IMultithreaded*)

[Andrew Petro]

Hi Eric, "Make wars, not war." I'm with Dan on this one.  IMultithreaded has not been deprecated long enough to be removed outright; removing it outright will significantly inconvenience folks who coded channels in what was prior to the realization that IMultithreaded was a bad idea, the "best practices" recommended way. It seems to me that the relevant potential uPortal and JA-SIG have started to take action on is to JSR-168-ify the most popular channels. (This is happening at least in spirit, vis. the Email Preview Portlets starting to move in on some of the UBC_Webmail use cases.)  CAnnouncements* would be even better formulated as a Spring PortletMVC-implemented JSR-168 portlet -- in such a design it might even be possible to accommodate the varying announcements channel needs on a single shared codebase different configured locally, which would have significant advantage in making progress rather than forks. I believe the best tactical move here is for JA-SIG to go after JSR-168 and Spring PortletMVC in a big way, for the architecture advantages, for the collaboration advantages.  If we do that, using the Unconference and our conference and our camaraderie to grow towards that as the go-to way to implement portal widgets for this community in a way that the source can be most usefully shared among us, then the end of IMultithreaded*Channel support in uPortal will be one of pull factors rather than the push factor of an API-still-in-use being pulled out from under. However, if Springification of uPortal progresses to the point where ChannelManager etc. implementation is declaratively configured, then there may very well be room in the world for MultithreadedChannelSupportingChannelManager vs. SleekNoMultithreadedsChannelManager .  It's probably worth more thorough investigation before doing that heroics, but as noted in the page pitching deprecating IMultithreaded, review of the code suggests to me that there are performance gains to be had by eliminating IMultithreaded *support* from the framework.  Support for the IMultithreaded*s at all, whether they're used or not, introduces lock churn on every channel instantiation. One of the initiatives I've pitched for inclusion in the scope of uPortal 3.x is a Grand Unification and Distribution of the Cool Widgets uPortal is Sitting On But Not Shipping By Default.  Maybe this idea's not rolling off the tongue elegantly contributes to its lack of uptake. If uPortal reviews the available channels and portlets, makes them shine, includes them by default in the uPortal distribution, such that one gets a cool announcements experience out of the box, then there's an opportunity to 1) Standardize on some (presumably non-IMultithreaded, quite possibly Springified) code, thereby increasing the future potential for deprecating that API, 2) projectify the fringe projects, getting them up to a point where they're cutting releases suitable for inclusion in uPortal, and 3) raising the baseline functionality of uPortal in a way that competes with e.g. LifeRay and helps this open source project to market itself. My suggestion is that uPortal "Make wars not war" here. (Like that one?)  Eliminating support for something people are using is hostile, a wee bit like "making war".  Going after compelling shared-source JSR-168 portlets well-architected to meet the shared needs of higher education ("making wars"), make these easy to adopt, make it clear in this community how effective this is as an approach for implementing institution-local portal widgets (the Duke presentation at JA-SIG Denver was a good step in communicating this message) and the need to support any IChannels at all as such [1],  let alone IMultithreaded, will make great strides towards quietly going away. Andrew [1]: I'm still not convinced this means that the framework gets rid of IChannels.  IChannels, especially if uPortal were free to aggressively evolve them to meet new JSR-168 and JSR-286 support needs, still seem to me to be a reasonable and affective way for the portal to implement the layer that sits above the portlet container, the boxes and tasks the portal needs to allocate, start, and stop when they time out.  It's proving pretty convenient that CPortletAdapter exists and can exist alongside other JSR-168 support implementations, allowing e.g. special handling for portlets needing CAS proxy tickets. Hi Eric, I'd rather see the multithreaded code deprecated, since whatever the advantages of removing it, it raises the cost of migration for quite a few current implementors. I've written a couple of multithreaded channels for local use at Columbia, at least one of which is still running.  If I remember correctly, some of the Announcements channel variants are IMultithreadedChannels.     Dan Eric Dalquist wrote: With the basic Spring re-org done the next task on the block is reviewing and removing deprecated code from the framework. There is a Jira issue http://www.ja-sig.org/issues/browse/UP-1832 of course and you can peak at the Fisheye tab to see what has been done so far. One large set of files that is deprecated is everything related to multithreaded channels. I would like to get opinions of people on if this code should be out-right removed for a uPortal 3.0 release or is it ok to remain in the codebase but be deprecated? Thank you, -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev