Page Comparison

...

Let me start out by saying this proposal doesn't propose that support be dropped for IMultithreaded interfaces. This proposal does propose that they should be marked as deprecated and over time channels should be rewritten to use IChannel instead. Eventually there might come a time when most current IMultithreadedChannel implementations have dropped IMultithreaded and we can simplify and improve the performance of uPortal by dropping support for this interface, but there are no near term plans to drop that support. Also, we need to make it clear that IMultithreaded* channels shouldn't be perceived as a better, faster more optimized way of developing a channel.

Advantages of Implementing the IMultithreaded* Interfaces

IMultithreaded* allows the running portal to minimize the number of calls to Class.forName("org.jasig.portal.YourChannelClassName").instanceOf(), because this call happens once per channel class name and then, for IMultithreadeds, the instantiated class instance is stored in a static Map so that from then on it can be looked up by String class name.

Drawbacks of Implementing the IMultithreaded* Interfaces

...

And these services can be shared. They can be grabbed from Factories using static initializers if they need to be shared statically. They can be grabbed from Spring if you'd like to declaratively configure them. They could even be grabbed from JNDI. Writing traditional IChannels, rather than IMultithreadeds, does not by any means mean that your channels cannot share the state and services they ought to share. Avoiding IMultithreaded does, however, help channels to avoid sharing state they don't need to share, state that just gets in the way.

Summary

What makes this even more clear-cut for me is that we haven't written a single channel that benefits from being implemented as IMultithreaded*There are no important advantages of IMultithreaded* to be had, and there are real costs of implementing this interface. It is clear that we should discourage implementation of channels as IMultithreaded*, and I think deprecating the interfaces is the clearest way to communicate this without ambiguity.

...

• Discourage use of these deprecated APIs
• Refactor the core channels to implement IChannel* .
  • These framework channels implement one of the IMultithreaded* interfaces:
    • CGroupsManager
    • CPortletAdapter
    • CWebProxy
    • CApplet
    • CGenericXSLT
    • CImage
    • CInlineFrame
    • CPersonAttributes
• Adopt a policy that no new channels implementing IMultithreaded*will be accepted into the framework (uPortal source tree) if they implement IMultithreaded*
• Propose a presentation for JA-SIG Vancouver conference "Why IMultithreaded is Deprecated and How to Refactor Your Channels away from IMultithreaded"