I have one maven project which wanted to have service account(json file) for authentication and maven should product the .war not .jar.
Considering that, I wanted to specify the json file location into project application.properties, like this:
spring.cloud.gcp.credentials.location=file:src/main/resources/service-account/service-account-key.json
I am new to the .war world, now the problem is when i build the project locally I am able to get the json file as it is in my resource folder and I am using tomcat locally which is working fine.
But in case of when i deploy into google app engine and its war nature service-account-key.json file is not found on the mentioned location.
Can anyone help on the same, where i need to put in for that as a part of build only i can refer and use the service account json file at both the time locally and after deploy as well.
thanks for you help in advance.
According to Google Cloud documentation you have two choices for providing the credentials to your application:
1. Set the GOOGLE_APPLICATION_CREDENTIALS environment variable explicitly.
2. Pass the path to the service account in code.
You can check this link for more information: https://cloud.google.com/docs/authentication/production#auth-cloud-implicit-java
You can reference the file in resources by prepending classpath: instead of file:
See my answer here.
Related
I suppose same problem as described in question MSAL for Java quickstart sample app throws exception. When using IDE and deploying to embedded tomcat, app works. After spending one day, I figured out what is the problem.
Application AuthPageController specifies #RequestMapping("/msal4jsample/secure/aad"). This works with embedded tomcat. When deployed to tomcat server, tomcat removes application name from path since it is deployment information and exploded folder name depends on war file name. Same application can be deployed multiple times to different folders. Tomcat maps url as /secure/aad and request in this case is never handled. To fix problem, I created array of request mappings #RequestMapping(value = {"/msal4jsample/secure/aad", "/secure/aad"}).
I forked MS Azure repository and made changes. Please take a look at zdenko-s/ms-identity-java-webapp
There are other fixes too.
War file name is specified in pom.xml, no need to rename it. Removed rename step from documentation also
.gitignore wrongly specifies exclude target. Should be */target
Sharing info. Fix in my forked branch
So i am not really sure how to ask this question so I am going to try my best.
I currently have a file within my project that is used for SSO oidc configuration. For the most part we do not use it, most of the configuration comes from the dev database. The only value that we do use is the callback url, Which calls back to localhost instead of the dev environment. When my application starts up i check to see if that file exists and pretty much override dev configurations with anything in that file. Mostly so we can just return back to localhost. I also do development work and need to add or change additional values locally so the ability to override is needed for me specifically. So the issue i am trying to find a solution for is when we jar the application that oidc configuration file also gets included and deployed to the server. This then will make the dev environment point to localhost. I tried excluding that oidc configuration file from gradle but then when i run the application locally it also excludes it and then does not have the file locally. I am trying to figure out a way to only exclude that oidc file configuration when deployed to dev/test/prod but keep it locally. Or maybe even a different approach would work too.
For this case, you can create a local directory in your resources folder, then in gradle you can exclude this directory specifically to be bundled when jar is created using below:
jar {
exclude ("DIRECTORY-TO-EXCLUDE/**")
}
I inherited a Java app that is configured to run in Google App Engine. My pom includes the com.google.appengine.appengine-maven-plugin plugin, which may or may not be related to this question.
In my src directory, in the WEB-INF directory, I have a "app.yaml" file. But when my project is built into a war, the target directory has both a "app.yaml" file and a "appengine-web.xml" file. How did this "appengine-web.xml" file get here?
The first line of this "appengine-web.xml" file says <!-- Generated from app.yaml. Do not edit. -->. If this file was generated from an "app.yaml" file, then what generated it? Which plugin/function has created this file?
As mentioned in the official documentation appengine-web.xml Reference:
App Engine Java applications use a configuration file, named appengine-web.xml, to specify information about your app and to identify which files in the app's WAR file are static files (like images) and which are resource files used by the application.
So, this is created by default, by the App Engine environment, when using the App Engine Maven plugin, so you can handle some specific settings and configurations. You can find more details on these settings here, but it includes the setting of environment variables, how to scale the application - manual, basic or automatic - etc. In addition to that, you can check this example of a sample app that is deployed into war and the file is created as well. Please, bear in mind that this is only on Java 8.
To summarize, this file is created by the App Engine environment when using this plugin, not by a specific function. In this official documentation here, it indicates this as well:
The artifact you used to create the project has done the basic src/main/webapp/WEB-INF/appengine-web.xml configuration for you
So, this confirms that it was created via the plugin. Besides that, it shows the message of the relation with app.yaml, because they work together and each one of them has a specific use and settings that are needed for your application to work correctly.
Let me know if the information helped you!
This was a non-documented feature of App Engine Maven Plugin that was removed about two years ago.
https://github.com/GoogleCloudPlatform/app-maven-plugin/issues/426#issuecomment-665757462
I have managed to develop a controller and service in the backend(spring) which successfully uploads a file on the server.
As far as upload location is concerned, I have used System.getProperty("user.dir") to get the path of the current project after which I have appended my custom folder structure specified in application.properties file. Moreover, I am saving the file path in database.
So, while trying to access the file from localmachine(localhost) on anchor tag, the file is successfully getting opened(downloaded to be precised).
However, when I push my application to the server, the project is added as a WAR java file. In the server, the file is getting uploaded to a folder which is outside my war file.
Hence I am not able to access the file from URL.
Please let me know if there is any way to fix this. Thanks in advance.
You could configure a path in your application.properties. In production, it would be absolute path and in dev a relative path. Alternatively, you could configure a url in yml using file:prefix for prod and classpath: prefix for dev to use ResourceLoader.
I am coding a website using java servlets and am using eclipse and tomcat. When I test it using localhost, it works fine. But when I am deploying it on my actual website, the directory structure is messed up and the files are not called properly.
My eclipse directory structure on localhost is
Project Name
.src/packageName/java files
.WebContent/HTML files.
When I make a call from the html files, I use the relative location and tomcat automatically knows to look in the src/packageName folder. For example, from the /WebContent/login.html page makes a onClick call as follows,
. This will automatically trigger the java file in /src/packageName/welcome
When I am deploying it in my actual website, the WebContent/login.html is throwing an error WebContent/welcome file is not found. How do I tell my website to search in /src/packageName folder?
Hmm...have you been sure to package the application as a war for deployment.