generator-jhipster-quarkus icon indicating copy to clipboard operation
generator-jhipster-quarkus copied to clipboard

Generating a blog app with OAuth 2.0 fails to compile

Open mraible opened this issue 3 years ago • 4 comments

Describe the bug

I tried generating an app with the blog-oauth2.jdl. It fails to compile.

To Reproduce

jhipster jdl blog-oauth2.jdl --blueprints quarkus

Unfortunately, this results in a compilation error.

[INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ blog ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 30 source files to /Users/mraible/quarkus/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] /Users/mraible/quarkus/src/main/java/com/jhipster/demo/blog/domain/Blog.java:[42,12] cannot find symbol
  symbol:   class User
  location: class com.jhipster.demo.blog.domain.Blog
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  59.470 s
[INFO] Finished at: 2020-12-10T09:09:28-07:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project blog: Compilation failure
[ERROR] /Users/mraible/quarkus/src/main/java/com/jhipster/demo/blog/domain/Blog.java:[42,12] cannot find symbol
[ERROR]   symbol:   class User
[ERROR]   location: class com.jhipster.demo.blog.domain.Blog
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

mraible avatar Dec 10 '20 16:12 mraible

@mraible as for now the Oauth2 does not produce a User entity as upstream JHipster. I guess in your JDL your Blog entity has a relation to the User entity. That's why it fails by default. Add a custom User entity in your JDL and I'm pretty sure it will work :)

danielpetisme avatar Dec 10 '20 16:12 danielpetisme

IMO, it should match what the main generator does. The Micronaut blueprint has this capability. I ran it through similar tests when its OAuth support was being developed.

mraible avatar Dec 10 '20 16:12 mraible

I'm not comfortable with generating User domain object when there is no user management and authentication actually managed by the application. (I'm not with the upstream generator too BTW).

In the Blog sample, we need a user mainly to fullfill the Blog ownership relation. I tend to separate the authentication/authorization aspect of the User from it's data segregation function which is domain dependant.

AFAIK, .Net Core or nodejs blueprints aren't implementing it neither.

danielpetisme avatar Dec 12 '20 15:12 danielpetisme

Since you're the maintainer of this blueprint, the choice is up to you. I thought it was a cool feature when I added it to the main generator because it allows you to create relationships with the User object, just like you can with JWT authentication. It also works in a microservices architecture.

If you try to create a JWT-based microservice with a relationship to User, the generation succeeds, but the compilation fails (similar to how it does here). I think it'd be better if the generation fails and warns the user before they try to compile.

If you have entities that need a relationship to the current user, how would you suggest a developer implements it?

The "save the user right after they log in" implementation might not be ideal. A better solution would be to use something like Okta Event Hooks which can call an endpoint to sync a user when they're created. However, I don't think Keycloak has anything like that, and it's not a standard part of OAuth.

FWIW, this does work in the Micronaut blueprint. I haven't tested this JDL with the .NET Core or Node.js blueprint, but I'd be happy to sponsor their implementation.

mraible avatar Dec 12 '20 19:12 mraible