We Keep Coding

How to use environment variables on a Spring Boot and Gradle application?

I explain my problem;
I have a web app developed using Vue.js and Spring Boot, this application working a PDF sheet and saves the file that is generated by Java, I use two lines of code to separate my development part from the production part (I leave you the 2 lines of code like this you understand the concept well)
FileReader leggoFile = new FileReader(System.getProperty("user.dir") + "/temp/webapps/foolder/foolder/file.pdf");
// FileReader leggoFile = new FileReader(System.getProperty("catalina.base") + "/temp/webapps/foolder/foolder/file.pdf");
This whole application is built using the "bootWar gradle plugin" which returns me a .war which I will then upload to a Tomcat server;
My goal is this:
I would like to set a single environment variable so that if I want to build the project I don't have to comment/uncomment that line for example:
FileReader leggoFile = new FileReader({{variableEnvironment}} + "/temp/webapps/foolder/foolder/file.pdf")
my question is this:
How dp Gradle and Spring Boot handle environments? Is there a way to separate environments? Is this possible or should I start thinking differently?
I tried to search on something but unfortunately I was tied to the problem that I don't understand how the .war file is generated through the BootWar Gradle plugin, also searching on the internet I understood that environment Gradle and environment Spring are two separate things but in general even if I know the line of code is wrong in the beginning my question is always the same:
How are environment variables handled in Spring and Gradle?

With Spring Boot, you can add properties to your application by adding an file named application.yaml to your resources folder (src/resources/). In addition you can add properties through application-{profile}.yaml to add properties only for given Spring profiles. For instance application-test.yaml would only be read if "test" is an active profile. When booting up the application, Spring will first read application.yaml, then any profile-specific YAML-files, such that any overlapping properties are replaced.
There are several approaches to injecting the property. A simple solution is to add a field to your component annotated with #Value("${PATH}) and replace PATH with the property's path in the YAML.

Which directory is the .properties file located for OOTB ATG Handlers (i.e. ProfileFormHandler)?

I'm working to debug a custom FormHandler that extends ATG's out of the box ProfileFormHandler and want to know if any of the methods (as well as which ones) were overridden by the custom java code. I'm having no success with finding where the .properties file lies in correlation with the ProfileFormHandler.java file.
The custom FormHandler is named "MYKProfileFormHandler.java" and is located at the filepath myk/userprofiling/MYKProfileFormHandler.java

Once the server comes up, use the dyn/admin to find where the properties file is located. Use the following URL with your hostname and port
http://host:port/dyn/admin/nucleus/atg/userprofiling/ProfileFormHandler/?propertyName=serviceConfiguration
On this page, you'll find the properties configuration at different module layers. You'll find the properties setup in your application towards the bottom. It will look something like this:
/u02/oracle/domains/servername/Domain/servers/instancename/tmp/_WL_user/Estore/qwo6y/war/WEB-INF/ATG-INF/DCS/config/config.jar/atg/userprofiling/ProfileFormHandler.properties
This is the temporary location where your application server (in this case weblogic) would extract it for its use. But this helps you to find which module has this jar. In the above example, DCS is the module.
Like bated had mentioned, you'll see that in the config.jar inside your built EAR.
Also, I am assuming that you've the source code. Just search for ProfileFormHanlder and you can find it. Please note that even though your custom formhandler is MYKProfileFormHandler, the component is still ProfileFormHandler.

To view all configuration applied to any component (e.g. a form handler) open up dyn/admin and locate the component you are searching for (http://localhost:8080/dyn/admin/nucleus/atg/userprofiling/ProfileFormHandler/) then select 'View Service Configuration'.
This will provide the path to where the config exists and the order in which the config is applied to your component.

config.ini file properties being replaced by another file properties in OSGI Run Time

I have an option in my config.ini file to set proxy settings in my OSGI application, eg:
http:proxyHost= 192.168......
However, when I set them, out of nowhere in "org.eclipse.core.net.prefs" file they are overridden, eg:
proxyData/http/host=something else ...
I am wondering whether somehow eclipse thinks that I am trying to reconfigure its own proxy settings, if they exist ? I am not really confident what I am doing in the moment, so any help is appreciated.

The name of the preference file clearly states the name of the bundle that is using it. You are talking about org.eclipse.core.net.prefs meaning that the bundle using these properties is org.eclipse.core.net
You are talking about your OSGi application and Eclipse. Are you using Eclipse as an IDE to run your application or you have standalone OSGi application running in equinox?
In general the answer to your question is that if you need to have system variables for proxy e.g. http.proxyHost and http.proxyPort you will need to find out if you really need this bundle "org.eclipse.core.net".
If you do not need it just remove it from your launch configuration and the proxy settings will not be overwritten. If this is not possible try to configure it using the file you've mentioned "org.eclipse.core.net.prefs" or even better you can do it programmatically using org.eclipse.core.net.proxy package services.

Failed to import bean definitions from URL location [classpath:applicationContext-core.xml]

I'm working on a java project with spring on eclipse using Maven, and running on a Tomcat server v6.0. Everything was working fine since yesterday morning.
Here his my problem : I'm building my project, I got a build success. Then I start my Tomcat server and got this error :
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:applicationContext- core.xml]
Offending resource: ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [applicationContext-core.xml]; nested exception is java.io.FileNotFoundException: class path resource [applicationContext-core.xml] cannot be opened because it does not exist
I found out similar problem on some website but none of them give me a solution that worked for me.
It seems that eclipse isn't able to find applicationContext-core.xml when I'm doing this :
<import resource="classpath:applicationContext-core.xml" />
However, I do have the needed jar file nad-core-0.0.1-SNAPSHOT.jar in WEB-INF/lib containing applicationContext-core.xml.
I even tried to add it manually to the classpath but I was still having the same problem.
I keep on looking for a solution, when suddendly it work again once after restarting Eclipse and building while Eclipse was still updating indexes and my project was having this strange status Hg status pending instead of default. Surprised by this result I decide to build again my project after restarting Eclipse and I got the error again and I enable to make it work again. It's quite annoying...
This looks to be a really random problem.
Thanks a lot for your help :)

As you've not specified you web application structure. I assume you've a simple web application at hand with the following structures
webapp
WEB-INF/classes/applicationContext.xml
WEB-INF/lib/nad-core-0.0.1-SNAPSHOT.jar/applicationContext-core.xml
Application context.xml refers to the applicationContext-core.xml file using the import tag. I did encounter a similar situation in my web application, here're the check lists that you should go through and may be one of them can apply to your situation.
Check the generated snapshot jar file for the applicationContext-core.xml file and make sure it is in the root directory of the jar. As silly as it sounds, this was the root cause of the issue I faced in my deployment.
Make sure your Maven Pom.xml file is configured to include this XML file from the resources folder. You can use the resource tags in the build phase of Maven to package them within the jar file itself.
You can try removing the import tag from application context.xml file and instead load both of them from Spring's webapplication context itself.
Add a context loader listener class from spring org.springframework.web.context.ContextLoaderListener
Add context-param contextConfigLocation with value classpath:applicationContext-core.xml,classpath:applicationContext.xml. Spring has the ability to dynamically sort out the dependencies before initiating the bean factory.
Hope this check list helps.

I get pretty much the same config, six years later, I got the same error.
I also restart Eclipse, and it solved the issue.

Problem creating an Embedded Jetty Endpoint in a NetBeans Platform Application using System.setProperty

I created a Netbeans Platform Application using Netbeans 7.0.1 and the JDK 1.7.
I implemented my own Web Application on a normal module using Embedded Jetty 7.4.5 (consisting of a Web Service and a couple of servlets), and I created a Library Wrapper Module including all the Jetty jar files and the "jetty-j2sehttpspi-7.4.5.v20110725.jar" that I needed to be able to publish the Web Service's Endpoint. The Web module has a dependency on the Jetty module.
The code I'm using is this:
System.setProperty("com.sun.net.httpserver.HttpServerProvider",
"org.mortbay.jetty.j2sehttpspi.JettyHttpServerProvider");
server = new Server();
JettyHttpServerProvider.setServer(server);
//We read the config file
String[] configFiles = {"etc/jetty.xml"};
for(String configFile : configFiles) {
XmlConfiguration configuration =
new XmlConfiguration(new File(configFile).toURI().toURL());
configuration.configure(server);
}
// Web Services
QueryWeb qWS = new QueryWeb();
Endpoint.publish("http://0.0.0.0:" +
(server.getConnectors()[0].getPort()) + "/ws", qWS);
// Servlets
HandlerCollection hc = (HandlerCollection)server.getHandler();
ServletContextHandler sch =
new ServletContextHandler(ServletContextHandler.SESSIONS);
sch.setContextPath("/web");
sch.addServlet(stream.class, "/stream");
// We add the servlet handler to the server's context handler collection
// because it's the one used by the Web Service Endpoint
ContextHandlerCollection chc = (ContextHandlerCollection)hc.getHandlers()[0];
chc.addHandler(sch);
server.start();
When I try and run the application, I get the following error after the "Endpoint.publish" call:
Exiting C:\Program Files (x86)\NetBeans 7.0\harness\run.xml.
Exiting C:\Program Files (x86)\NetBeans 7.0\harness\run.xml.
C:\Program Files (x86)\NetBeans 7.0\harness\suite.xml:500:
The following error occurred while executing this line:
C:\Program Files (x86)\NetBeans 7.0\harness\run.xml:225:
The following error occurred while executing this line:
C:\Program Files (x86)\NetBeans 7.0\harness\run.xml:193:
The application is already running within the test user directory.
You must shut it down before trying to run it again.
As far as I understand, this is happening because the system can't find the "org.mortbay.jetty.j2sehttpspi.JettyHttpServerProvider" class. Therefore it defaults back to the web server included in the JDK, which causes a conflict since we get both web Servers (Jetty and the JDK's) trying to run on the same port (in this case it's 8081).
The only way I managed to fix this problem was by copying all the Jetty jar files into the JRE's "lib/ext" folder (copying only the "jetty-j2sehttpspi-7.4.5.v20110725.jar" results in no errors, but the server won't start). In this way the system can find the class it needs and all it's dependencies.
I suppose that what's going on is that even if NetBeans uses it's own classpath loader, the System.setProperty method is ignoring this and trying to access the standard classpath, and since a NetBeans Platform Application doesn't actually let you change the classpath directly (that would beat the whole purpose of having modules administered by the NetBeans platform), I don't really know how to make it use the library included in the wrapper module.
I can keep developing the application with the temporary solution I found, but honestly, copying stuff into the JRE folders is not an acceptable solution and will eventually result in distribution and installation problems in client machines (already tried it in a Mac OS machine and I didn't even know where the JRE kept it's libraries to try and do the same dirty trick).
Therefore I want to ask you guys if there is any solution to this particular problem or if anyone has a better explanation of what's going on and how I might fix it without having to recreate the whole architecture of my project (which actually works OK except for this little inconvenient).
Thanks in advance!

Write your question to the mailing list, dev#platform.netbeans.org, and you're more likely to get an answer.