You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following #9709 and the PR #9879 to mitigate this by disabling the feature, this issue is to track efforts to entirely disable it. This would allow projects to safely leave JDO/JPA annotations in their DTO sources, without needing to filter or sign/verify requests and responses.
At GWT compile time, some hint would tell the GWT-RPC codegen to not only leave the @ClientFields code out of the serialization policy, but avoid generating client code to handle those enhanced payloads. This should amount to little more than ensuring that JClassType.isEnhanced() or TypeInfoComputed.maybeEnhanced() always return false in these cases.
Disabling this could be by annotations on the DTO type itself, on the RemoteService type that the policy file would pertain to, or perhaps globally, with something like a "deny" to match the "allow" that the rpc.enhancedClasses configuration property currently allows (perhaps with wildcards, rather than excluding on a class-by-class basis).
By excluding the ClientFields directive entirely from the serialization policy file, the changes made in #9879 would never need to warn/error about these types at runtime.
The text was updated successfully, but these errors were encountered:
Following #9709 and the PR #9879 to mitigate this by disabling the feature, this issue is to track efforts to entirely disable it. This would allow projects to safely leave JDO/JPA annotations in their DTO sources, without needing to filter or sign/verify requests and responses.
At GWT compile time, some hint would tell the GWT-RPC codegen to not only leave the
@ClientFields
code out of the serialization policy, but avoid generating client code to handle those enhanced payloads. This should amount to little more than ensuring thatJClassType.isEnhanced()
orTypeInfoComputed.maybeEnhanced()
always return false in these cases.Disabling this could be by annotations on the DTO type itself, on the RemoteService type that the policy file would pertain to, or perhaps globally, with something like a "deny" to match the "allow" that the
rpc.enhancedClasses
configuration property currently allows (perhaps with wildcards, rather than excluding on a class-by-class basis).By excluding the
ClientFields
directive entirely from the serialization policy file, the changes made in #9879 would never need to warn/error about these types at runtime.The text was updated successfully, but these errors were encountered: