[GLASSFISH-2546] Dynamic Weaving causes NoSuchMethodError when setting related object Created: 04/Mar/07  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: entity-persistence
Affects Version/s: 9.0pe
Fix Version/s: not determined

Type: Bug Priority: Minor
Reporter: spatula Assignee: tware
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: All

Attachments: Java Source File Message.java     Java Source File MessageRoot.java     Java Source File MessageService.java    
Issuezilla Id: 2,546


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:

@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:

at net.spatula.tally_ho.model.Message.setRoot(Message.java:169)

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.

Comment by spatula [ 04/Mar/07 ]

Created an attachment (id=776)
Message.java class (work in progress; sorry for the mess)

Comment by spatula [ 04/Mar/07 ]

Created an attachment (id=777)
MessageRoot.java class; (work in progress; sorry for the mess)

Comment by spatula [ 04/Mar/07 ]

Created an attachment (id=778)
MessageService.java; look at createMessage for the setRoot call.

Comment by tware [ 05/Mar/07 ]

How are you running your application? Are you in an application server? Are
you running in JavaSE?

Do you see the same problem when you use Static Weaving? See the "Static
Weaving Using the StaticWeave Class on the Command Line" or "Static Weaving
Using the weave Ant Task" section in the link below for instructions.


Comment by spatula [ 05/Mar/07 ]

Sorry I should have been more clear about that. This is running outside of a
container from a Junit test in Eclipse. I'll give static weaving a try and see
if the same thing happens.

Comment by spatula [ 06/Mar/07 ]

Static weaving also fails, but in a different and unrelated way (it claims it
cannot find one of the Entity classes, although verbose:class shows that it was
loaded from the woven jar file, and Toplink's debugging shows that it was
configured during startup).

Comment by pkrogh [ 07/Mar/07 ]

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
  • use property access.

I have tested both of these and they work.

Downgraded because there are simple work arounds.

Comment by tware [ 07/Mar/07 ]

To fix:

In TopLinkClassWeaver.visitEnd() change the following line:

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


if (attributeDetails.isMappedWithAttributeAccess()){

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

Comment by spatula [ 03/Nov/07 ]

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.

Comment by tware [ 05/Nov/07 ]

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.

Comment by Tom Mueller [ 06/Mar/12 ]

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

Generated at Tue Mar 31 03:48:07 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.