Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-12833

Unable to use Configuration classes in signed jar due to CGLIB

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: 4.1.4
    • Fix Version/s: 4.2.3
    • Component/s: Core

      Description

      When using Java Configuration from a signed jar (in a multi-module project), I get an error stating that the class enhanced by CGLIB doesn't have the same signer information than other classes from the same package.

      Looking into ConfigurationClassPostProcessor and related classes code it appears that classes annotated with @Configuration will always be enhanced using CGLIB (I've plenty of other classes in the same module that work fine but they are apparently enhanced using JDK proxy).

      Is there a way to use Java Configuration from a signed jar ? Or to have @configuration classes enhanced using JDK proxy ? (I tried giving them interfaces with no luck).

        Issue Links

          Activity

          Hide
          juergen.hoeller Juergen Hoeller added a comment -

          @Configuration classes currently always get enhanced via CGLIB. This can't happen through interface-based proxies since it's about a runtime-generated subclass which overrides all @Bean methods... in order to intercept them for cross-reference calls between @Bean methods.

          That said, there is a 'lite' mode of @Bean processing where we don't apply any CGLIB processing: simply declare your @Bean methods on classes not annotated with @Configuration (but typically with another Spring stereotype instead, e.g. @Component). As long as you don't do programmatic calls between your @Bean methods, this is going to work just as fine.

          Of course, the real problem is that CGLIB doesn't seem to work with signed jars. We'll see whether there's anything we can do about this. After all, there are quite a few Spring features which happen to apply CGLIB.

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - @Configuration classes currently always get enhanced via CGLIB. This can't happen through interface-based proxies since it's about a runtime-generated subclass which overrides all @Bean methods... in order to intercept them for cross-reference calls between @Bean methods. That said, there is a 'lite' mode of @Bean processing where we don't apply any CGLIB processing: simply declare your @Bean methods on classes not annotated with @Configuration (but typically with another Spring stereotype instead, e.g. @Component ). As long as you don't do programmatic calls between your @Bean methods, this is going to work just as fine. Of course, the real problem is that CGLIB doesn't seem to work with signed jars. We'll see whether there's anything we can do about this. After all, there are quite a few Spring features which happen to apply CGLIB. Juergen
          Hide
          denis.carniel@loginpeople.com Denis Carniel added a comment -

          Thanks for the workaround, that worked for me.

          I guess that ticket can be kept to track the general issue of using CGLIB and signed jars, but I'll lower the priority.

          Denis

          Show
          denis.carniel@loginpeople.com Denis Carniel added a comment - Thanks for the workaround, that worked for me. I guess that ticket can be kept to track the general issue of using CGLIB and signed jars, but I'll lower the priority. Denis
          Hide
          dimafeng Dmitry Fedosov added a comment -

          Hello, I found out that this issue has been solved in original CGLIB repository - https://github.com/cglib/cglib/commit/f9d2f6cef31615d2dd98b3d41ca7de4b6294f2a0
          Are you planning to merge these changes into your version of CGLIB?

          My team is using this CGLIB proxies for AOP, but we have to distribute out app via Java Web Start, so, all jars should be signed. For now, we got stuck with a class loader with disabled security checkings. It would be great, if we could get rid of this workaround.

          Show
          dimafeng Dmitry Fedosov added a comment - Hello, I found out that this issue has been solved in original CGLIB repository - https://github.com/cglib/cglib/commit/f9d2f6cef31615d2dd98b3d41ca7de4b6294f2a0 Are you planning to merge these changes into your version of CGLIB? My team is using this CGLIB proxies for AOP, but we have to distribute out app via Java Web Start, so, all jars should be signed. For now, we got stuck with a class loader with disabled security checkings. It would be great, if we could get rid of this workaround.
          Hide
          juergen.hoeller Juergen Hoeller added a comment - - edited

          In contrast to our ASM fork, we do not maintain a CGLIB fork of our own; we're just repackaging CGLIB 3.1 proper. So in order to pick up CGLIB changes since 3.1, we'd really need a new CGLIB release in Maven Central.

          I've been waiting for CGLIB 3.2 for quite a while already. The work seems to have been done, but no release has been made available yet. Feel free to raise this with the CGLIB team and push for a release on their side!

          Juergen

          Show
          juergen.hoeller Juergen Hoeller added a comment - - edited In contrast to our ASM fork, we do not maintain a CGLIB fork of our own; we're just repackaging CGLIB 3.1 proper. So in order to pick up CGLIB changes since 3.1, we'd really need a new CGLIB release in Maven Central. I've been waiting for CGLIB 3.2 for quite a while already. The work seems to have been done, but no release has been made available yet. Feel free to raise this with the CGLIB team and push for a release on their side! Juergen

            People

            • Assignee:
              juergen.hoeller Juergen Hoeller
              Reporter:
              denis.carniel@loginpeople.com Denis Carniel
              Last updater:
              Stéphane Nicoll
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                2 years, 14 weeks, 3 days ago