JHIpster microservice application without registry generates configuration for UAA registry - jhipster

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

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.

Related

aws: missing credentials in config when using systemd

I'm trying to deploy a small Node.js server to a Linux EC2 on AWS. This server uses the AWS JavaScript SDK. The ~/.aws/credentials and ~/.aws/config are properly filled out. Everything works when I run the server by node index.js or npm start, but if I run it using systemd, I get the following response:
{ message: 'Could not load credentials from any providers',
retryable: false,
time: 2018-07-23T20:12:59.057Z,
code: 'CredentialsError' }
For some systems ~ becomes / when run from a service. This means the path is /.aws/credentials. For your system try copying "~/.aws" to "/root/.aws". Then try copying to "/.aws". One of these will work.
You can also use a json file and specify that when creating your client.
Create the file "/mysite/aws_config.json" with the following contents:
{
"accessKeyId": "YOUR_ACCESS_KEY_ID",
"secretAccessKey": "YOUR_SECRET_ACCESS_KEY",
"region": "YOUR_REGION"
}
Then load the credentials with this statement:
AWS.config.loadFromPath('/mysite/aws_config.json');
This way you can keep your site's configuration in one directory.
There are many methods to specify credentials. The AWS documentation for node.js SDK has lots more.

Jhipster Registry Release 3.2.4 - can't change admin password

I'm using registry release 3.2.4 on Windows environnement (dev).
I want to change the default admin password.
According the documentation I just need to define security.user.password on my application-*.yml file.
So my central-config/application-dev.yml become
jhipster:
security:
authentication:
jwt:
secret: my-secret-token-to-change-in-production
registry:
password: admin123
I start my registry java -jar jhipster-registry/jhipster-registry-3.2.4.war --spring.profiles.active=swagger,dev,native (the parameter --spring.profiles.activeis set here just to be sure my config file is correctly load).
I try to connect on http://127.0.0.1:8761/#/ with admin user...but my new password doesn't work (just the default "admin" password still work).
When the registry launch, i've got these warnings
WARN 1152 --- [ main] c.n.c.sources.URLConfigurationSource : No URLs will be polled as dynamic configuration sources.
WARN 1152 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Bean with key 'zuulEndpoint' has been registered as an MBean but has no exposed attributes or operations
And when i try to connect, this warning
WARN 1152 --- [ XNIO-2 task-1] o.s.c.n.zuul.web.ZuulHandlerMapping : No routes found from RouteLocator
When i look the config load on my application, it's look all right
My cloud configuration
I try to add -e JHIPSTER_SECURITY_AUTHENTICATION_JWT_SECRET=my-secret-token-to-change-in-production and -e SECURITY_USER_PASSWORD=admin123 when i launch my registry, but still don't work.
Any ideas?
Thanks
Password has to be set in 2 places; in the application.yml of the registry and in the registry clients (the services and gateways) in their own bootstrap.yml because properties in central-config are read only once the app has been able to connect to the registry.
You can also set it in an environment variable SECURITY_USER_PASSWORD and use placeholders in those files to avoid exposing it in your git repo while managing it in a single place.
I just had to cope with the same issue with JHipster Registry 4.1.1. As the documentation and the command line option stated to use spring.security.user.password property I've updated my application.yml as follow
jhipster:
security:
authentication:
jwt:
secret: my-secret-token-to-change-in-production
spring:
security:
user:
password: admin1234
It works as expected for me.

Running jhipster-registry in native profile: central-config folder not rode

I am currently trying to run jhipster-registry in dev profile to serve the configurations to a jhipster microservice application.
I've followed this official jhipster registry doc and:
have built it from sources, and launched it as follow:
./jhipster-registry-3.0.0.war --spring.profiles.active=dev
And as the doc states, i have put the central-config directory containing <mymicrosericeappname>-dev.yml alongside the jhipster-registry generated war file.
When i launch jhipster-registry, everything is ok,
but when i run my microservice application, it connects to the registry (i can see it in the jhipster-registry dashboard), but i realize that it is reading the application-dev.yml file located at src/main/resources/config/ inside the microservice app.
I dont know if i misplaced the central-config folder...
That said, i really need to know what's wrong.
Thanks
The config directory is specified in bootstrap.yml in search-locations property.
spring:
cloud:
config:
server:
native:
search-locations: file:./central-config
Rather than specifying a relative path (relative to where you launched the regsitry from), you may want to specify an absolute path:
search-locations: file:/home/something/central-config
Also rather than using dev profile, you can use prod with native :
./jhipster-registry-3.0.0.war --spring.profiles.active=prod,native
Thanks to #GaelMarziou, his answer helped me found why the central-config was not being rode.
In fact the Spring Cloud Config bootstrap configuration for the "dev" profile bootstrap.yml file gives this:
cloud:
config:
server:
git:
uri: https://github.com/jhipster/jhipster-registry-sample-config
native:
search-locations: file:./central-config
So each time i ran jhipster-registry, it was pointing the git repo and not the central-config directory.
To get it work, i had to launch the registry in dev,native profile :
./jhipster-registry-3.0.0.war --spring.profiles.active=dev,native
Nevertheless the documentation states this:
Using the dev profile will run the JHipster Registry with the dev and the native profiles.
Which is not really true... considering my struggling.

Jhipster - Error while starting a jhipster mysql project

I am trying jhipster and ran into the following error while starting the application which is configured to use mysql as the backend:
Your database connection pool configuration is incorrect! The applicationcannot start. Please check your Spring profile, current profiles are: [dev]
I have the database created and mysql is up and running at the right ports
From troubleshooting this in my IDE, it appears that the datasource properties are null while trying to configure liquibase.
My application-dev.yml
server:
port: 8080
spring:
profiles: dev
datasource:
dataSourceClassName: com.mysql.jdbc.jdbc2.optional.MysqlDataSource
url: jdbc:mysql://localhost:3306/test
databaseName:test
serverName:localhost
username: admin
password: xxxxx
cachePrepStmts: true
prepStmtCacheSize: 250
prepStmtCacheSqlLimit: 2048
useServerPrepStmts: true
jpa:
database-platform: org.hibernate.dialect.MySQLInnoDBDialect
database: MYSQL
openInView: false
show_sql: true
Any thoughts on what should I try next to get past this erorr?
I don't think you should write the database name in the url AND in the databaseName properties.
-> can you remove the databaseName configuration and see what happens?
Otherwise, please send the stacktrace.
If you're using Eclipse, it may be that the source folders configuration is wrong. When I imported the project, for some reason the src/main/resources and src/test/resources folders had all files excluded.
Check your build path and make sure all files are included.

Deploying war in Jboss 7.0.1 through Commandline

I have a war file and I need to deploy it on Jboss 7.0.1 Server. Now I have gone through the documentation, but didnt find any thing to deploy a war file. Moreover for deploying your build through command line you generally have to use maven. So do we need for the war as well? If so, does it affects the war file?
FYI : I am using linux (CentOs5)...
You can deploy a .war file using the Management Command Line Interface. The specific documentation for it is located here: JBoss AS7 Admin Guide - Deployment, with the relevant sections per the below. You might also like to have a quick watch of the video: 5 Ways To Deploy Your Applications To JBoss AS7
CLI Deployment To A Managed Domain
The process of distributing deployment binaries involves two steps: You need to upload the deployment to the repository from which the domain controller can distribute it's contents. In a second step you need to assign the deployment to one or more server groups:
Using the CLI you can do it one sweep:
[domain#localhost:9999 /] deploy ~/Desktop/test-application.war
Either --all-server-groups or --server-groups must be specified.
[domain#localhost:9999 /] deploy ~/Desktop/test-application.war --all-server-groups
'test-application.war' deployed successfully.
[domain#localhost:9999 /] deploy --help
[...]
After you've uploaded the binary using the "deploy" command, it will be available to the domain controller
and assigned to a server group:
[domain#localhost:9999 /] :read-children-names(child-type=deployment)
{
"outcome" => "success",
"result" => [
"mysql-connector-java-5.1.15.jar",
"test-application.war"
]
}
[domain#localhost:9999 /] /server-group=main-server-group/deployment=test-application.war:read-resource
{
"outcome" => "success",
"result" => {
"enabled" => true,
"name" => "test-application.war",
"runtime-name" => "test-application.war"
}
}
In a similar way it can be removed from the server group:
[domain#localhost:9999 /] undeploy test-application.war --all-relevant-server-groups
Successfully undeployed test-application.war.
[domain#localhost:9999 /] /server-group=main-server-group:read-children-names(child-type=deployment)
{
"outcome" => "success",
"result" => []
}
CLI Deployment To A Standalone Server
Deployment on a standalone server works similar to the managed domain, just that the server-group associations don't exist. You can rely on the same CLI command as for a managed domain to deploy an application:
[standalone#localhost:9999 /] deploy ~/Desktop/test-application.war
'test-application.war' deployed successfully.
[standalone#localhost:9999 /] undeploy test-application.war
Successfully undeployed test-application.war.
CLI Deployment to Standalone Server (one liner Shell command)
You can deploy a WAR in one shot from the Shell as well. This is useful for Bash scripts or Unix aliases. NOTE: This exposes the password, so only use it for personal development instances. Ensure $JBOSS_HOME is set, and change Password and WAR file path & name below as needed:
$ $JBOSS_HOME/bin/jboss-cli.sh -u=admin -p=MY_PASSWORD --controller=localhost:9990 --connect --command="deploy /path/to/MY_APP.war --force"
Footnote: As you would know, you've got the Management Console for deployment, as well as the deployment scanner. The former is popular as any GUI would be, but the latter is more for development. I try to use the CLI as much as possible, as the learning curve is well worth the effort for the power of batch scripting and the sheer scale of low level operations that are exposed by the CLI API. Very cool stuff. I should add for sake of transparency that I work on the AS/EAP documentation team, so I might be biased.
Above answer confused me.. So, here is the solution which is simple
and worked for me.
Make sure jboss is already running. Commandps -ef | grep jboss
navigate to JBSS_HOME/bin/ and open JBOSS CLI. Command to open CLI is./jboss-cli.sh.
Once CLI is opened. You'll see like this [disconnected /]. Now, run the command connect. It will show like this [standalone#localhost:9999 /]
now, do deployment using the below command.
"deploy /YOUR_WAR_PATH.war".
Example: "deploy /tmp/my_app.war"
That's all we need to do.
Happy Learning..

Resources