Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support RequestObject in DocService #1557

Merged
merged 5 commits into from Feb 1, 2019

Conversation

minwoox
Copy link
Member

@minwoox minwoox commented Jan 25, 2019

Motivation:
Currently, RequestObjects are not shown in DocService.

Modifications:

  • Rename AnnotatedBeanFactory to AnnotatedBeanFactoryRegistry
  • Add AnnotatedBeanFactory which has information about the bean factory
  • Add FieldInfoBuilder to make FieldInfo easily
  • Add FieldLocation enum
  • Change the DEFAULT in FieldRequirement to UNSPECIFIED when it's unknown
  • Bean fields are now collapsible in DocService

Result:

  • Better developer experience

@minwoox minwoox force-pushed the requestObject_docservice branch 4 times, most recently from 28a783f to 1db9c8d Compare January 29, 2019 01:23
@codecov
Copy link

codecov bot commented Jan 29, 2019

Codecov Report

Merging #1557 into master will decrease coverage by <.01%.
The diff coverage is 84.22%.

Impacted file tree graph

@@             Coverage Diff             @@
##             master   #1557      +/-   ##
===========================================
- Coverage     72.71%   72.7%   -0.01%     
- Complexity     7387    7402      +15     
===========================================
  Files           685     688       +3     
  Lines         29853   29942      +89     
  Branches       3640    3648       +8     
===========================================
+ Hits          21708   21770      +62     
- Misses         6263    6282      +19     
- Partials       1882    1890       +8
Impacted Files Coverage Δ Complexity Δ
...om/linecorp/armeria/server/docs/TypeSignature.java 87.14% <ø> (+2.85%) 30 <0> (+1) ⬆️
...ecorp/armeria/server/docs/EndpointInfoBuilder.java 73.33% <0%> (ø) 16 <2> (ø) ⬇️
...om/linecorp/armeria/server/docs/FieldLocation.java 100% <100%> (ø) 1 <1> (?)
.../armeria/server/thrift/ThriftDocServicePlugin.java 85.37% <100%> (ø) 59 <0> (ø) ⬇️
...a/com/linecorp/armeria/server/docs/DocService.java 94.7% <100%> (+0.07%) 37 <0> (ø) ⬇️
...ia/internal/annotation/AnnotatedValueResolver.java 87.2% <100%> (+0.13%) 109 <7> (+1) ⬆️
...linecorp/armeria/server/docs/FieldRequirement.java 100% <100%> (ø) 1 <0> (ø) ⬇️
...linecorp/armeria/server/docs/FieldInfoBuilder.java 70% <70%> (ø) 6 <6> (?)
...rnal/annotation/AnnotatedHttpDocServicePlugin.java 80.51% <78.33%> (+0.28%) 62 <10> (+5) ⬆️
...va/com/linecorp/armeria/server/docs/FieldInfo.java 60.6% <78.57%> (ø) 11 <4> (ø) ⬇️
... and 17 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bfee616...1b54acc. Read the comment docs.

Copy link
Contributor

@hyeonjames hyeonjames left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave some comments!

docs-client/src/components/VariableList/index.tsx Outdated Show resolved Hide resolved
docs-client/src/components/VariableList/index.tsx Outdated Show resolved Hide resolved
Copy link
Contributor

@hyeonjames hyeonjames left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me !, left 2 comments

docs-client/src/components/VariableList/index.tsx Outdated Show resolved Hide resolved
docs-client/src/components/VariableList/index.tsx Outdated Show resolved Hide resolved
@trustin trustin added this to the 0.80.0 milestone Jan 30, 2019
@minwoox minwoox force-pushed the requestObject_docservice branch 2 times, most recently from 02e39a0 to 65ca0f0 Compare January 31, 2019 06:20
@trustin trustin removed the request for review from anuraaga January 31, 2019 10:10
Copy link
Contributor

@hyangtack hyangtack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job! Left some nits. :-)

private final Map<Method, List<AnnotatedValueResolver>> methods;

AnnotatedBeanFactory(BeanFactoryId beanFactoryId,
Entry<Constructor<T>, List<AnnotatedValueResolver>> constructor,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: alignment

@@ -0,0 +1,327 @@
/*
* Copyright 2018 LINE Corporation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: 2019?

final Builder<Method, List<AnnotatedValueResolver>> methodsBuilder = ImmutableMap.builder();
final Set<Method> methods = getAllMethods(beanFactoryId.type);
for (final Method method : methods) {
final RequestConverter[] converters = method.getAnnotationsByType(RequestConverter.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: How about using recently-added AnnotationUtil#findDeclared for consistency? 😄

final Builder<Field, AnnotatedValueResolver> builder = ImmutableMap.builder();
final Set<Field> fields = getAllFields(beanFactoryId.type);
for (final Field field : fields) {
final RequestConverter[] converters = field.getAnnotationsByType(RequestConverter.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto

factory.fields().values().forEach(builder::add);
final List<AnnotatedValueResolver> resolvers = builder.build();
if (!resolvers.isEmpty()) {
// TODO(minwoox) Should we support http element name for the bean type?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: If this TODO is not necessary, how about removing it and leaving a short description how we handle the bean type?

Motivation:
Currently, `RequestObject`s are not shown in `DocService`.

Modifications:
- Rename `AnnotatedBeanFactory` to `AnnotatedBeanFactoryRegistry`
- Add `AnnotatedBeanFactory` which has information about the bean factory
- Add `EndpointInfoBuilder` to make it `EndpointInfo` easily
- Add `FieldLocation` enum

Result:
- Better developer experience
@@ -372,7 +373,7 @@
final RequestObject requestObject = annotatedElement.getAnnotation(RequestObject.class);
if (requestObject != null) {
// Find more request converters from a field or parameter.
final RequestConverter[] converters = typeElement.getAnnotationsByType(RequestConverter.class);
final List<RequestConverter> converters = findDeclared(typeElement, RequestConverter.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! 👍

@minwoox minwoox merged commit f1e14e9 into line:master Feb 1, 2019
@minwoox minwoox deleted the requestObject_docservice branch February 1, 2019 03:04
fmguerreiro pushed a commit to fmguerreiro/armeria that referenced this pull request Sep 19, 2020
Motivation:
Currently, `RequestObject`s are not shown in `DocService`.

Modifications:
- Rename `AnnotatedBeanFactory` to `AnnotatedBeanFactoryRegistry`
- Add `AnnotatedBeanFactory` which has information about the bean factory
- Add `FieldInfoBuilder` to make `FieldInfo` easily
- Add `FieldLocation` enum
- Change the `DEFAULT` in `FieldRequirement` to `UNSPECIFIED` when it's unknown
- Bean fields are now collapsible in `DocService`

Result:
- Better developer experience
minwoox added a commit to minwoox/armeria that referenced this pull request Dec 9, 2022
Motivation:
We have introduced `TypeSignature` not to parse a struct type in place when creating `DocService` but put the struct in the list of `StructInfo` and link to it using `TypeSignature` in line#422.
We could have the definition of a struct in only one place so we could dedup the information.
However, we have started to parse a bean(which is a struct) in place to represent a `@RequestObject` type in line#1557.
To represent the type, `FieldInfo.childFieldInfo` was added and it turned out to be a bad decision.
Because after that, we have lots of duplicate information on structs. Also, the way that some of the structs use a link using `TypeSignature` whereas the rest of them don't, brought us the inconsistency of parsing and reorganizing the `DocService`.

Modifications:
- Remove `FieldInfo.childFieldInfos`.
  - `FieldInfo` now has only a `TypeSignature` and uses the `TypeSignature` to link to the corresponding struct.
  - The nested struct is not parsed in place.
- Add `REQUEST_OBJECT` `TypeSignature` for a `@RequestObject`.
- `FieldInfo`'s name for a `@RequestObject` is now the parameter name.
  - It was `class.getSimpleName` before which doesn't represent the field information properly.

Result:
- Unified way to create and organize `DocService`.
ikhoon pushed a commit that referenced this pull request Dec 15, 2022
Remove `FieldInfo.childFieldInfo`
Motivation:
We have introduced `TypeSignature` not to parse a struct type in place when creating `DocService` but put the struct in the list of `StructInfo` and link to it using `TypeSignature` in #422.
We could have the definition of a struct in only one place so we could dedup the information.
However, we have started to parse a bean(which is a struct) in place to represent a `@RequestObject` type in #1557.
To represent the type, `FieldInfo.childFieldInfo` was added and it turned out to be a bad decision.
Because after that, we have lots of duplicate information on structs. Also, the way that some of the structs use a link using `TypeSignature` whereas the rest of them don't, brought us the inconsistency of parsing and reorganizing the `DocService`.

Modifications:
- Remove `FieldInfo.childFieldInfos`.
  - `FieldInfo` now has only a `TypeSignature` and uses the `TypeSignature` to link to the corresponding struct.
  - The nested struct is not parsed in place.
- Add `REQUEST_OBJECT` `TypeSignature` for a `@RequestObject`.
- `FieldInfo`'s name for a `@RequestObject` is now the parameter name.
  - It was `class.getSimpleName` before which doesn't represent the field information properly.

Result:
- Unified way to create and organize `DocService`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants