Add a compile-time switch for RPC enhanced classes - #10386
Conversation
niloc132
left a comment
niloc132
left a comment
There was a problem hiding this comment.
Thanks for working on this! A few comments:
| return Boolean.parseBoolean(prop.getValues().get(0)); | ||
| } | ||
| } catch (BadPropertyValueException e) { | ||
| // Preserve the historical behavior when compiling without the new property. |
There was a problem hiding this comment.
Why do we need this, given that you also changed RemoteService.gwt.xml?
There was a problem hiding this comment.
Agreed—the inherited module normally guarantees the property. I kept only a warned, backwards-compatible fallback for custom modules that replace or do not inherit RemoteService.gwt.xml: a missing or malformed value now logs a warning and returns true.
| Controls whether RPC generates support for server-enhanced classes. Set | ||
| this to false to ignore both JPA/JDO annotations and the | ||
| rpc.enhancedClasses list, preventing @ClientFields entries and the | ||
| corresponding client-side payload handling from being generated. |
There was a problem hiding this comment.
Maybe tie this back to the actual server behavior being lost through this?
Something like
| corresponding client-side payload handling from being generated. | |
| corresponding client-side payload handling from being generated | |
| and so the server from seeing JPA/JDO fields returned to it from | |
| client calls |
There was a problem hiding this comment.
Updated the module documentation to make the server-side consequence explicit: when disabled, the server cannot see the JPA/JDO fields returned to it from client calls.
| */ | ||
|
|
||
| if (serializableClass.isEnhanced()) { | ||
| if (Shared.isEnhancedClass(context.getPropertyOracle(), serializableClass)) { |
There was a problem hiding this comment.
This seems very late to check this - could we instead just not set isEnhanced as you've already done so that this check fails?
There was a problem hiding this comment.
Done. I removed the late property checks and restored the direct serializableClass.isEnhanced() checks. The builder now remains the single place that decides whether to mark a type as enhanced.
| * Returns whether the type should be treated as enhanced for the current compilation. | ||
| */ | ||
| static boolean isEnhancedClass(PropertyOracle propertyOracle, JClassType type) { | ||
| return shouldEnableEnhancedClasses(propertyOracle) && type.isEnhanced(); |
There was a problem hiding this comment.
If we do need this, contrary to my comment in FieldSerializerCreator, let's swap the && and do the cheap field check before the map lookups
There was a problem hiding this comment.
Removed Shared.isEnhancedClass entirely, so there is no property lookup at this late stage. FieldSerializerCreator and ProxyCreator now use the direct isEnhanced() checks again.
Signed-off-by: kamex <kamexETH@users.noreply.github.com>
2 participants
Add the single-valued
rpc.enhancedClasses.enabledconfigurationproperty, defaulting to
truefor compatibility.When set to
false, RPC ignores both JPA/JDO enhancement annotations andthe
rpc.enhancedClasseslist. Generated field serializers omit the opaqueserver-enhanced payload, serialization policies omit
@ClientFields, and theserver no longer sees those JPA/JDO fields when clients return them.
Missing, malformed, or multi-valued settings log a warning and retain the
backwards-compatible enabled behavior. The enhanced-class settings are also
included in RPC generator cache validation, preventing field serializers
generated under different settings from being reused.
Tests:
ant -f user/build.xml -Dgwt.nongwt.testcase.includes="**/RpcJreSuite.class" test.nongwtant -f user/build.xml checkstyleFixes #9881