Community
Participate
Working Groups
If you create a converter based error and then override that entity with an eclipselink-orm.xml you will hit the following exception. To reproduce you simply reference a non-existing converter in a Java entity, then add that entity to your eclipselink-orm.xml. I hit this reproducing bug 339418. Null text range for message ID: ID_MAPPING_UNRESOLVED_CONVERTER_NAME java.lang.IllegalArgumentException: Null text range for message ID: ID_MAPPING_UNRESOLVED_CONVERTER_NAME at org.eclipse.jpt.jpa.eclipselink.core.internal.DefaultEclipseLinkJpaValidationMessages.buildMessage(DefaultEclipseLinkJpaValidationMessages.java:48) Full stack is attached.
Created attachment 195794 [details] Stack trace
This results in there being no source location for the validation error.
Created attachment 196034 [details] patch 1 Candidate patch. Requires Pascal's patch from bug 339418.
Pascal's patch fixes the problem where we do not detect that a Java attribute mapping is "virtual" when it is part of a type mapping in an EclipseLink orm.xml file (as opposed to a generic orm.xml file). The patch attached to this bug addresses a number of problems with EclipseLink converters: Converters cannot use a reserved name ("none", "class-instance", or "serialized"). There is no such thing as a "virtual" converter. Java converters defined on a Java type mapping or attribute mapping is still active when the Java mapping is overridden in the orm.xml file. Overridden converters should not be validated. Invalid Java converters should be marked as such in the *Java* source file, as opposed the corresponding orm.xml file mapping element. These changes uncovered some bugs in how the UI listens for changes to the list of converters in a persistence unit. These are fixed.
With the patch applied, I got an NPE(stack trace attached) and no validation message show up even when no eclipselink-orm.xml is involved. The ID mapping I have is @Id @Convert("BALABA") @Converter(converterClass = Foo.class, name = "CONV") private int id1;
Created attachment 196055 [details] Stack Trace
Tried to get this fixed for RC2 but didn't have enough time. Targeting to RC3 and will evaluate whether or not it is appropriate for RC3 when the fix is complete.
(In reply to comment #7) > Tried to get this fixed for RC2 but didn't have enough time. Targeting to RC3 > and will evaluate whether or not it is appropriate for RC3 when the fix is > complete. oops..wrong bug. please ignore the last comment.
(In reply to comment #5) > With the patch applied, I got an NPE(stack trace attached) and no validation > message show up even when no eclipselink-orm.xml is involved. The ID mapping I > have is > > @Id > @Convert("BALABA") > @Converter(converterClass = Foo.class, name = "CONV") > private int id1; This problem is cause by the validation of converter class and should be a separate problem so it will be tracked in another bug. The patch can be verified with other types of converters.
Fix is too big for RC's...targeting to maintenance. We will fix invalid validation by removing it in RC3.
Created attachment 196364 [details] patch 2 This patch fixes the NPE described in comment 5 (and bug 346498) which was caused by an oversight in patch 1. (As a hack) converter validation is passed a null instead of an AST. This was OK for calculating text ranges, since the appropriate Dali annotations now cache their text ranges; but caused a NPE because the AST is also being used to determine the converter class's inheritance tree. We now use the JDT model (as opposed to the AST) to determine the converter class's inheritance. This patch also includes a modified version of the patch for bug 339418; so that patch no longer needed.
These problems have been reduced in severity with the fix for bug 346535. These changes (patch 2) need to be resolved with the changes in 346535 in head.
Moving JPA specific bugs to new JPA component in bugzilla.
I think these changes have already gone in. I can no longer reproduce this issue. Let me know if there was anything else needed here Brian.
