OpenJPA
  1. OpenJPA
  2. OPENJPA-387

Getting "java.lang.ClassNotFoundException" when loading datacache plug-in which is a class outside of OpenJPA package.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0
    • Fix Version/s: 1.0.1, 1.1.0
    • Component/s: datacache
    • Labels:
      None

      Description

      Getting "java.lang.ClassNotFoundException" when loading datacache plug-in which is a class outside of OpenJPA package.

      This happens when loading the class as DatCache plug-in but it can potentially happen to any plug-in classes that reside outside of OpenJPA package. In order to load these classes, the fix is to get the class loader (by calling findDerivedLoader with no interface loader, loader = null) to load it again when the current class loading fails and the target class is not part of OpenJPA package. The same exception is still thrown if the second attempt fail or the target class is actually part of OpenJPA.

      Please see the patch for detail changes.

      1. OPENJPA-387.patch
        3 kB
        Kevin Sutter
      2. JIRA387.zip
        2 kB
        Daniel Lee

        Activity

        Hide
        Kevin Sutter added a comment -

        Resolved 1.0.x Branch and 1.1.0 Trunk.

        Show
        Kevin Sutter added a comment - Resolved 1.0.x Branch and 1.1.0 Trunk.
        Hide
        Kevin Sutter added a comment -

        Talked this over with Daniel and we modified the patch slightly. New patch is attached as OPENJPA-387.patch. Will be committing soon...

        Show
        Kevin Sutter added a comment - Talked this over with Daniel and we modified the patch slightly. New patch is attached as OPENJPA-387 .patch. Will be committing soon...
        Hide
        Daniel Lee added a comment -

        It was good catch. The new fix is attahced. Thanks for your commentc.

        Show
        Daniel Lee added a comment - It was good catch. The new fix is attahced. Thanks for your commentc.
        Hide
        Kevin Sutter added a comment -

        Daniel,
        It looks like the patch resolves the immediate problem. Thanks. But, I have a couple of questions about the patch itself...

        With this patch, could we be accidentally be corrupting the loaderCaches? We first lookup the proper loaderCache based on the loader being
        used on the first attempt. Since the problem is surfacing with a non-null loader variable, then we have looked up an existing loaderCache (or just created one). But, then if we drop into your new code (because the class wasn't cached yet), then we null out the loader variable and try again. If this one succeeds, then we store the class into the loaderCache instance that was first accessed by the non-null loader instance. Is that what we really want to do? It seems that we may need the loaderCache lookup as part of the while loop as well. Either that, or we need more explanation on the keys being used for the loaderCache lookups.

        Second comment... Why limit the retry to packages that don't start with "org.apache.openjpa"? Why not just re-try all class lookup failures with a null class loader and see if they work? It's always possible that somebody may have named their plugin with "org.apache.openjpa.*", especially if they are just testing.

        Thanks,
        Kevin

        Show
        Kevin Sutter added a comment - Daniel, It looks like the patch resolves the immediate problem. Thanks. But, I have a couple of questions about the patch itself... With this patch, could we be accidentally be corrupting the loaderCaches? We first lookup the proper loaderCache based on the loader being used on the first attempt. Since the problem is surfacing with a non-null loader variable, then we have looked up an existing loaderCache (or just created one). But, then if we drop into your new code (because the class wasn't cached yet), then we null out the loader variable and try again. If this one succeeds, then we store the class into the loaderCache instance that was first accessed by the non-null loader instance. Is that what we really want to do? It seems that we may need the loaderCache lookup as part of the while loop as well. Either that, or we need more explanation on the keys being used for the loaderCache lookups. Second comment... Why limit the retry to packages that don't start with "org.apache.openjpa"? Why not just re-try all class lookup failures with a null class loader and see if they work? It's always possible that somebody may have named their plugin with "org.apache.openjpa.*", especially if they are just testing. Thanks, Kevin
        Hide
        Daniel Lee added a comment -

        Patch for OpenJPA 1.0.x branch

        Show
        Daniel Lee added a comment - Patch for OpenJPA 1.0.x branch
        Hide
        Daniel Lee added a comment -

        Patch for OpenJPA 1.0.0 Trunk.

        Show
        Daniel Lee added a comment - Patch for OpenJPA 1.0.0 Trunk.

          People

          • Assignee:
            Daniel Lee
            Reporter:
            Daniel Lee
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development