I just created a fresh Jhipster 7.0.1 project and I'm trying to use the Jhipster Control center.
In the official page, it says:
As soon as an application registers on a server (consul or eureka), it
will become available in the list.
I just started all my microservices, they are all registered in the Jhipster registry but they are still not showing up on the Control center.
Am I forgetting to do something? I didn't do any extra configuration, just created the project and started.
To use JHipster Control Center, you must edit src/main/docker/jhipster-control-center.yml to configure it to use your chosen discovery service (in your case Eureka with the JHipster registry).
The instructions are in the jhipster-control-center.yml file comments, you got to set 2 environment variables in jhipster-control-center.yml and remove "127.0.0.1:" prefix from ports in the jhipster-registry.yml file.
Related
I recently read about ServiceFabric offering some kind of Autorefresh mode, considering its infrastructure and the cluster running independently.
So, according to what I've wrote, all I need to do it go to my project, check the properties and set the "Application Debug Mode" to Refresh Application.
Basically that is what I did now, but I don't quite see the difference. There's no repackaging happening at all.
Do I have to run some kind of cmdlet in the background, as it is the case with e.g. webpack watch?
The docs explains Refresh Application as follow.
Refresh Application This mode enables you to quickly change and debug
your code and supports editing static web files while debugging. This
mode only works if your local development cluster is in 1-Node mode.
This is the default Application Debug Mode.
On other application debug options, Visual Studio creates a package and deploy it to the cluster and register the application to run on Service Fabric, the package will contain all binaries compiled that are needed to run the application.
The main difference between the Refresh Application and the others, is that the package created is a symbolic link to the source in the Dev machine, you are not actually copying the package with the binaries, when you change the static files, it will be the same files used by the deployed application in SF, this will make more flexible to make changes without repackaging, registering and deploying the application on every change.
PS: It does not work the same way as the watch feature for nodeJs development, it is just to avoid the package deployment. You could just reload the page though.
This post explain in more details.
I want to insert a sidebar into the body of the element body in a JHipster application.
Is there a command that can help me?
There is no module available for converting JHipster's nav bar into a sidebar. JHipster generates the code, but you will need to customize it yourself depending on your requirements.
You can see available JHipster commands by running jhipster --help, and the command's options by running jhipster service --help (example showing the service subgenerator options).
JHispter also offers modules, which extend JHipster's functionality with new commands. The full list can be viewed in the JHipster Module Marketplace. No module offers a sidebar option at this point in time.
In order to present a brand new way of developing a web application, our team decided to create an Angular 2 web application that will be integrated within an already existing Maven Project in Eclipse Mars which DOES NOT use NodeJS nor Angular.
We are currently using the frontend-maven-plugin belonging to com.github.eirslet and managed to download and install both node.exe and npm.
Now, here is the deal: our web application has its own package.json file with all the configuration required to run properly, BUT we would like to be able to differentiate between the web applications, as each one of them belongs to a different working directory (i.e. com.webapp.app01, com.webapp.app02, ...).
As the plugin does not let the user use the npm install command on different directories, we were wondering about how we could reach this goal... maybe using a general package.json, but generating all .js and dependency files in each project directories.
Would that be something even possible?
Could you give us some help?
Thank you.
Cheers!
What I would suggest is to have a multi-module maven project, with a common parent, and children, that would give you this kind of architecture:
parent-project
|-child-project1 (java project)
|-child-project2 (webapp1)
|-child-project3 (webapp2)
|....
|-child-projectn (webapp n-1)
This way you can have for each web-app the frontend plugin available. And you can handle the flow of the build from the parent project (for instance if webapp2 needs to be built before webapp1, you can orchestrate it from the parent)
We decided to generate all the libraries locally and upload them to SVN, due to the fact that the already existing structure cannot be changed and the maven plugin is too much limited for our purpose.
Thank you for your replies, though. :-)
I have installed IBM Bluemix tools on Eclipse and created a 'Hello World' JSF and EAR project. While creating I have chosen a Bluemix runtime environment. Now I try to deploy EAR from Eclipse, it successfully deployed and started but when I try to open it I get the following error:
Not Found The application or context root for this request has not been found: [Ljava.lang.Object;#bdb04149
What have I missed? Is there comprehensive tutorial to deploy Java EE web applications on Bluemix available anywhere?
You can deploy complete EAR files on Bluemix yes. Using the eclipse tools also makes it much easier. This link has steps on how you can do this https://www.ng.bluemix.net/docs/#manageapps/eclipsetools.html
Further down the page (you can use the menu on the left too) there are steps on how to push an EAR. It might be with pushing a complete Liberty profile to get finer control on the application behavior. This link has further details on pushing Liberty apps and the profile itself https://www.ng.bluemix.net/docs/#starters/liberty/index.html#liberty
If you deployed an EAR (containing your JSF app) you need to add the web module name to the URL, for example, if your project is called testJSF, your URL will look like this:
http://testApp.mybluemix.net/testJSF/
And of course, if your web page is not called index.xxx you need to add the web page name as well, for example:
http://testApp.mybluemix.net/testJSF/textPage.xhtml
or
http://testApp.mybluemix.net/testJSF/textPage.faces
I have successfully created a few loopback projects using
slc lb project *myproject*
command but now I have a pre-existing node project that I would like to use loopback in.
Is there a recommended best practice around the migration to loopback?
Is it just a matter of including the relevant module references in my package.json and running npm install? Or do also need to make some changes to my app.js?
Will I need to manually create the models.json and datasources.json?
Any insignts appreciated.
Edit: I added the relevant loopback modules to my package.json, replaced my express requires with loopback, manually added a datasources.json, and models.json and it all seems to have worked.
The only remaining issue is that when I bring up my explorer view the shell comes up but no api endpoints even though I have models defined in my models.json file.
Edit: I added the relevant loopback modules to my package.json, replaced my express requires with loopback, manulally added a datasources.json, and models.json and it all seems to have worked.
The only remaining issue is that when I bring up my explorer view the shell comes up but no api end points even though I have models defined in my models.json file.
To load and process models.json and datasources.json, you have to "boot" your LoopBack application.
Assuming you have installed loopback 2.x in your project, and you want to use the old 1.x project layout scaffolded by slc lb, here are the instructions:
Install loopback-boot 1.x. Make sure you are not using 2.x or newer, as 2.x changed the project layout.
npm install --save loopback-boot#1.x
Modify your main application file (e.g. app.js) and add the following lines:
// at the top
var boot = require('loopback-boot');
// after you have created `app` object
// and configured any request-preprocessing middleware
boot(app, __dirname);
Please consider using the new 2.x project layout, see Migrating apps to version 2.0 for information on how to migrate your "models.json" into the new format.
Is there a recommended best practice around the migration to loopback?
I suggest scaffolding a new app using slc loopback and moving your old apps files to the relevant directories.
is it just a matter of including the relveant module references in my package.json and running npm install or do also need to make some changes to my app.js?
This will be part of the migration process, you will also need to configure app.js to meet your needs (like setting up middleware, etc)
will I need to manually create the models.json and datasources.json?
No, when you scaffold the app using slc loopback, they will be automatically generated in the new project.
The only remaining issue is that when I bring up my explorer view the shell comes up but no api end points even though I have models defined in my models.json file.
Did you create the files in commmon/models manually? Try creating them through slc loopback:model and the tool will add the configurations in server/model-config.json for you.