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.

Sign up for GitHub

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

Jump to bottom

Improve support for @PostLoad annotation #516

Closed
michael-simons opened this issue Sep 3, 2018 · 1 comment
Closed

Improve support for @PostLoad annotation #516

michael-simons opened this issue Sep 3, 2018 · 1 comment
Assignees
@michael-simons
Labels
bug improvement

Comments

@michael-simons
Copy link
Collaborator

@PostLoad is not executed in a class hierarchy, see
#414 (comment).

There is PR #485 that solves this issue.

Furthermore, @PostLoad should behavior similar JSR 250's @PostConstruct:

  • The method MUST NOT have any parameters.
  • The return type of the method MUST be void.
  • The method MUST NOT throw a checked exception.
  • The method on which PostConstruct is applied MAY be public, protected,
    package private or private.
  • The method MUST NOT be static except for the application client.
  • In general, the method MUST NOT be final. However, other specifications are
    permitted to relax this requirement on a per-component basis.

With the addition that we don't create proxies and can allow final methods.

Thus gives us better means to structure domain classes, that is: the post load methods are not exposed and are constrained to a given context and not part of a public API.
@michael-simons michael-simons self-assigned this Sep 3, 2018
@michael-simons michael-simons mentioned this issue Sep 3, 2018
Closed
michael-simons referenced this issue Sep 3, 2018
@michael-simons
Allow @PostLoad-methods to be final and non-public
fe0911d 
Forcing the PostLoad method to be public and non final leads to poor domain classes:
- often the postload method is also used from the constructor, so they should be at least final so that the class can be safely overwritten
- also postload should usually not be an exposed method to calling code, it’s used to be only internal

Steps taken:
- Include „final“ methods in MethodsInfo. That should be the least problematic, didn’t find any usage of proxies
- When postload is executed, check if the annotated method is accessible. MethodInfo already includes protected, package private and private methods, we can at least try to use them
michael-simons added a commit that referenced this issue Sep 3, 2018
@michael-simons
GH-516 - Treat @PostLoad methods the same way as JSR-250 treats @Post…
2a6da66 
…Construct.

Forcing the PostLoad method to be public and non final leads to poor domain classes:
- often the postload method is also used from the constructor, so they should be at least final so that the class can be safely overwritten
- also postload should usually not be an exposed method to calling code, it’s used to be only internal

Steps taken:
- Include „final“ methods in MethodsInfo.
- When postload is executed, check if the annotated method is accessible. If not, try to make it accessible.
michael-simons added a commit that referenced this issue Sep 3, 2018
@michael-simons
GH-516 - Recognize overwritten @PostLoad methods in a class hierarchy.
bf70cdb 
This changes the way `@PostLoad` methods are computed:
- Don’t store MethodInfo by their name but by their method, as the name is not even unique per class
- Traverse class hierarchy for method infos and prioritize lower class methods
- Make sure that no ambigious scenerio can be created with multiple `@PostLoad` methods.
michael-simons added a commit that referenced this issue Sep 3, 2018
@michael-simons
GH-516 - Treat @PostLoad methods the same way as JSR-250 treats @Post…
73a5ac3 
…Construct.

Forcing the PostLoad method to be public and non final leads to poor domain classes:
- often the postload method is also used from the constructor, so they should be at least final so that the class can be safely overwritten
- also postload should usually not be an exposed method to calling code, it’s used to be only internal

Steps taken:
- Include „final“ methods in MethodsInfo.
- When postload is executed, check if the annotated method is accessible. If not, try to make it accessible.
michael-simons added a commit that referenced this issue Sep 3, 2018
@michael-simons
GH-516 - Recognize overwritten @PostLoad methods in a class hierarchy.
13f8fa4 
This changes the way `@PostLoad` methods are computed:
- Don’t store MethodInfo by their name but by their method, as the name is not even unique per class
- Traverse class hierarchy for method infos and prioritize lower class methods
- Make sure that no ambigious scenerio can be created with multiple `@PostLoad` methods.
michael-simons added a commit that referenced this issue Sep 4, 2018
@michael-simons
GH-516 - Treat @PostLoad methods the same way as JSR-250 treats @Post…
1d8751e 
…Construct.

Forcing the PostLoad method to be public and non final leads to poor domain classes:
- often the postload method is also used from the constructor, so they should be at least final so that the class can be safely overwritten
- also postload should usually not be an exposed method to calling code, it’s used to be only internal

Steps taken:
- Include „final“ methods in MethodsInfo.
- When postload is executed, check if the annotated method is accessible. If not, try to make it accessible.
michael-simons added a commit that referenced this issue Sep 4, 2018
@michael-simons
GH-516 - Recognize overwritten @PostLoad methods in a class hierarchy.
d356478 
This changes the way `@PostLoad` methods are computed:
- Don’t store MethodInfo by their name but by their method, as the name is not even unique per class
- Traverse class hierarchy for method infos and prioritize lower class methods
- Make sure that no ambigious scenerio can be created with multiple `@PostLoad` methods.
michael-simons added a commit that referenced this issue Sep 4, 2018
@michael-simons
GH-516 - Polishing.
5c65222
meistermeier pushed a commit that referenced this issue Sep 4, 2018
@michael-simons @meistermeier
GH-516 - Recognize overwritten @PostLoad methods in a class hierarchy.
27b3123 
This changes the way `@PostLoad` methods are computed:
- Don’t store MethodInfo by their name but by their method, as the name is not even unique per class
- Traverse class hierarchy for method infos and prioritize lower class methods
- Make sure that no ambigious scenerio can be created with multiple `@PostLoad` methods.
meistermeier pushed a commit that referenced this issue Sep 4, 2018
@michael-simons @meistermeier
GH-516 - Treat @PostLoad methods the same way as JSR-250 treats @Post…
c8bc0ee 
…Construct.

Forcing the PostLoad method to be public and non final leads to poor domain classes:
- often the postload method is also used from the constructor, so they should be at least final so that the class can be safely overwritten
- also postload should usually not be an exposed method to calling code, it’s used to be only internal

Steps taken:
- Include „final“ methods in MethodsInfo.
- When postload is executed, check if the annotated method is accessible. If not, try to make it accessible.
meistermeier pushed a commit that referenced this issue Sep 4, 2018
@michael-simons @meistermeier
GH-516 - Recognize overwritten @PostLoad methods in a class hierarchy.
51ba9fb 
This changes the way `@PostLoad` methods are computed:
- Don’t store MethodInfo by their name but by their method, as the name is not even unique per class
- Traverse class hierarchy for method infos and prioritize lower class methods
- Make sure that no ambigious scenerio can be created with multiple `@PostLoad` methods.
@michael-simons
Copy link
Collaborator Author

Closed with 51ba9fb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michael-simons michael-simons

Labels
bug improvement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@michael-simons