Stack trace observed:
java.lang.IndexOutOfBoundsException: The size must be at least 1
at io.ebeaninternal.server.deploy.id.IdBinderSimple.getIdInValueExpr(IdBinderSimple.java:135)
at io.ebeaninternal.server.deploy.BeanDescriptor.parentIdInExpr(BeanDescriptor.java:1634)
at io.ebeaninternal.server.deploy.BeanPropertyAssocManySqlHelp.addWhereParentIdIn(BeanPropertyAssocManySqlHelp.java:121)
at io.ebeaninternal.server.deploy.BeanPropertyAssocMany.addWhereParentIdIn(BeanPropertyAssocMany.java:342)
at io.ebeaninternal.api.LoadManyRequest.createQuery(LoadManyRequest.java:90)
at io.ebeaninternal.server.core.DefaultBeanLoader.loadMany(DefaultBeanLoader.java:39)
at io.ebeaninternal.server.core.DefaultServer.loadMany(DefaultServer.java:475)
at io.ebeaninternal.server.loadcontext.DLoadManyContext$LoadBuffer.loadMany(DLoadManyContext.java:215)
at io.ebean.common.AbstractBeanCollection.lazyLoadCollection(AbstractBeanCollection.java:90)
at io.ebean.common.BeanList.init(BeanList.java:141)
at io.ebean.common.BeanList.iterator(BeanList.java:327)
A parent in the Inheritance hierarchy has @DiscriminatorValue but not the @Inheritance annotation. The bug means the inherited properties are not included on the generated query bean.
The fix is to the querybean-generator to pick up inherited properties for this case.
- Requires ebean-agent to be up-to-date (13.13.2 or greater)
- Split TQAssocBean into 2, one for embeddable beans and the other for the reset
- The eq(), in() etc expressions go to TQAssoc
- Add fetch() methods to TQAssocBean
- No longer generate the fetch() methods as we now have them on TQAssocBean
- For the case where entity beans implement an interface
- Adds these expressions to the "associated" querybeans (not the root querybeans).
- The expressions added use of the interface type
Revert the use of ${revision} in poms to plain old version dur to issues not being able to use mvn --rf --resume-from ... as it complains about the parent pom version
The history behind this is that originally there was a "profileId" concept where that was a int value that could be used as an "id" for a transactional method that we wanted to profile.
That went away and then the idea was that bytecode enhancement would determine the line number and we would use that but that was a bad idea and we ended up with lineNumber always as 0.
These days with StackWalker and DProfileLocation we can do this better that way so yeah. A followup to this is to add to the api a boolean flag as to whether a profile location should be with line numbers (which can change frequently due to refactoring etc)
Rob Bygrave