I'm using Mustache templates with the spring OpenAPI Generator to generate Java interfaces from an OpenAPI spec.
I'm trying to make them generate #GetMapping, #PostMapping instead of using RequestMapping(method = RequestMethod.GET). I have the http method as a variable (e.g. "GET"), and I need to make it title case. The docs say there is a lambda for this, but it doesn't seem to work.
Here is my input:
#{{#lambda.titlecase}}{{httpMethod}}{{/lambda.titlecase}}Mapping(
And the output code looks like this:
#GETMapping(
... which of course doesn't compile - it needs to be GetMapping.
I've tried plain text:
#{{#lambda.titlecase}}BOB{{/lambda.titlecase}}Mapping(
produces:
#BOBMapping
What am I doing wrong? Do I need to somehow configure the generator to switch on these lambdas? Or perhaps the spring code generator doesn't come with these lambdas - in which case what other options are there?
Related
Was writing some Quarkus test and I had issues trying to mock the .persist() method.
If a method contains optional parameters such as it does in the persist method, you have to capture those even if your code is not using them. I was able to do that by just using they any() matcher as shown below.
Mockito.when(query.firstResult()).thenReturn(null);
PanacheMock.mock(MyDAO.class);
Mockito.when(MyDAO.find(Mockito.any(String.class), Mockito.any(Object.class))).thenReturn(query);
Note you can just replace the Mockito.any(String.class) with whatever matcher you want.
A question about code generation based on a scheme, before that I worked with REST, for it there is a code generator (openapi codegen) that outputs a ready-made service (class) at the output, with the translation of fields from snake-style to camel-style, type checks, etc. P.
Is there such a thing for GraphQl, tried graphql-code-generator - it outputs not a class / service, but only type interfaces.
I'm trying to understand spring cloud contract so am reading the tour.
My question is specifically regarding this section:
https://cloud.spring.io/spring-cloud-contract/multi/multi__spring_cloud_contract_verifier_introduction.html#_defining_the_contract
Looking at the request body part, there is a difference between the Groovy and YAML contracts.
In the Groovy DSL:
"client.id": $(regex('[0-9]{10}'))
In the YAML:
"client.id": 1234567890
You can see the difference - one is specific, the other is not.
Questions are:
Q1. Is this difference deliberate?
Q2. Is it correct that these are turned into tests on the Producer side, so they are run against my real implementation of the service?
So does that mean my real implementation needs to support the hard coded client.id of 1234567890?
TIA
The difference is such that in Groovy DSL we can code sth and YAML is just declarative. In Groovy, in the body, we can state that the value of a particular part of the body will be dynamic. Then at runtime we will generate the fixed value (e.g. for the generated tests). You could also achieve the same via the bodyMatchers section.
In Yaml however you can't code. You need to provide a fixed value and if you want to have a dynamic part of that particular e.g. body element then you have to provide that value in the matchers sections. That will tell the framework that there is a fixed value for e.g. generated tests BUT also there's a dynamic part to consider e.g. for the stub.
I am writing a brand new custom doclet using JDK 1.7. These are the problems I have found so far:
Doc methods isAnnotationType(), isAnnotationTypeElement(), isEnum() and isEnumConstant() do not work. They always return false.
PackageDoc method enums() does not work. It always returns an empty array. Enums are included in the result of methods allClasses() and ordinaryClasses().
ClassDoc method enumConstants() does not work. It always returns an empty array. Enum constants are included in the result of method fields().
PackageDoc method annotationTypes() does not work. It always returns an empty array. Annotations are included in the result of method interfaces(), so I could implement the following work-around:
AnnotationTypeDoc annotationDoc;
ClassDoc[] interfaces = packageDoc.interfaces();
for (ClassDoc classDoc : interfaces) {
if (classDoc instanceof AnnotationTypeDoc) {
annotationDoc = (AnnotationTypeDoc) classDoc;
} else {
continue;
}
process(annotationDoc);
}
Based on something that I found in the "What's New in Javadoc 5.0" page (http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/whatsnew-1.5.0.html) I am guessing that, even though I am writing it with JDK 1.7, my doclet is working in some kind of pre-5.0 compatibility mode. This is what I found in the "What's New in Javadoc 5.0" page:
Incompatibilities with Custom Doclets
Custom doclets written prior to 5.0 will have compatibility problems when run on source files that use new language features in 5.0.
New Language Features: The Doclet API and standard doclet were revised to handle the new 5.0 language features -- generics, enums, varargs and annotations.
To handle these features, custom doclets would also need to be revised.
The Javadoc tool tries -- to the extent possible -- to present so-called "legacy" doclets with a view of the program that
1) continues to work with pre-5.0 source code, and
2) matches their expectations for 5.0 source code.
So, for example, type parameters and type arguments are stripped from generic constructs, type variables and wildcard types are replaced by their erasures, and ClassDoc.fields() will return enum constants.
Solved! It really was working in pre-5.0 compatibility mode. All I had to do to was to add the following method to my custom doclet:
public static LanguageVersion languageVersion() {
return LanguageVersion.JAVA_1_5;
}
I am working on a REST service which uses Spring 4.x. As per a requirement I have to produce several different views out of same object. Sample URIs:
To get full details of a location service: /services/locations/{id}/?q=view:full
To get summary of a location service: /services/locations/{id}/?q=view:summary
I have thought of two solutions for such problem:
1. Create different objects for different views.
2. Create same object, but filter out the fields based on some configuration (shown below)
location_summary_fields = field1, field2
location_detail_fields = field1, field2, field3
Could someone help me to understand what could be an ideal solution? I am not aware of any standard practice followed for this kind of problems.
Thanks,
NN
In my opinion the best option is to use separate POJOs for different views. It's a lot easier to document it (for example when you use some automated tools like Swagger). Also you've to remember that your application will change after some time, and then having one common POJO could make troubles - then you'll need to add one field to one service and don't expose it through another.
See this article on how google gson uses annotations to convert a Java Object representation to a json format : http://www.javacreed.com/gson-annotations-example/
Since you want two different representations for the same object you could roll your own
toJson method as follows :
a) Annotate each field of you model with either #Summary, #Detail or #All
b) Implement a toJson() method that returns a json representation by examining the annotations for the fields and appropriately using them
If you need an XML representation same thing, except you would have a toXML().