CDV ❯ fix issues with class "export" feature

• Type: New Feature
• Status: Open
• Priority: 2 Major
• Resolution:
• Component/s: Byte Code Transform
• Labels:

• Assignee: prodmgmt
• Reporter: teck
• Created: March 30, 2009
• Votes: 0
• Watchers: 0
• Updated:

  May 18, 2010
• Resolved:

Description

A TIM can call TerracottaConfiguratorModule.addExportedBundleClass(..) to expose types present in the TIM bundle out to application land.

There are two aspects of the class export feature that problematic though:

1) explicit calls to loadClass(String) will bypass the export mechanism. Our hook is in ClassLoader.loadClassInternal() which is only invoked for implicit class loads. More than once we’ve changed code to use the 3 argument form of Class.forName() to workaround this.

2) There is no way to target specific loaders (other than the system classloader). Provided you’re no targeting the system loader, the exported class will get defined in the initiating loader always. This might not be what you want and tim-session-commons and tim-jetty-6.1 have to specific work against class export since a specific loader should “see” exported types.

Comments

Tim Eck 2010-05-18

part (1) of this is actually fixed as a side effect of the changes made to support JDK 6u18+. We now inspect every subclass of ClassLoader and get in the path of loadClass() (as opposed to only loadClassInternal())