Abstract DataObject as property type generate an impossible converter
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by reproducing the generated converter shown for TestObjectWithInterfaceField, TestInterface, and TestInterfaceImpl, then trace the code-generation path that handles abstract DataObject property types. Done means generation no longer emits an impossible interface construction and the resulting converter has defined JSON behavior for the interface field.
Written by the indexing model from the issue text.
Description
If you make a DataObject of this kind
@DataObject(generateConverter = true)
public class TestObjectWithInterfaceField {
private TestInterface anInterface = new TestInterfaceImpl();
public TestObjectWithInterfaceField() {
}
public TestObjectWithInterfaceField(JsonObject object){
}
public TestInterface getAnInterface() {
return anInterface;
}
public void setAnInterface(TestInterface anInterface) {
this.anInterface = anInterface;
}
}
with TestInterface as :
@DataObject
public interface TestInterface {
String getString();
}
the generated converted is :
public class TestObjectWithInterfaceFieldConverter {
public static void fromJson(JsonObject json, TestObjectWithInterfaceField obj) {
if (json.getValue("anInterface") instanceof JsonObject) {
obj.setAnInterface(new TestInterface((JsonObject)json.getValue("anInterface")));
}
}
public static void toJson(TestObjectWithInterfaceField obj, JsonObject json) {
}
}
Obviously, converter isn't usable, even valid... is it fixable?
- Dominant language
- Java
- Stars
- 111
- Forks
- 88
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from eclipse-vertx/vertx-codegen
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
eclipse-vertx/vertx-codegen#361 ·
-
help wanted
Difficulty 4/5 3-5 days Newbie friendliness 35/100
eclipse-vertx/vertx-codegen#340 · 11 comments · 2 reactions ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
eclipse-vertx/vertx-codegen#335 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 25/100
eclipse-vertx/vertx-codegen#320 · 4 comments ·
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 45/100
eclipse-vertx/vertx-codegen#319 · 1 comment · 1 reaction ·
All issues in eclipse-vertx/vertx-codegen
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
apache/rocketmq-dashboard#6110 ·
Maintainers usually reply within 4 days
-
`Processing lsp` never exits and leaves orphaned processesPossibly taken @overcast302 claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
processing/processing4#1578 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
Maintainers usually reply within 1 day
-
[BUG] S3 CORS responses omit Access-Control-Allow-Credentials for matched originsPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
floci-io/floci#5369 · 1 comment ·
Maintainers usually reply within 1 day
-
securityHeaders replaces a route's own Content-Security-Policy (0.9.9; weakens embedders' pages)Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day