Community
Participate
Working Groups
Build Identifier: I20110526-1708 Currently, we don't support validation for binary sources since we can do nothing to fix the problems reported; however, we can get UnsupportedOperationException with our current code. E.g. if we have two generators with the same name and one of generators is in the jar file, , we'll get the exception below. ---------------- java.lang.UnsupportedOperationException at org.eclipse.jpt.jpa.core.internal.resource.java.binary.BinaryGeneratorAnnotation.getNameTextRange(BinaryGeneratorAnnotation.java:76) at org.eclipse.jpt.jpa.core.internal.context.java.AbstractJavaGenerator.getNameTextRange(AbstractJavaGenerator.java:187) at org.eclipse.jpt.jpa.core.internal.context.persistence.AbstractPersistenceUnit.extractNameTextRange(AbstractPersistenceUnit.java:2379) at org.eclipse.jpt.jpa.core.internal.context.persistence.AbstractPersistenceUnit.checkForDuplicateGenerators(AbstractPersistenceUnit.java:2367) ---------------- The solution could be 1) giving more comprehensive messages to the problems reported against sources indicating the problems co-exist with jar files; 2) making the resource of the problems reported again jar files be the jar file refer entries of the persistence.xml. We need a general solution for this. Reproducible: Always
Moving JPA specific bugs to new JPA component in bugzilla.
Targeting to Juno release.
This happens when creating validation errors for any of our project-aggregated objects: - queries - generators - (eclipselink) converters
Not sure if there is something easy we can do to improve this situation for Juno. Perhaps we could change the binary annotations to route these messages to the jar file resource in question, which is I think what we used to do. It seems to me that it would be nice to report these types of errors, especially errors involving globals that would only be discovered upon specifying a jar file reference. Perhaps we should only route these types of errors to the jars, and ignore the rest, as there would be little context to work with. Maybe that was the intent here all along.
The same code (related to queries, generators, and EclipseLink converters) that causes this exception with binary Java objects also puts markers in Java source code in projects that are on the JPA project's build path.
Created attachment 215716 [details] proposed patch More hacking, until we figure out how we want to validate binary and extra-project Java classes.
This case actually prevents the user from getting any validation, and this error message won't be a good clue to figure out what has gone wrong. This ups the relative severity of this bug.
Nan...can you do some testing with Brian's patch?
Tested the patch and it works fine. We will only get validation message for the duplicates in the source code and ignore the duplicates in the binary code.
Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. In the case were binary content has a Dali error, validation may break, resulting in no Dali validation errors being reported. Is there a work-around? If so, why do you believe the work-around is insufficient? Workaround is to fix error in binary content, but this would not be obvious. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Manual tests have been performed and the automated tests have been run. Give a brief technical overview. Who has reviewed this fix? This code makes a simple determination on whether a given validation message should be added based on the type of resource involved. If the resource in binary, we simply don't add the validation message. What is the risk associated with this fix? Fix is isolated and fairly low risk.
Patch checked into HEAD for RC1.
