JHipster and Quarkus

468 views
Skip to first unread message

Max Andersen

unread,
Dec 18, 2019, 4:00:55 AM12/18/19
to Quarkus Development mailing list
Hi,

Yesterday a few us met up with people involved in JHipster to hear about the current Quarkus blueprint work happening.

Daniel Petisme are doing great work with his sample app and written up a doc listing his outstanding challenges - he also after the meeting outlined his view on a table of must/should/nice to have for  a first version of a jhipster blueprint. 

From Quarkus core team we'll try and help where we can from Quarkus side on fixing issues and make recommendations on how to best implement a certain pattern; on jhipster side our expertise will fall short ;)

If anyone in the community are up for helping out Daniel making the blueprint complete you can grab items in the above if interested.

Note: just to be clear, Quarkus built-in scaffolding is something different from jhipster scaffolding - we'll still work on making out-of-box Quarkus have a good default setup; this mail is to just make quarkus community aware of the jhipster work. If you are already in jhipster 'ecosystem' or who wants to explore using jhipster DSL approach for generating Quarkus apps you can do so.
 
--

Loïc MATHIEU

unread,
Dec 18, 2019, 4:57:16 AM12/18/19
to Max Rydahl Andersen, Quarkus Development mailing list
Hello,

Very interesting !
I can help with anything MongoDB related if needed as I worked on it for Quarkus :)

Regards,

Loïc

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAHL%3D7VssS%2BzPjXu4cdEx%2BDtnedE-3VLLczx8mgdLGrxxENgm4Q%40mail.gmail.com.

Daniel Petisme

unread,
Dec 18, 2019, 5:23:02 AM12/18/19
to Loïc MATHIEU, Max Rydahl Andersen, Quarkus Development mailing list
@Max Andersen as for now I think we need to block a scope. Can we timebox the definition ? Let's say a week to discuss priorities and block a first version content?
Make sense?

Daniel PETISME
daniel....@gmail.com


To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVEJ0SU6u6aBTPT-yxBrq9wk5kwPS17fVjgV3Yv%3DKYTSZg%40mail.gmail.com.

Emmanuel Bernard

unread,
Dec 18, 2019, 5:24:55 AM12/18/19
to Daniel Petisme, Loïc MATHIEU, Max Rydahl Andersen, Quarkus Development mailing list

I'm even +1 for you to be the benevolent dictator and make your enlightened scope the true one.
We can make this support 0.x like we did for Quarkus.

Daniel Petisme

unread,
Dec 19, 2019, 12:31:31 PM12/19/19
to Emmanuel Bernard, Loïc MATHIEU, Max Rydahl Andersen, Quarkus Development mailing list
I do like the 0.x approach and consider it as experimental until a formal 1.0.

Daniel PETISME

unread,
Jan 6, 2020, 4:50:56 AM1/6/20
to Quarkus Development mailing list
Hello all and happy new year!!

I wish you all the best for 2020.

I worked on the jhipster quarkus and before going into details I think it might be useful to explains couple of JHipster concepts.

JHipster concepts
JHipster(https://github.com/jhipster/generator-jhipster) is a code generator based on Yeoman(https://yeoman.io/) initially targeting Spring and Angular as main technologies. So yes, it relies on JavaScript, node, npm... 
Nowadays, JHipster is able to  generate an incredible combination of configuration, you can chosse you data storage (SQL or not), caching, authentication mode, i18n, websockets, etc etc.

Behind the scene, the code generation is delegated on "sub-generator" each representing an aspect of the application (server, client, controllers, entity, service, docker, common, i18n, etc.)
Just as Maven phase, the sub-generator are chained to generate the application code.
A sub-generator is basically a set of EJS templates (Embedded JavaScript  templating - https://ejs.co/) and some processing (prompt a question, validation, computation, etc).
The templating is very close to JSP with conditions checking, loops, partials etc. the final output is the rendered text file in the appropriate folder.

JHipster proposes a way to override one or many sub-generators in an external node module and that's what we call a blueprint. You can provide new templates, redefine the prompts, etc
For instance the Kotlin blueprint (https://github.com/jhipster/jhipster-kotlin) is an external node module which simply overrides the appropriate sub-generators (server to override the pom.xml, and the basic application Java code, entity for the entity generation, etc) and fallback to the default JHipster sub-generators for the client part).  Very similar to Maven with a defined flow and where you configure/override part of it.


So for Quarkus, the plan is to have also a dedicated blueprint to generate Quarkus code and certainly redefine some prompts (choosing between the active record vs repository pattern)

JHipster provide also a "sample app" (https://github.com/jhipster/jhipster-sample-app), which is a kind of petstore application, to showcase a very basic generated application. The app is dummy bank account management system.

When one tries to include a new core technology (like Kotlin, dotnet or Quarkus), the very first step is to re-develop this sample app. Is a good feasibility indicator and since JHipster is all about templating, when you have a sample-app it's very easy to convert each file into a template.

Now that the concepts are established, let's dive into what I've done

JHipster Quarkus
A sample app generated with it (it's not complete at all): https://github.com/jhipster/jhipster-sample-app-quarkus

Installation
npm install -g generator-jhipster
git clone g...@github.com:jhipster/jhipster-quarkus.git
cd jhipster-quarkus
npm link
Usage
mkdir my-app && cd my-app
npm link generator-jhipster-quarkus
jhipster -d --blueprint quarkus

Status
I can generate an application with Quarkus dependencies (Maven only for now).
Based on the DB choices the dependencies and configuration are applied (Bonus: the MongoDB will be very easy).
I can generate an entity (with public fields no accessors), the according PanacheRepository (since it's the default pattern in JHipster I sticked to it to go faster) a REST ressource with JAX-RS semantic rather than Spring Web)
I started the authentication User Management part.

Issues
1- JHipster web files location
Spring relies on `src/main/webapp` where Quarkus uses `src/main/resources/META-INF`. 
Quarkus does not plan to support this location (https://github.com/quarkusio/quarkus/issues/1049) so that means the generation destination must be change on JHipster side. This is an issue since it's hard coded deep and change it implies to override a lot of files... It's a recurring issue I have with JHipster to I'll try to fix it once for all.

2- Quarkus dev mode and "fat" frontend technologies
Quarkus dev is able to live reload resource files in order to reflect the modifications (pretty neat with Java but also web development). As soon as you frontend relies on a build tool (webpack for instance) it's useless. Technologies like Angular, React, etc introduce a concept of "build" where they do a set of operations (like transpiling Typescript to JS, concatenating files, etc.).
As for now, (just as I do with Spring) I started the backend application (with quarkus:dev) on port 8080 and start the frontend with live reload on 9000 (it's the default JHipster config). JHipster proposes a proxy config to redirect the request to 0.0.0.0:9000 to 0.0.0.0:8080 for dev mode.

3- Authentication
Currently (with a default config), JHipster exposes a /authenticate endpoint (https://github.com/jhipster/jhipster-sample-app/blob/master/src/main/java/io/github/jhipster/sample/web/rest/UserJWTController.java) which receives the user and password, Spring propose an AuthenticationManager system in which I can inject a custom `UserDetailsService` (https://github.com/jhipster/jhipster-sample-app/blob/master/src/main/java/io/github/jhipster/sample/security/DomainUserDetailsService.java) to load the Domain User from the database.
The authenticationManager is in charge of doing the password comparaison and return the `Authentication`.

Once authenticated, the JHipster application forges a JWT which is returned to the frontend. The client application will use this JWT for the next requests (and JHipster is configured with a JWT filter to validate, extract the claims and build the SecurityContext).

In Quarkus, As far as I know, the extensions can't be combined? I can't use the JDBC to do a first authentication, manually build a token and then use MP-JWT for the rest of the security ?
Digging a litle bit, I found the elytron-security extension which seems to propose a way to manually invoke an authentication (https://github.com/quarkusio/quarkus/blob/master/extensions/elytron-security/runtime/src/main/java/io/quarkus/elytron/security/runtime/ElytronPasswordIdentityProvider.java)?
WDYT?
The other solution I have is to build my own AuthenticationService (very basic) but I don't think it's the proper way

This is it, I hope it's clear enough. Feel free to ask questions.

Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev+unsubscribe@googlegroups.com.

Stephane Epardaud

unread,
Jan 6, 2020, 11:28:47 AM1/6/20
to daniel....@gmail.com, Quarkus Development mailing list
I agree with the scenario of using BASIC auth on a `/login` endpoint which returns a JWT token to use for the rest of the REST API. I'm not sure we support that, but we should: I've seen this use-case in the past.

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/a54c8bb9-aa12-488a-b2da-78efc4c52534%40googlegroups.com.


--
Stéphane Épardaud

Daniel Petisme

unread,
Jan 6, 2020, 12:32:25 PM1/6/20
to Stephane Epardaud, Quarkus Development mailing list
Hello,

It's not properly speaking a BASIC auth since it sends the credentials in the request body rather than a header but yes the flow is similar: a request with user/password, the authentication itself is part of the framework but somehow can be manually invoked. The authentication can be configured (identity providing delegated to the app, password encoder etc).

The app receives an authentication result and decide what to do next (forge a token, or do whatever).

Do you think it can be done out of the box with the current Quarkus security APIs?

Stuart Douglas

unread,
Jan 7, 2020, 8:00:40 PM1/7/20
to daniel....@gmail.com, Quarkus Development mailing list
We could try and fix this but I think it would end up involving some really nasty hacks. It would be easy enough to do when building a maven application, however for things like running tests from the IDE I think we would basically end up with hard coded paths to try and guess the webresources location. 

If it is a big issue we could look into it, but I was hoping we could avoid it.
 

2- Quarkus dev mode and "fat" frontend technologies
Quarkus dev is able to live reload resource files in order to reflect the modifications (pretty neat with Java but also web development). As soon as you frontend relies on a build tool (webpack for instance) it's useless. Technologies like Angular, React, etc introduce a concept of "build" where they do a set of operations (like transpiling Typescript to JS, concatenating files, etc.).
As for now, (just as I do with Spring) I started the backend application (with quarkus:dev) on port 8080 and start the frontend with live reload on 9000 (it's the default JHipster config). JHipster proposes a proxy config to redirect the request to 0.0.0.0:9000 to 0.0.0.0:8080 for dev mode.


I did toy with the idea of having Quarkus be able to automatically start the frontend live reload server and proxy requests automatically, so you could just access the application on 8080, but I was not sure how useful it would be as I am not really a fronend dev. Does this sound useful at all?
 
3- Authentication
Currently (with a default config), JHipster exposes a /authenticate endpoint (https://github.com/jhipster/jhipster-sample-app/blob/master/src/main/java/io/github/jhipster/sample/web/rest/UserJWTController.java) which receives the user and password, Spring propose an AuthenticationManager system in which I can inject a custom `UserDetailsService` (https://github.com/jhipster/jhipster-sample-app/blob/master/src/main/java/io/github/jhipster/sample/security/DomainUserDetailsService.java) to load the Domain User from the database.
The authenticationManager is in charge of doing the password comparaison and return the `Authentication`.

Once authenticated, the JHipster application forges a JWT which is returned to the frontend. The client application will use this JWT for the next requests (and JHipster is configured with a JWT filter to validate, extract the claims and build the SecurityContext).

In Quarkus, As far as I know, the extensions can't be combined? I can't use the JDBC to do a first authentication, manually build a token and then use MP-JWT for the rest of the security ?
Digging a litle bit, I found the elytron-security extension which seems to propose a way to manually invoke an authentication (https://github.com/quarkusio/quarkus/blob/master/extensions/elytron-security/runtime/src/main/java/io/quarkus/elytron/security/runtime/ElytronPasswordIdentityProvider.java)?
WDYT?
The other solution I have is to build my own AuthenticationService (very basic) but I don't think it's the proper way


I think we need to make some improvements here. We have a FORM based auth that uses encrypted cookies to store the logged in user, however it it is not really designed for end user consumption. 

Stuart
 
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/a54c8bb9-aa12-488a-b2da-78efc4c52534%40googlegroups.com.

Daniel PETISME

unread,
Jan 8, 2020, 6:03:56 AM1/8/20
to Quarkus Development mailing list


On Wednesday, January 8, 2020 at 2:00:40 AM UTC+1, Stuart Douglas wrote:
I think you're right and we should avoid it, I'll use maven configuration as workaround and investigate on JHipster side to generate the frontend in META-INF.
 

2- Quarkus dev mode and "fat" frontend technologies
Quarkus dev is able to live reload resource files in order to reflect the modifications (pretty neat with Java but also web development). As soon as you frontend relies on a build tool (webpack for instance) it's useless. Technologies like Angular, React, etc introduce a concept of "build" where they do a set of operations (like transpiling Typescript to JS, concatenating files, etc.).
As for now, (just as I do with Spring) I started the backend application (with quarkus:dev) on port 8080 and start the frontend with live reload on 9000 (it's the default JHipster config). JHipster proposes a proxy config to redirect the request to 0.0.0.0:9000 to 0.0.0.0:8080 for dev mode.


I did toy with the idea of having Quarkus be able to automatically start the frontend live reload server and proxy requests automatically, so you could just access the application on 8080, but I was not sure how useful it would be as I am not really a fronend dev. Does this sound useful at all?
IMHO, it's definitively makes sense. I can provide you an "real application" using massively webpack building/proxy. Let me know.
 
3- Authentication
Currently (with a default config), JHipster exposes a /authenticate endpoint (https://github.com/jhipster/jhipster-sample-app/blob/master/src/main/java/io/github/jhipster/sample/web/rest/UserJWTController.java) which receives the user and password, Spring propose an AuthenticationManager system in which I can inject a custom `UserDetailsService` (https://github.com/jhipster/jhipster-sample-app/blob/master/src/main/java/io/github/jhipster/sample/security/DomainUserDetailsService.java) to load the Domain User from the database.
The authenticationManager is in charge of doing the password comparaison and return the `Authentication`.

Once authenticated, the JHipster application forges a JWT which is returned to the frontend. The client application will use this JWT for the next requests (and JHipster is configured with a JWT filter to validate, extract the claims and build the SecurityContext).

In Quarkus, As far as I know, the extensions can't be combined? I can't use the JDBC to do a first authentication, manually build a token and then use MP-JWT for the rest of the security ?
Digging a litle bit, I found the elytron-security extension which seems to propose a way to manually invoke an authentication (https://github.com/quarkusio/quarkus/blob/master/extensions/elytron-security/runtime/src/main/java/io/quarkus/elytron/security/runtime/ElytronPasswordIdentityProvider.java)?
WDYT?
The other solution I have is to build my own AuthenticationService (very basic) but I don't think it's the proper way


I think we need to make some improvements here. We have a FORM based auth that uses encrypted cookies to store the logged in user, however it it is not really designed for end user consumption. 
I'm close to achieve the explained flow (manually auth + JWT) in the application. I'll have it with you I would be more than happy to have your feedback  

Stuart
 
This is it, I hope it's clear enough. Feel free to ask questions.

Daniel


On Thursday, December 19, 2019 at 6:31:31 PM UTC+1, Daniel PETISME wrote:
I do like the 0.x approach and consider it as experimental until a formal 1.0.

Le mer. 18 déc. 2019 à 11:24, Emmanuel Bernard <eber...@redhat.com> a écrit :

I'm even +1 for you to be the benevolent dictator and make your enlightened scope the true one.
We can make this support 0.x like we did for Quarkus.

On 18 Dec 2019, at 11:22, Daniel Petisme wrote:

...@Max Andersen as for now I think we need to block a scope. Can we timebox the definition ? Let's say a week to discuss priorities and block a first version content?
Make sense?

Daniel PETISME
daniel...@gmail.com


On Wed, Dec 18, 2019 at 10:57 AM Loïc MATHIEU <loik...@gmail.com> wrote:
Hello,

Very interesting !
I can help with anything MongoDB related if needed as I worked on it for Quarkus :)

Regards,

Loïc

Le mer. 18 déc. 2019 à 10:00, Max Andersen <mand...@redhat.com> a écrit :
Hi,

Yesterday a few us met up with people involved in JHipster to hear about the current Quarkus blueprint work happening.

Daniel Petisme are doing great work with his sample app and written up a doc listing his outstanding challenges - he also after the meeting outlined his view on a table of must/should/nice to have for  a first version of a jhipster blueprint. 

From Quarkus core team we'll try and help where we can from Quarkus side on fixing issues and make recommendations on how to best implement a certain pattern; on jhipster side our expertise will fall short ;)

If anyone in the community are up for helping out Daniel making the blueprint complete you can grab items in the above if interested.

Note: just to be clear, Quarkus built-in scaffolding is something different from jhipster scaffolding - we'll still work on making out-of-box Quarkus have a good default setup; this mail is to just make quarkus community aware of the jhipster work. If you are already in jhipster 'ecosystem' or who wants to explore using jhipster DSL approach for generating Quarkus apps you can do so.
 
--

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

Sergey Beryozkin

unread,
Jan 13, 2020, 6:29:56 AM1/13/20
to Stuart Douglas, Daniel Petisme, Quarkus Development mailing list
Not sure yet it is relevant but a JWT generation builder API (signing, encryption, with the assymetric/symmetric keys) is coming shortly to Quarkus as part of smallrye-jwt. Daniel, I haven't updated smallrye-jwt yet to verify the tokens signed with the symmetric keys (as per our initial discussions awhile back), but it will be straightforward....

Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cxYDe4qGN1ri2V5j6q_SCo7KSTHEJCYzodY96xaPpt0DQ%40mail.gmail.com.

Daniel Petisme

unread,
Jan 13, 2020, 12:49:07 PM1/13/20
to Sergey Beryozkin, Stuart Douglas, Quarkus Development mailing list
Hi,


Stéphane send me the PR  too
So far I use the vanilla Jose4j API and it works so it's not a blocking point for me.

I should be able to share an example end of this week I hope.

Copy Paper

unread,
Feb 9, 2020, 2:51:45 PM2/9/20
to Quarkus Development mailing list
Hi,

were you able to write this kind of example? (first authentication, manually build a token and then use MP-JWT for the rest of the security)

Thanks!
...@Max Andersen as for now I think we need to block a scope. Can we timebox the definition ? Let's say a week to discuss priorities and block a first version content?
Make sense?

Daniel PETISME
daniel...@gmail.com


On Wed, Dec 18, 2019 at 10:57 AM Loïc MATHIEU <loik...@gmail.com> wrote:
Hello,

Very interesting !
I can help with anything MongoDB related if needed as I worked on it for Quarkus :)

Regards,

Loïc

Le mer. 18 déc. 2019 à 10:00, Max Andersen <mand...@redhat.com> a écrit :
Hi,

Yesterday a few us met up with people involved in JHipster to hear about the current Quarkus blueprint work happening.

Daniel Petisme are doing great work with his sample app and written up a doc listing his outstanding challenges - he also after the meeting outlined his view on a table of must/should/nice to have for  a first version of a jhipster blueprint. 

From Quarkus core team we'll try and help where we can from Quarkus side on fixing issues and make recommendations on how to best implement a certain pattern; on jhipster side our expertise will fall short ;)

If anyone in the community are up for helping out Daniel making the blueprint complete you can grab items in the above if interested.

Note: just to be clear, Quarkus built-in scaffolding is something different from jhipster scaffolding - we'll still work on making out-of-box Quarkus have a good default setup; this mail is to just make quarkus community aware of the jhipster work. If you are already in jhipster 'ecosystem' or who wants to explore using jhipster DSL approach for generating Quarkus apps you can do so.
 
--

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

Daniel PETISME

unread,
Mar 25, 2020, 7:57:36 PM3/25/20
to Quarkus Development mailing list
Hello folks,

It has been a while... so let's sum up what has been done since the beginning of the year.

TL;DR
git clone g...@github.com:jhipster/jhipster-sample-app-quarkus.git
cd jhipster-sample-app-quarkus
./mvnw

Main feature: user management

RSS JHipster Quarkus 300MB vs JHipster Spring 700MB+ almost (~80%) identical from a user point of view

it has been harder than I thought and I have to do a proper report of the issues we had but I'm satisfied of the current status.

Screenshot 2020-03-26 at 12.24.36 AM.png



Long version
I start to work on the JHipster Quarkus blueprint (ie. override JHipster main generator in order to keep the big steps os the generation while producing  Quarkus files).
The project is hosted in the JHipster organization: https://github.com/jhipster/jhipster-quarkus/

- We generate qn Angular frontend + a Quarkus backend properly configured to work together (build tools are configured, proxy defined etc)
- The user can start the application in devmode (ie quarkus:dev) by invoking `./mvnw`, behind the scene everything is configure to trigger the frontend install/buidl + quarkus build)
- The user can then log into the application because:
  1. There is an h2 databse packaged and the quarkus configs are preset in development mode
  2. Liquibase init the database with basic user and roles
  3. There is a first authentication using the DB to forge a JWT and then Quarkus JWT Security + RBAC will filter the following requests
- Once logged in as admin, the user can create new users (administration > User management) or a new user can fill up the registration form. After providing basic creating a new user, a activation mail produced with Qute will be send with an activation key. The new user clik on this link to activate the account and define a password..

- The default Java version is 11, I did not try to go native yet
- As for now, the application use the Repository pattern because I had a weird issue in some tests, I have to retry with Quarkus 1.3.0
- Plenty of integration tests with RestAssured (quite painfull actually...)

I'm sure I missed some elements, feel free to ask me anything

Stuart Douglas

unread,
Mar 25, 2020, 9:04:13 PM3/25/20
to daniel....@gmail.com, Quarkus Development mailing list
Can you elaborate on why the Restassured testing was painful? Also any other major pain points that you had?

Stuart

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/9b02a6ab-fb83-4ebc-81ca-da96f5f8733d%40googlegroups.com.

Sergey Beryozkin

unread,
Mar 26, 2020, 6:46:13 AM3/26/20
to Stuart Douglas, Daniel Petisme, Quarkus Development mailing list
Hi Daniel

If you already use jose4j to forge JWT then it is fine, otherwise you can optimize on some extra dependencies if you try smallrye-jwt builder api which is done on top of jose4j, since you already use smallrye-jwt...

Cheers, Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD%2BL2cwA5yvKjRrYJVpePqYMzvEDi6QW4SR2z9bk95PamVR3tQ%40mail.gmail.com.

Daniel Petisme

unread,
Mar 26, 2020, 1:14:26 PM3/26/20
to Sergey Beryozkin, Stuart Douglas, Quarkus Development mailing list
Hello,

To answer Stuart's questions
Can you elaborate on why the Restassured testing was painful?
I would separate my answer in 2 parts.
First, I did not know RestAssurred before Quarkus, so there is a natural learning curve
Most of the Quarkus/RestAssured are quite basics, and when people are already discovering Quarkus trust me if they have an issue with Restassured they will blame Quarkus...
Let's take an example
The sample projet uses java.time.Instant, and when I was testing, I had what looked like deserialization error. So I spend time to understand how I configure JsonB to unmarshall properly date/time.
Actually, the error was on RestAssured side which 1/ does not use JsonB as default object mapper out of the box 2/ needs to be configured to properly serialize dates in ISO8601 vs epoch (which one found make totally sense).
This issue was described here, Antonoio also raised it as a Quarkus issue where it was RestAssured.
https://github.com/quarkusio/quarkus-quickstarts/issues/205

So I think, couple of documentation/configuration could ease restassured testing:
1- pre-configure the defaultObjectMapper just as it's done with the application url?
2- Complete the https://quarkus.io/guides/getting-started-testing doc with links to the RestAssured doc about key topics (content-negotiation, authentication, Serial/Deserial).

And BTW, I had couple of issues with jsonpath expression (I copy/pasted some tests assertions I had in Spring and they were not working exactly the same, but couple of try/fail iteration permits to figured out the proper jsonpath expression).

Secondly, is not related to Restassured specifically but more about the integration testing strategy. 
Spring proposes a complete integration mock layer (database, rest, security, etc), and Jhipster heavily relies on it to setup a test context. So in a first attempt, I try to mimic that and I failed.
https://github.com/quarkusio/quarkus/issues/1367

The position regarding mocking the application when running test is not very clear yet (at least for me), I saw you post regarding Mock improvement but I don't know how far Quarkus plan to mock the application component.
So after couple of discussions, I choose to do black box testing for the integration part. The main drawback of this option is the test setup becoming more complex (since it has to follow the functional path of the application). For example, when testing user management, before testing the update of the current user for instance, I have to:
- call the user registration endpoint, the user registration sends an activation email
- Retrieve the activation email (I used the MockMailbox) to parse the mail text to get the token
- call the activation endpoint with the token.
- Call the authentication endpoint with the freshly created user to retrieve the JWT
- finally invoke the update account with the token in headers.

While being more "realistic", the test development/debug is less siloted thus more complex to realize IMHO.

To be honest, I think every dev has its own definition unit vs integration vs whatever testing, and I don't want to fall into an expert debate.
Here, I translated what I knew from Spring to Quarkus. If I want to be critic regarding what I have done, maybe some tests are close to unit tests than other and I could probably rewrite some tests which simply instantiate the component under test (REST Resource, Service) rather than starting the whole application and go through complex layer to mock (security for instance).
Spring provides tools to basically simulate the while application (with MockMvc) which permits to enable/disable the security, inject a user in the security context, share transactions between the app code and the test code, etc.). This layer is obviously expensive to develop and more code means more issues, thus more support activity.
Maybe, Java developers went too far with mocking/simulations etc and Quarkus shouldn't fall into the rabbit hole and stick to the KISS philosophy.

So to rephrase, RestAssured testing was painful but maybe I shouldn't have done it in the first place.
Thoughts?

Also any other major pain points that you had?
Classloader issues
I had to use the repository pattern because on a particular test setup the Panache augmentation was not made properly (sorry it was a long time ago, I didn't keep track of the issue).
I have to retest with 1.3.0 I'll keep you informed.

IDE integration
It's frustrating to be able to simply click on "Run the application" or "Run the test". I'm not very used to run Maven stage from the IDE so I had play with Maven CLI to run the proper unit/integration test in debug mode.

Surefire vs Failsafe code coverage
I tried to setup test coverage (with jacoco) and I had class loader issues

Pain points with a solution but not totally finished
Caching
https://github.com/quarkusio/quarkus/issues/6492
At the end it was not the proper solution but still the feature is not covered yet

EntityGraph loading
I tried to eagerly load an entity graph and ends up with a JPQL query (which is valid solution). I think HIbernate Panache finders could cover the need with an entity Graph definition (rather than s JQPL string).

I plan to organize a status meeting where I could go in details and discuss these points.
I hope this feedback helps you, feel free to ask me anything.

Daniel PETISME
daniel....@gmail.com

Daniel Petisme

unread,
Mar 26, 2020, 1:15:59 PM3/26/20
to Sergey Beryozkin, Stuart Douglas, Quarkus Development mailing list
To answer Sergey's question.

I started a home made forging then Stephane shared with me your work on JWT forging.
I didn't look at it yet but definitively in my todo list!
 
Daniel PETISME
daniel....@gmail.com

Sergey Beryozkin

unread,
Mar 26, 2020, 1:18:58 PM3/26/20
to Daniel Petisme, Stuart Douglas, Quarkus Development mailing list
Thanks, it is a minor thing...

Cheers, Sergey

Georgios Andrianakis

unread,
Mar 26, 2020, 1:36:15 PM3/26/20
to Daniel Petisme, Sergey Beryozkin, Stuart Douglas, Quarkus Development mailing list


On Thu, Mar 26, 2020, 19:14 Daniel Petisme <daniel....@gmail.com> wrote:
Hello,

To answer Stuart's questions
Can you elaborate on why the Restassured testing was painful?
I would separate my answer in 2 parts.
First, I did not know RestAssurred before Quarkus, so there is a natural learning curve
Most of the Quarkus/RestAssured are quite basics, and when people are already discovering Quarkus trust me if they have an issue with Restassured they will blame Quarkus...
Let's take an example
The sample projet uses java.time.Instant, and when I was testing, I had what looked like deserialization error. So I spend time to understand how I configure JsonB to unmarshall properly date/time.
Actually, the error was on RestAssured side which 1/ does not use JsonB as default object mapper out of the box 2/ needs to be configured to properly serialize dates in ISO8601 vs epoch (which one found make totally sense).
This issue was described here, Antonoio also raised it as a Quarkus issue where it was RestAssured.
https://github.com/quarkusio/quarkus-quickstarts/issues/205

We can definitely configure RESTAssured to use the proper ObjectMapper (I had a PR at one point). The problem is that it wouldn't work for native tests which would be very confusing for users.
There might be some obscure workaround, but I haven't looked into it.

So I think, couple of documentation/configuration could ease restassured testing:
1- pre-configure the defaultObjectMapper just as it's done with the application url?
2- Complete the https://quarkus.io/guides/getting-started-testing doc with links to the RestAssured doc about key topics (content-negotiation, authentication, Serial/Deserial).

And BTW, I had couple of issues with jsonpath expression (I copy/pasted some tests assertions I had in Spring and they were not working exactly the same, but couple of try/fail iteration permits to figured out the proper jsonpath expression).

Secondly, is not related to Restassured specifically but more about the integration testing strategy. 
Spring proposes a complete integration mock layer (database, rest, security, etc), and Jhipster heavily relies on it to setup a test context. So in a first attempt, I try to mimic that and I failed.
https://github.com/quarkusio/quarkus/issues/1367

The position regarding mocking the application when running test is not very clear yet (at least for me), I saw you post regarding Mock improvement but I don't know how far Quarkus plan to mock the application component.
So after couple of discussions, I choose to do black box testing for the integration part. The main drawback of this option is the test setup becoming more complex (since it has to follow the functional path of the application). For example, when testing user management, before testing the update of the current user for instance, I have to:
- call the user registration endpoint, the user registration sends an activation email
- Retrieve the activation email (I used the MockMailbox) to parse the mail text to get the token
- call the activation endpoint with the token.
- Call the authentication endpoint with the freshly created user to retrieve the JWT
- finally invoke the update account with the token in headers.

While being more "realistic", the test development/debug is less siloted thus more complex to realize IMHO.

To be honest, I think every dev has its own definition unit vs integration vs whatever testing, and I don't want to fall into an expert debate.
Here, I translated what I knew from Spring to Quarkus. If I want to be critic regarding what I have done, maybe some tests are close to unit tests than other and I could probably rewrite some tests which simply instantiate the component under test (REST Resource, Service) rather than starting the whole application and go through complex layer to mock (security for instance).
Spring provides tools to basically simulate the while application (with MockMvc) which permits to enable/disable the security, inject a user in the security context, share transactions between the app code and the test code, etc.). This layer is obviously expensive to develop and more code means more issues, thus more support activity.
Maybe, Java developers went too far with mocking/simulations etc and Quarkus shouldn't fall into the rabbit hole and stick to the KISS philosophy.

Stuart has proposed some improvements to mocks which I wholeheartedly think we must put enough work into to bring more familiarity to people already used to Spring's way of doing things.

Stuart Douglas

unread,
Mar 26, 2020, 8:50:20 PM3/26/20
to Daniel Petisme, Sergey Beryozkin, Quarkus Development mailing list
On Fri, 27 Mar 2020 at 04:14, Daniel Petisme <daniel....@gmail.com> wrote:
Hello,

To answer Stuart's questions
Can you elaborate on why the Restassured testing was painful?
I would separate my answer in 2 parts.
First, I did not know RestAssurred before Quarkus, so there is a natural learning curve
Most of the Quarkus/RestAssured are quite basics, and when people are already discovering Quarkus trust me if they have an issue with Restassured they will blame Quarkus...
Let's take an example
The sample projet uses java.time.Instant, and when I was testing, I had what looked like deserialization error. So I spend time to understand how I configure JsonB to unmarshall properly date/time.
Actually, the error was on RestAssured side which 1/ does not use JsonB as default object mapper out of the box 2/ needs to be configured to properly serialize dates in ISO8601 vs epoch (which one found make totally sense).
This issue was described here, Antonoio also raised it as a Quarkus issue where it was RestAssured.
https://github.com/quarkusio/quarkus-quickstarts/issues/205

So I think, couple of documentation/configuration could ease restassured testing:
1- pre-configure the defaultObjectMapper just as it's done with the application url?
2- Complete the https://quarkus.io/guides/getting-started-testing doc with links to the RestAssured doc about key topics (content-negotiation, authentication, Serial/Deserial).

+1 to both of these.
 

And BTW, I had couple of issues with jsonpath expression (I copy/pasted some tests assertions I had in Spring and they were not working exactly the same, but couple of try/fail iteration permits to figured out the proper jsonpath expression).

Secondly, is not related to Restassured specifically but more about the integration testing strategy. 
Spring proposes a complete integration mock layer (database, rest, security, etc), and Jhipster heavily relies on it to setup a test context. So in a first attempt, I try to mimic that and I failed.
https://github.com/quarkusio/quarkus/issues/1367

Ok, we can do a lot more here. It seems like Stephane, Georgios and I have all been looking into mocking, so we need a coordinated approach.

The good news is that my CDI mock PR actually provides a pretty good base for this, and there is a lot we can do here. I will send a follow up email about this to try and kick start some design discussions.
 


The position regarding mocking the application when running test is not very clear yet (at least for me), I saw you post regarding Mock improvement but I don't know how far Quarkus plan to mock the application component.
So after couple of discussions, I choose to do black box testing for the integration part. The main drawback of this option is the test setup becoming more complex (since it has to follow the functional path of the application). For example, when testing user management, before testing the update of the current user for instance, I have to:
- call the user registration endpoint, the user registration sends an activation email
- Retrieve the activation email (I used the MockMailbox) to parse the mail text to get the token
- call the activation endpoint with the token.
- Call the authentication endpoint with the freshly created user to retrieve the JWT
- finally invoke the update account with the token in headers.

While being more "realistic", the test development/debug is less siloted thus more complex to realize IMHO.

To be honest, I think every dev has its own definition unit vs integration vs whatever testing, and I don't want to fall into an expert debate.
Here, I translated what I knew from Spring to Quarkus. If I want to be critic regarding what I have done, maybe some tests are close to unit tests than other and I could probably rewrite some tests which simply instantiate the component under test (REST Resource, Service) rather than starting the whole application and go through complex layer to mock (security for instance).
Spring provides tools to basically simulate the while application (with MockMvc) which permits to enable/disable the security, inject a user in the security context, share transactions between the app code and the test code, etc.). This layer is obviously expensive to develop and more code means more issues, thus more support activity.
Maybe, Java developers went too far with mocking/simulations etc and Quarkus shouldn't fall into the rabbit hole and stick to the KISS philosophy.

So to rephrase, RestAssured testing was painful but maybe I shouldn't have done it in the first place.
Thoughts?

We need to improve this, there is quite a lot we can do here without that much work, but I think the real challenge is figuring out what makes the most sense. 

For example internally we use QuarkusUnitTest which gives a lot of flexibility in terms of what you are testing, but I don't think this is something that we want application developers using, and giving too many different options can also cause problems. I think we need solutions for:

- Mock based unit tests, that don't go over the wire
- Integration style tests via Restassured (or whatever) that also allow for setup from within the test (to get around the issues you mention above where the setup is done over the wire)
- Full integration tests where you test a running version of your app. At the moment we support this for native image, but not for the JVM version.
 

Also any other major pain points that you had?
Classloader issues
I had to use the repository pattern because on a particular test setup the Panache augmentation was not made properly (sorry it was a long time ago, I didn't keep track of the issue).
I have to retest with 1.3.0 I'll keep you informed.

This should be fixed.
 

IDE integration
It's frustrating to be able to simply click on "Run the application" or "Run the test". I'm not very used to run Maven stage from the IDE so I had play with Maven CLI to run the proper unit/integration test in debug mode.


I have a PR that should start to address this: https://github.com/quarkusio/quarkus/pull/7681
 
Surefire vs Failsafe code coverage
I tried to setup test coverage (with jacoco) and I had class loader issues


I might have a look at this today.
 
Pain points with a solution but not totally finished
Caching
https://github.com/quarkusio/quarkus/issues/6492
At the end it was not the proper solution but still the feature is not covered yet

EntityGraph loading
I tried to eagerly load an entity graph and ends up with a JPQL query (which is valid solution). I think HIbernate Panache finders could cover the need with an entity Graph definition (rather than s JQPL string).

I plan to organize a status meeting where I could go in details and discuss these points.
I hope this feedback helps you, feel free to ask me anything.

Thanks a lot for this, I will see what I can come up with to improve the testing experience.

Stuart

Emmanuel Bernard

unread,
Mar 27, 2020, 3:29:01 AM3/27/20
to daniel....@gmail.com, Quarkus Development mailing list
This is awesome !
Anyone with a bit of spare time, could you try Daniel’s work and give feedback ?

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/9b02a6ab-fb83-4ebc-81ca-da96f5f8733d%40googlegroups.com.

Daniel Petisme

unread,
Mar 27, 2020, 4:44:16 AM3/27/20
to Emmanuel Bernard, Quarkus Development mailing list
You can test the sample application, just clone it and run ./mvnw and the Quarkus app starts. I would definitely appreciate a code review.

If you want to try the generation, feel free to ping me, even with documentation, using a "not released" generator can be tricky and I can help to speed up the process

Anyway, I think a status meeting could be interesting to have a live demo + discussions.

WDYT Emmanuel ? Max gave me the last meeting attendees, how can check RedHatters availability? Do you have a tool or I simply propose slots on the ML?

Emmanuel Bernard

unread,
Mar 27, 2020, 5:29:51 AM3/27/20
to Daniel Petisme, Quarkus Development mailing list
With confinement, availability is all speculative. Propose 2 slots on doodle and we can vote

Daniel Petisme

unread,
Mar 27, 2020, 9:24:32 AM3/27/20
to Emmanuel Bernard, Quarkus Development mailing list
Ok dooddle sent.

Of course feel free to forward.

Daniel PETISME
daniel....@gmail.com

Daniel Petisme

unread,
Mar 28, 2020, 11:45:00 AM3/28/20
to Emmanuel Bernard, Quarkus Development mailing list

In the current status of the generator I used the repository pattern because some operation failed with the exact same error message as I had before the class loader refactoring.
So I thought it was related to it.

In fact, not at all.
https://github.com/quarkusio/quarkus/issues/8235
I guess there is a glitch during the Panache augmentation of method references.
No big deal since I just have to use the lambda expression rather than reference.

Daniel PETISME
daniel....@gmail.com

Reply all
Reply to author
Forward
0 new messages