We Keep Coding

Accessing external files on network directories when deployed with microservice Jar file in Spring Boot

So I have a microservice app that does image processing with ImageJ which I have created a microservice using spring boot.
Often the image I am trying to load is coming from a samba share mapped to a directory like p:/
I have an issue that is ONLY happening when I execute the spring boot app as a JAR directly. If I execute it directly from STS using the tool executors it works fine. As well, the file is readable, viewable etc.
File f = new File("P:\\Stamps\\_Temp\\Img001.jpg");
BufferedImage image = ImageIO.read(f);
This will result in
javax.imageio.IIOException: Can't read input file!
at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1308) ~[na:na]
For debugging purposes I had it print out the .exist() and .canRead() - when executed in STS (Eclipse) these both return true, however from the JAR it will return false. More over if I try to access the image directly from a local folder (say c:\my-images) it works fine. So my assumption is there is some thing restricting access to these Network shared files when accessed from within a Jar (only).
I have not been able to find any reference information via searches to this on the usage of File so I am wondering if there is a spring boot configuration that is blocking this access (mainfest setting etc), or if it is a restriction of executing class byte-code from within a JAR?

So networked Mapped Drives in Windows can be accessed if you track back to the remote name and replace that drive letter with the appropriate mapping name. This thread covers an example where they do that: https://gist.github.com/digulla/31eed31c7ead29ffc7a30aaf87131def they key here is to replace the "P:" with "\server\path"
Again does not explain why this fails via Jar access vs. class exploded access, but at least it covers a workaround. For my use I might just simply use a mapping file since while I use the Network Mapping, I do not know how common this would be for other users and asking them to set some configuration in application.properties does not seem ridiculous for those cases. Still if anyone has insights into WHY we get different behavior inside and outside the Jar execution I'd be curious (or whether there is some spring-boot property in the manifest that needs to be set)

Link to properties file outside webservice

I have a webservice that uses Java, REST, Jersey and runs on Tomcat8. The webservice requires access to a database. Depending on where we are in the process the we may be using a testdatabase, production database or something else. Ideally we would like to be able to set which database to use without requiring a code change and recompile.
The approach we have tried is to have a properties file defining the database parameters and use an environment variable to point to the file. This has proved troublesome, first we've had a hard time defining system properties on the Tomcat server that we can read from the application, also it seems like all the files will have to be defined on the classpath, i.e already configured ahead of time and part of the codebase.
This seems like fairly common scenario, so I'm sure there is a recommended way to handle situations like this?

Zack Macomber has a point here. Don't enable your app/service to look up its settings dynamically.
Make your build process dynamic instead.
Maven, Gradle and friends all provide simple ways to modify output depending on build parameters and or tasks/profiles.
In your code always link to the same file (name). The actual file will then be included based on your task and/or build environment. Test config for tests. Production config for production.
In many cases a complete recompilation is not necessary and will therefore be skipped (this depends on your tool, of course).
No code changes at all. Moreover the code will be dumb as hell as it does not need to know anything about context.
Especially when working on something with multiple people this approach provides the most stable long-term-solution. Customizable for those who need some special, local config and most important transparent for all who don't need or don't want to know about runtime environment requirements!

We have a similar case. We have created a second web service on the same endpoint (/admin) which we call to set a few configuration parameters. We also have a DB for persisting the configuration once set. To make life easier, we also created a simple UI to set these values. The user configures the values in the UI, the UI calls the /admin web service, and the /admin service sets the configuration in memory (as properties) as well as in the DB. The main web service uses the properties as dynamic configuration.
Note: we use JWT based authorization to prevent unauthorized access to /admin. But depending upon your need you can keep it unsecure, use basic HTTP auth or go with something more detailed.

Not sure if in this particular case it is wise, but it is possible indeed to create a .properties file anywhere on the filesystem - and link it into your application by means of a Resources element.
https://tomcat.apache.org/tomcat-8.0-doc/config/resources.html
The Resources element represents all the resources available to the web application. This includes classes, JAR files, HTML, JSPs and any other files that contribute to the web application. Implementations are provided to use directories, JAR files and WARs as the source of these resources and the resources implementation may be extended to provide support for files stored in other forms such as in a database or a versioned repository.
You would need a PreResources element here, linking to a folder, the contents of which will be made available to the application at /WEB-INF/classes.
<Context antiResourceLocking="false" privileged="true" docBase="${catalina.home}/webapps/myapp">
<Resources className="org.apache.catalina.webresources.StandardRoot">
<!-- external res folder (contains settings.properties) -->
<PreResources className="org.apache.catalina.webresources.DirResourceSet"
base="/home/whatever/path/config/"
webAppMount="/WEB-INF/classes" />
</Resources>
</Context>
Your application now 'sees' the files in /home/whatever/path/config/ as if they were located at /WEB-INF/classes.
Typically, the Resources element is put inside a Context element. The Context element must be put in a file located at:
$CATALINA_BASE/conf/[enginename]/[hostname]/ROOT.xml
See https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Defining_a_context

Spring load a file

I need to load a file from within a directory in the root of a WAR using Spring
This is the directory structure
rootOfWar
--static-dir
---- my-file.css
--WEB-INF
---- classes
.....
It is a normal WAR.
In a Spring #RestController I need to be able to read and write to my-file.css file. What is the best way to get the File, ServletContextResource or?
More Details
- The location of the file is out of my control I cannot move the file.
- The jee container is Tomcat.
- The Spring version is current 4.1.6
- The Spring environment is not using XML only annotations with WebApplicationInitializer, WebMvcConfigurerAdapter and an annotation configuration class.
Is there another way to do this like specify a file as a resource in the configuration so that it is loaded by the frame work and accessible within the application?
Basically I have JEE knowledge but my Spring knowledge on best practices concerning read/write are lacking.

If you need to modify a file you should not make it part of the WAR. Store it somewhere outside the web package and reference it there. Everything else will lead to problems, especially when you deploy to Websphere which is often run in a restricted environment where writes are rejected.
But I consider overwriting files in the web path bad design, because you are likely to run into caching issues. Better write a servlet that generates the CSS you need. If you would be able to name the content that should overwrite your css file, you are also able to render this dynamically.
Something like this may be already sufficient:
#RequestMapping(value = "/my.css", produces = "text/css;charset=UTF-8")
public String showCss() {
return "<here goes your css>";
}
(This is written from my memory and not tested).
The good thing is that you can modify the css any time you want and even set caching information as needed.

Global Hadoop configuration storage

Is there any way to set / get global Hadoop configuration object, something like pseudocode below? Of course I can create my own class with static methods which do what I need but its better if something like this could be found inside Hadoop Java API to not make dependencies more complex. By now I did not find anything usable. Any advice?
In some application level configurator.
Configuration conf = new Configuration();
conf.set(...);
<something>.SetGlobalConfig(conf);
In lower layer client code.
Configuration conf = <something>.GetGlobalConfig();
// ... something that needs configuration.
UPDATE 1: I know about Hadoop .xml configuration files and actually it's one of possible solutions but it's preferable to have all configuration done in code, without external files.
UPDATE 2: Based on points provided decision is to use 'usual' .xml configuration packaged together with job code. Client can 'tune' some parameters via command line parameters that keep hadoop-like semantic due to usage of the same Tool. To isolate rest of code from Hadoop configuration / user aspects even more application code requests configuration through special COnfigurator singletone.
Original question is considered solved though I don't mind against useful ideas.

When you call
Configuration conf = new Configuration();
it will look into the classpath of your project for core-default.xml and core-site.xml.
And the core-site.xml is exactly where you want to put your "global" configurations into.

Overwrite configuration for Spring project from outside

I'm developing a Spring application which shall be used by any kind of other application, no matter if that is a Spring project, a web application or even a simple single-class console application. The application who uses my project will just have to add the JAR file with my application.
So my project has a static factory class that gets and returns a bean from its Spring context which acts as an access object to access all public available functions of my project.
That part is already working.
But I need the developer of the application that uses my JAR to be able to overwrite certain configurations in my project without editing the config files in the JAR itself. At the moment those settings should be overwritable:
- the data source and hibernate bean configuration
- the jasypt (encryption) bean configuration
- the log4j settings
How do I make those settings overwriteable with configs from outside the jar?
Greetings
touchdown

Maybe a good solution would be a configuration that the user could override, for this take a look into:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java
Specially to #Configuration and #Bean
Maybe you could have a configuration class implemented and the user can override it. After extending the class and overwrite some methods that provides some beans the user shall inform it to your factory that will do nothing else than
new AnnotationConfigApplicationContext(userConfigurationClass);

If you want to replace the complete configuration, than the easyest way would be to have a parametrized factory that takes an alternative configuration file as its argument.
If you need it a bit more fine grain (lets say up to 10 parts), than you can split your application xml in several smaller once, and use again a configurable factory that allows to exchange the smaller xml files.

So I got a solution that is working for me.
I put an general import for override context-XMLs at the bottom of my main application context:
<import resource="classpath*:project/package/config/override/or-*.xml" />
So all the user has to do is to create the package "project/package/config/override" in his classpath (e.g. resource folder) and place matching XML files in it with new bean definitions.