Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 341564

Summary: Need better handling of mismatch of property name, field, getters, setters, etc.
Product: z_Archived Reporter: Konstantin Komissarchik <konstantin>
Component: SapphireAssignee: Konstantin Komissarchik <konstantin>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: ling.hao
Version: unspecifiedKeywords: plan
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Konstantin Komissarchik CLA 2011-03-31 20:05:40 EDT
Sapphire requires that the various part of the property definition block match...

1. Name of the static field holding the property object.
2. Name of the property in the property object's constructor.
3. Names of getters and setters.

If a mismatch is found, the annotation processor does not surface it in the way that the user can easily react to. Generally developers notice that there is a problem when an element implementation class isn't generated. If Eclipse is running with a console, there is a stack trace like the following on standard error, but most of the time you don't run Eclipse with a console.

java.lang.IllegalStateException: Unable to find getter method for ISOAPBinding@PROP_NAME
	at org.eclipse.sapphire.modeling.annotations.processor.GenerateImplProcessor.processValuePropertyInternal(GenerateImplProcessor.java:497)
	at org.eclipse.sapphire.modeling.annotations.processor.GenerateImplProcessor.processValueProperty(GenerateImplProcessor.java:382)
	at org.eclipse.sapphire.modeling.annotations.processor.GenerateImplProcessor.process(GenerateImplProcessor.java:242)
	at org.eclipse.sapphire.modeling.annotations.processor.GenerateImplProcessor.process(GenerateImplProcessor.java:114)
	at org.eclipse.sapphire.modeling.annotations.processor.Processor.process(Processor.java:89)
	at org.eclipse.sapphire.modeling.annotations.processor.Processor.process(Processor.java:48)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.dispatchToFileBasedProcessor(APTDispatchRunnable.java:656)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTInFileBasedMode(APTDispatchRunnable.java:345)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:683)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.access$1(APTDispatchRunnable.java:675)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable$1.run(APTDispatchRunnable.java:273)
	at org.eclipse.jdt.apt.core.internal.env.BuildEnv$CallbackRequestor.acceptBinding(BuildEnv.java:611)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:925)
	at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:577)
	at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:888)
	at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:859)
	at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356)
	at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:283)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:225)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2310)
	at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:150)
	at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:627)
	at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:338)
	at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
	at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:717)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:191)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:228)
	at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:281)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:284)
	at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:340)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:363)
	at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
	at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

====================

Exhibit A:

ValueProperty PROP_NAME = new ValueProperty( TYPE, "WSDL" );

Value<String> getWSDL();
void setWSDL( String value );

There are actually two problems here. The field is PROP_NAME. It should be PROP_WSDL. Fixing that, is not sufficient, however. Sapphire takes the PROP_WSDL, breaks it into words and then camel-cases it. So it is looking for property called "Wsdl", getWsdl() getter and setWsdl() setter. 

The first one is clearly an error that we just need to report better. The second one is probably a case where we are being unnecessary string. The matching could be case-insensitive.

====================

Exhibit B:

ValueProperty PROP_SERVERPORT = new ValueProperty( TYPE, "ServerPort" );

Value<String> getServerPort();
void setServerPort( String value );

In this particular case, the issue is case sensitivity. Sapphire is looking for property name "Serverport", getServerport() and setServerport(). The fix is to rename the field PROP_SERVER_PORT.

This probably should have been accepted as valid. Nothing is gained by case sensitivity here.
Comment 1 Konstantin Komissarchik CLA 2011-04-29 20:28:13 EDT
Fixed. The annotation processor is now tolerant of case differences when looking for getters and setters. If a getter or a setter still cannot be found with the more relaxed case-insensitive search, the processor puts up a proper validation error on the property instead of failing with an exception.
Comment 2 Ling Hao CLA 2011-06-09 13:55:13 EDT
Verified, I'm so glad this is now fixed, yay!