[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-users] Weaving and targetEntity
|
Hi Zeb,
The bug you list below is exactly the bug that covers this situation.
It is possible that PROPERTY access will avoid this issue. It might be worth
giving it a try in a small scenario to verify.
Anyone reading this thread who is running into this issue should vote for
this bug.
-Tom
Zeb Ford-Reitz wrote:
Hi Tom,
Thanks for the quick response. Your assumption is correct. I opted to go
directly for static weaving because dynamic sounded like it might be too
much of a hassle.
The stack trace that I'm seeing looks like this:
java.lang.IllegalStateException: Can't overwrite cause
at java.lang.Throwable.initCause(Throwable.java:320)
at
org.eclipse.persistence.exceptions.DescriptorException.errorAccessingSetMethodOfEntity(DescriptorException.java:391)
at
org.eclipse.persistence.internal.indirection.WeavedObjectBasicIndirectionPolicy.getSetMethod(WeavedObjectBasicIndirectionPolicy.java:87)
at
org.eclipse.persistence.internal.indirection.WeavedObjectBasicIndirectionPolicy.setRealAttributeValueInObject(WeavedObjectBasicIndirectionPolicy.java:131)
at
org.eclipse.persistence.internal.indirection.WeavedObjectBasicIndirectionPolicy.updateValueInObject(WeavedObjectBasicIndirectionPolicy.java:99)
at
org.eclipse.persistence.internal.indirection.WeavedObjectBasicIndirectionPolicy.getRealAttributeValueFromObject(WeavedObjectBasicIndirectionPolicy.java:67)
at
org.eclipse.persistence.mappings.ObjectReferenceMapping.cascadeRegisterNewIfRequired(ObjectReferenceMapping.java:822)
at
org.eclipse.persistence.mappings.ObjectReferenceMapping.cascadeRegisterNewIfRequired(ObjectReferenceMapping.java:802)
at
org.eclipse.persistence.internal.descriptors.ObjectBuilder.cascadeRegisterNewForCreate(ObjectBuilder.java:1685)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNewObjectForPersist(UnitOfWorkImpl.java:4212)
at
org.eclipse.persistence.internal.jpa.EntityManagerImpl.persist(EntityManagerImpl.java:403)
at
org.eclipse.jubula.client.core.persistence.ProjectPM.saveProject(Unknown
Source)
at
org.eclipse.jubula.client.archive.businessprocess.FileStorageBP$CompleteImportOperation.importProject(Unknown
Source)
at
org.eclipse.jubula.client.archive.businessprocess.FileStorageBP$CompleteImportOperation.run(Unknown
Source)
at
org.eclipse.jubula.client.archive.businessprocess.FileStorageBP$ImportOperation.run(Unknown
Source)
at
org.eclipse.jubula.client.archive.businessprocess.FileStorageBP.doImport(Unknown
Source)
at
org.eclipse.jubula.client.archive.businessprocess.FileStorageBP.importProject(Unknown
Source)
at
org.eclipse.jubula.client.ui.businessprocess.ImportFileBP$3.run(Unknown
Source)
at
org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
You may actually already be aware of the issue. It seems to me that it's
at least similar to:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282523
Thanks again for the help.
- Zeb
Tom Ware wrote:
Hi,
I assume this is the first time you have used our weaving support?
(i.e. you are not seeing this issue when converting from dynamic to
static weaving)
Our weaving code may not be using targetEntity to account for the
fact that your may be using interfaces in your model to represent the
relationships. Can you please post the stack trace of one of the
exceptions you are seeing?
-Tom
Zeb Ford-Reitz wrote:
Hello,
I'm in the process of adding static weaving to our application and
have run into a bit of a problem. All of my relationship targets are
interfaces that have a single implementer, so I use the
"targetEntity" property liberally in my mapping annotations.
For example, where class B implements interface IB, the getter and
setter in class A look like:
private IB b;
@OneToOne(cascade = CascadeType.ALL,
targetEntity = B.class,
fetch = FetchType.LAZY)
public IB getB() {
return b;
}
public void setB(IB newB) {
b = newB;
}
This worked without any issues until I enabled static weaving. Now,
whenever I try to persist an entity, I receive a
java.lang.NoSuchMethodException indicating that there is no setter
method with the appropriate signature. What confuses me is that
(considering the example above) the desired setter method signature
is "setB(B)", whereas I would expect it to be "setB(IB)". Am I
missing some obvious configuration or setting that would allow the
interfaces to be used instead of the concrete classes?
Best regards,
Zeb Ford-Reitz
------------------------------------------------------------------------
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
------------------------------------------------------------------------
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users