dm Server
  1. dm Server
  2. DMS-181

Investigate problem with runtime creation of CGLib proxies

    Details

    • Type: Defect Defect
    • Status: Done Done
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: Sprint 4, 2.0.0.M2, 2.0.0.RELEASE
    • Component/s: None
    • Labels:
      None
    • Story Points:
      1

      Description

      ENGINE-1444

        Activity

        Hide
        Chris Frost added a comment -

        Andy Wilkinson added a comment - 14/Aug/08 03:30 PM
        The root cause of the problem is that the type being proxied, OrdinaryUser, is package-private. During application context initialization OWACL is asked to load the OrdinaryUser class, and it delegates to the PlatformBundleClassLoader for the WAR's bundle from where it's loaded. When the proxy is created OWACL is the thread context class loader so it's used to create the proxy. This fails as OWACL cannot see OrdinaryUser as it's package-private and was loaded by a different classloader.

        This problem does not occur on Tomcat as there is only a single classloader involved for the Web application.

        It could be argued that this is a bug in TeamCity, e.g. if, when running on Tomcat, the JAR that contains the OrdinaryUser class was moved into Tomcat's common area, it would be loaded by a different class loader and the proxying attempt would fail.
        [ Show » ]
        Andy Wilkinson added a comment - 14/Aug/08 03:30 PM The root cause of the problem is that the type being proxied, OrdinaryUser, is package-private. During application context initialization OWACL is asked to load the OrdinaryUser class, and it delegates to the PlatformBundleClassLoader for the WAR's bundle from where it's loaded. When the proxy is created OWACL is the thread context class loader so it's used to create the proxy. This fails as OWACL cannot see OrdinaryUser as it's package-private and was loaded by a different classloader. This problem does not occur on Tomcat as there is only a single classloader involved for the Web application. It could be argued that this is a bug in TeamCity, e.g. if, when running on Tomcat, the JAR that contains the OrdinaryUser class was moved into Tomcat's common area, it would be loaded by a different class loader and the proxying attempt would fail.

        Andy Wilkinson added a comment - 10/Oct/08 12:25 PM
        To resolve this issue we will have to change the classloader structure for Web applications. Note that this is something that we will have to do anyway if we want to pass the Java EE 6 Web profile's TCK. We could restrict the changes to only WAR-based web applications, i.e. OSGi web modules would not be affected.

        Show
        Chris Frost added a comment - Andy Wilkinson added a comment - 14/Aug/08 03:30 PM The root cause of the problem is that the type being proxied, OrdinaryUser, is package-private. During application context initialization OWACL is asked to load the OrdinaryUser class, and it delegates to the PlatformBundleClassLoader for the WAR's bundle from where it's loaded. When the proxy is created OWACL is the thread context class loader so it's used to create the proxy. This fails as OWACL cannot see OrdinaryUser as it's package-private and was loaded by a different classloader. This problem does not occur on Tomcat as there is only a single classloader involved for the Web application. It could be argued that this is a bug in TeamCity, e.g. if, when running on Tomcat, the JAR that contains the OrdinaryUser class was moved into Tomcat's common area, it would be loaded by a different class loader and the proxying attempt would fail. [ Show » ] Andy Wilkinson added a comment - 14/Aug/08 03:30 PM The root cause of the problem is that the type being proxied, OrdinaryUser, is package-private. During application context initialization OWACL is asked to load the OrdinaryUser class, and it delegates to the PlatformBundleClassLoader for the WAR's bundle from where it's loaded. When the proxy is created OWACL is the thread context class loader so it's used to create the proxy. This fails as OWACL cannot see OrdinaryUser as it's package-private and was loaded by a different classloader. This problem does not occur on Tomcat as there is only a single classloader involved for the Web application. It could be argued that this is a bug in TeamCity, e.g. if, when running on Tomcat, the JAR that contains the OrdinaryUser class was moved into Tomcat's common area, it would be loaded by a different class loader and the proxying attempt would fail. Andy Wilkinson added a comment - 10/Oct/08 12:25 PM To resolve this issue we will have to change the classloader structure for Web applications. Note that this is something that we will have to do anyway if we want to pass the Java EE 6 Web profile's TCK. We could restrict the changes to only WAR-based web applications, i.e. OSGi web modules would not be affected.

          People

          • Assignee:
            Rob Harrop
            Reporter:
            Anonymous
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 2h
              2h
              Remaining:
              0h
              Logged:
              Time Not Required
              1m