Re: [eclipselink-users] Dyn. Weaving, Lazy Collection, Clone Problem

[Oliver Vesper <oliver.vesper@xxxxxx>]

Hi Tom,

thanks for these hints, looking at the decompiled weaved classes is 
quite interesting. :) My _persistence_shallow_clone() method looked like 
the one of your test-class. So I removed the @CopyPolicy annotation from 
my entity and instead I provided a custom clone method like this:

@CloneCopyPolicy(method = "myCloneMethod", workingCopyMethod = 
"myCloneMethod")
class Bar {
  protected Object myCloneMethod() throws CloneNotSupportedException {
    final Bar clone = (Bar) super.clone();
    clone.pcs = new PropertyChangeSupport(clone);
    return clone;
  }
}

And it works as expected, so thank you very much!

Btw: Although the documentation states that I'd have to specify either 
"method" or "workingCopyMethod" (or both) in the annotation, I have to 
specify both. Don't know if it's just a mistake in the documentation.

-Oliver

Tom Ware schrieb:
> Hi Oliver,
>
>   If you want to see what any of your weaved classes do, you can do it 
> with the combination of a set of properties and a java decompiler.
>
>   Set the two system properties:
>
> eclipselink.weaving.output.path=<path>
> eclipselink.weaving.overwrite.existing=true
>
>   The output of the weaving process will go to <path>.  You should be 
> able to decompile those class files.
>
>   Here is a sample _persistence_shallow_clone() from one of our test 
> classes:
>
>
>     public Object _persistence_shallow_clone()
>     {
>         return super.clone();
>     }
>
>   The main impact of implementing your own clone method is that you take 
> responsibility for ensuring everything is cloned.  There may be very 
> minor performance impact, but it is likely almost negligible when done 
> for just one class.
>
> -Tom