glassfish
  1. glassfish
  2. GLASSFISH-2546

Dynamic Weaving causes NoSuchMethodError when setting related object

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 9.0pe
    • Fix Version/s: not determined
    • Component/s: entity-persistence
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      2,546

      Description

      Using V2 Build 37, dynamic weaving fails to correctly instrument my entity class.

      I have an entity called Message that has a 1:1 relationship with a MessageRoot
      entity. It is described like this:

      @OneToOne
      @JoinColumn(name = "root_id", referencedColumnName="object_id")
      private MessageRoot root;

      Then I have a pretty typical accessor called setRoot for setting the value of
      the related object when creating a new Message.

      Message has one unrelated Lazy-Loaded field called parent, which is a one-to-one
      back to Message. (Used to create a tree of Message objects that are also
      associated to a single MessageRoot collection.)

      The problem is that the way the root field has been instrumented / weaved
      results in a NoSuchMethodError exception being thrown upon a call to setRoot:

      java.lang.NoSuchMethodError:
      net.spatula.tally_ho.model.Message._toplink_setroot(Lnet/spatula/tally_ho/model/MessageRoot;)V
      at net.spatula.tally_ho.model.Message.setRoot(Message.java:169)
      at
      net.spatula.tally_ho.service.MessageService.createMessage(MessageService.java:94)
      at
      net.spatula.tally_ho.service.MessageServiceTest.testCreateMessage(MessageServiceTest.java:148)

      All setRoot does is this:

      public void setRoot(MessageRoot root)

      { this.root = root; }

      Unless I'm missing something, it seems like something is going very wrong with
      dynamic weaving.

      1. Message.java
        5 kB
        spatula
      2. MessageRoot.java
        3 kB
        spatula
      3. MessageService.java
        5 kB
        spatula

        Activity

        Hide
        pkrogh added a comment -

        I have reproduced this issue.

        The problem is that weaving is done on fields that don't use lazy, but when
        TopLink Essentials goes to add convenience methods, it assumes that only fields
        marked Lazy are woven.

        2 simple work arounds:

        • Mark the MessageRoot as Lazy
          OR
        • use property access.

        I have tested both of these and they work.

        Downgraded because there are simple work arounds.

        Show
        pkrogh added a comment - I have reproduced this issue. The problem is that weaving is done on fields that don't use lazy, but when TopLink Essentials goes to add convenience methods, it assumes that only fields marked Lazy are woven. 2 simple work arounds: Mark the MessageRoot as Lazy OR use property access. I have tested both of these and they work. Downgraded because there are simple work arounds.
        Hide
        tware added a comment -

        To fix:

        In TopLinkClassWeaver.visitEnd() change the following line:

        if (attributeDetails.getMapping().usesIndirection() &&
        attributeDetails.isMappedWithAttributeAccess()){

        to:

        if (attributeDetails.isMappedWithAttributeAccess()){

        This eliminates an inconsistency in how we deal with LAZY One-to-one mappings
        with FIELD access.

        Show
        tware added a comment - To fix: In TopLinkClassWeaver.visitEnd() change the following line: if (attributeDetails.getMapping().usesIndirection() && attributeDetails.isMappedWithAttributeAccess()){ to: if (attributeDetails.isMappedWithAttributeAccess()){ This eliminates an inconsistency in how we deal with LAZY One-to-one mappings with FIELD access.
        Hide
        spatula added a comment -

        Is there any hope for seeing a fix for this, since the fix is clearly outlined
        and understood?

        Can someone make that one-line change please? I could go build my own custom
        build of Toplink Essentials with the fix, but I'd much rather not diverge.

        Show
        spatula added a comment - Is there any hope for seeing a fix for this, since the fix is clearly outlined and understood? Can someone make that one-line change please? I could go build my own custom build of Toplink Essentials with the fix, but I'd much rather not diverge.
        Hide
        tware added a comment -

        Due to the available workarounds, other issues will be treated with higher
        priority by the development team. I'd be happy to help you go through the
        process of submitting the changed code yourself. It involves checking out the
        code, making the change, adding a test, and ensuring all the regression tests run.

        Show
        tware added a comment - Due to the available workarounds, other issues will be treated with higher priority by the development team. I'd be happy to help you go through the process of submitting the changed code yourself. It involves checking out the code, making the change, adding a test, and ensuring all the regression tests run.
        Hide
        Tom Mueller added a comment -

        Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.

        Show
        Tom Mueller added a comment - Bulk change to set fix version to "not determined" where the issue is open but the value is for a released version.

          People

          • Assignee:
            tware
            Reporter:
            spatula
          • Votes:
            6 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: