0

Why does Yeoman Jhipster generator generate code for JHipster UAA service registration with JHipster Registry even when we specify that we are not going to use JHipster Registry during Microservice application generation.

Following are the options selected by me during the Micorservice app generation

? (1/16) Which *type* of application would you like to create? Microservice application
? (2/16) What is the base name of your application? service
? (3/16) As you are running in a microservice architecture, on which port would like your server to run? It should be unique to avoid port conflicts. 8081
? (4/16) What is your default Java package name? com.test

################ Jhipster registry not to be used ##########################
? (5/16) Do you want to use the JHipster Registry to configure, monitor and scale your microservices and gateways? No

################ Use Jhipster UAA #######################################
? (6/16) Which *type* of authentication would you like to use? [BETA] Authentication with JHipster UAA server (the server must be generated separately)
? (7/16) What is the folder path of your UAA application? ../uaa

? (8/16) Which *type* of database would you like to use? SQL (H2, MySQL, MariaDB, PostgreSQL, Oracle)
? (9/16) Which *production* database would you like to use? PostgreSQL
? (10/16) Which *development* database would you like to use? H2 with in-memory persistence
? (11/16) Do you want to use Hibernate 2nd level cache? No
? (12/16) Would you like to use Maven or Gradle for building the backend? Maven
? (13/16) Which other technologies would you like to use?
? (14/16) Would you like to enable internationalization support? No
? (15/16) Besides JUnit and Karma, which testing frameworks would you like to use?
? (16/16) Would you like to install other generators from the JHipster Marketplace? No

After selecting these options when I generate the application it has following configuration for UAA inside application-dev.yml

jhipster:
    http:
        version: V_1_1 # To use HTTP/2 you will need SSL support (see above the "server.ssl" configuration)
    # CORS is only enabled by default with the "dev" profile, so BrowserSync can access the API
    cors:
        allowed-origins: "*"
        allowed-methods: GET, PUT, POST, DELETE, OPTIONS
        allowed-headers: "*"
        exposed-headers:
        allow-credentials: true
        max-age: 1800
    security:
        client-authorization:
            access-token-uri: http://uaa/oauth/token
            token-service-id: uaa ############ Why does it need service ID if it's not dependenty on Jhipster Registry
            client-id: internal
            client-secret: internal

Following are the two lines which are for UAA

access-token-uri: http://uaa/oauth/token
token-service-id: uaa

As it can be seen microservice configuration is created to look for a service named uaa. If this application is not dependent on the Jhipster Registry or any other registry for that matter, why this configuration is looking for a registered service name?

I expect that I only need to specify the UAA URL and credentials and that should be it in absence of a registry.

Any help is appreciated.

Jhipster version

{
  "devDependencies": {
    "generator-jhipster": "4.6.1"
  }
}

Output of yo jhipster:info

##### **JHipster Version(s)**

```
C:\workspace\test3\service
`-- generator-jhipster@4.6.1 

```


##### **JHipster configuration, a `.yo-rc.json` file generated in the root folder**


<details>
<summary>.yo-rc.json file</summary>
<pre>
{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "com.test"
    },
    "jhipsterVersion": "4.6.1",
    "baseName": "service",
    "packageName": "com.test",
    "packageFolder": "com/test",
    "serverPort": "8081",
    "authenticationType": "uaa",
    "uaaBaseName": "uaa",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Memory",
    "prodDatabaseType": "postgresql",
    "searchEngine": false,
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "jwtSecretKey": "replaced-by-jhipster-info",
    "enableTranslation": false,
    "applicationType": "microservice",
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "skipClient": true,
    "skipUserManagement": true,
    "clientPackageManager": "npm"
  }
}
</pre>
</details>


##### **JDL for the Entity configuration(s) `entityName.json` files generated in the `.jhipster` directory**

<details>
<summary>JDL entity definitions</summary>

<pre>





</pre>
</details>


##### **Environment and Tools**

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
Picked up _JAVA_OPTIONS: -Dfile.encoding=UTF-8

git version 2.10.0.windows.1

node: v6.11.1

npm: 3.9.6

bower: 1.7.7

gulp:
[07:50:35] CLI version 3.9.1

yeoman: 2.0.0
11thdimension
  • 10,333
  • 4
  • 33
  • 71
  • Which version of jhipster? if you think you found a bug open an issue on github and provide details like output of `yo jhipster:info`. – Gaël Marziou Jul 15 '17 at 00:13
  • I'm using the latest one for now, 4.6.1. I'm not sure if it's a bug or desired behavior. Do you know if a `microservice + uaa` combo can be used without a service registry (Jhipster or Eureka)? – 11thdimension Jul 16 '17 at 10:25
  • I don't know if we ever tested it as it's very unusual. What would be the benefit? Have you made it work? – Gaël Marziou Jul 16 '17 at 10:57
  • I checked the output of the infor command as you suggested, by default it seems to be using Eureka, so it makes sense that it would generate code for service discovery. I was under the impression that if I don't select any of the service registry options it would not use one. – 11thdimension Jul 17 '17 at 01:47
  • It would be beneficial for small applications which have no need for a service registry. In general using service registry makes sense if the service URL changes frequently. Which is what Netflix probably intended with Eureka as they had too many services and they didn't want to keep track of the URLs used by services after they were restarted. However this doesn't make sense to use in a microservice environment like Cloudfoundry, which provides fixed `routes` (URLs) for each microservice. – 11thdimension Jul 17 '17 at 01:51
  • @GaëlMarziou I checked again after seeing your comment on the answer, you're right I do get the `"serviceDiscoveryType": false,`. So I deleted my answer as my conclusion was that it was using `eureka` by default so it did make sense for JHipster to generate code for `uaa` service discovery. So as of now, I have no clue why it's generating the uaa service discovery config. – 11thdimension Jul 17 '17 at 11:47
  • Well maybe @DavidSteiman can answer here or you could open an issue on github as it seems that either "no discovery" choice should not be proposed or its implementation should be modified. If you open an issue, best is to delete this question as we try to avoid cross posting. – Gaël Marziou Jul 17 '17 at 12:07
  • Sure, I will open issue by EOD. – 11thdimension Jul 17 '17 at 12:16

1 Answers1

0

Sorry for the late answer. The only real unnecessary piece of generated code is that "token-service-id", as this is specific to having a service discovery inside your application stack (say, Netflix Eureka, Consul etc.)

If you don't have service discovery, you still need your application to access the UAA. So it's sufficient to just keep the access-token-uri and doesn't need to fill the token-service-id flag.

Basically, it should work, if your app is able to resolve the provided URI. But if not, feel free to open an issue on GitHub.

David Steiman
  • 3,055
  • 2
  • 16
  • 22
  • Thanks for your response, I'm no longer working on that project however I remember that it didn't work out of the box with UAA and I had to modify and override some Spring security beans and all of the `registration` and user management methods. For that I used `uaa-java-client` to which was sadly not up to date and I had to modify that too to add the new properties that my version of UAA was using. Fork: https://github.com/ConsciousObserver/uaa-java-client – 11thdimension Jun 26 '18 at 02:55