CaptchaImpl creates Captcha instance with the wrong class loader

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 5.1.2, 5.2.3, 6.0.5 GA
• Fix Version/s: --Sprint - SP, 6.1.0 CE RC1
• Component/s: WCM
• Labels: None
• Branch Version/s:
  5.1.x, 5.2.x, 6.0.x
• Backported to Branch:
  Committed
• Similar Issues: Show 5 results ; ;

  LPS-25721	LayoutLocalServiceImpl uses wrong class loader
  LPS-15727	Wrong class loader used when propagating the filter chain from a hook plugin filter
  LPS-3378	Poller processor is using wrong class loader for plugins
  LPS-18364	AssetRenderer fails for Journal/Web Content utilising template when embeded in custom portlet due to incorrect class loader
  LPS-850	Struts request processor sometimes loaded with wrong class loader

CaptchaImpl wires "Captcha" instances 2 ways:

1.) The plugin sets the instance using the plugin's class loader. This is how Hooks override the default Captcha implementation. This works all the time.

2.) The portal sets the name of the Captcha class, but does initialize it on startup, to make startup speed faster.

The first time a user hits a page that requires a captcha, it will now try and initialize the Captcha (if we're using the portal one and not the hook). This will work MOST of the time because the class loader for the class initialization is the correct one - the portal's. Sometimes, the thread context class loader may be a plugin's, which will then cause it to break.

Since this block is never reached except by the portal, the fix is to have it use the portal class loader all the time.