We Keep Coding

Using Java to modify AWS file?

I would like to build a centOS 7 instance on AWS and install Apache to build web server.
After that, I would like to modify the config file, /etc/hosts and /etc/httpd/conf.d/test.conf where test.conf is created by me.
Can I use java to modify the file directly? Or I should create the file and replace the old file on instance? I am little bit confused for the feasibility. Please someone help.

There seem to be a few questions here, so I've split them out.
Q: Can I use programming language X to modify a file on the local filesystem?
A: Yes, with very few exceptions. For Java, yes (if the instance has a JRE).
Q: Should I use Java?
A: Probably not the first choice (you could probably do what you need in a shell script at launch).
Q: Should I create the Apache config files dynamically or build them into an AMI?
A: Difficult to answer without more information. There are pros and cons to AMIs. If it's simple and quick to create/modify the files on launch, then I'd do it that way.
DevOps is a big subject and there are many options available to you for bootstrapping EC2 instances. Pre-baked AMIs is one option. Another simple option that you might consider is to write userdata scripts, that run at launch time, and that set up the instance for you (see simple nginx example). They can install software, modify config files, start services, and other things. They can also pull collateral such as pre-staged config files from S3, which can be a handy option.

Is there a way we can make the Java Language Server to skip checking `node_modules` files while starting up in VSCode?

Since I am having a couple of angular projects within the same workspace along with Spring Projects, the Java Language Server that runs for providing Java support to VSCode takes an enormous time (~10 mins) to run through all the contents of the workspace which includes node_modules.
Is there a way/setting that I can use to tell it to skip certain folders/files so that I can speed up the initialization of the Java Language Server? Especially contents of node_modules?

As of v0.66.0 of the extension, there is the java.project.resourceFilters setting. As it defaults to ["node_modules",".git"], your problem should be solved by using a current version of the redhat.java extension.
If you'd like to exclude more folders, you can add them in your settings.json.
#1460 is the matching issue for this question.
--
But: this does not work for me atm. See #1655, my setting seems to be ignored, I'll try to resolve this with the devs and update this answer accordingly.

Real path to a virtual directory

I setup a mapping to my images directory in Weblogic.xml by using the virtual-directory-mapping tag. How can I read the value of the real path so that my application can access that virtual directory for write access?
JMX seems to be of no help here since the WebServerMBean (or any other MBean) doesn't seem to provide access to the virtual-directory-mapping property.
Java Servlet API also has not yielded result since calling getRealPath() is only appending the url-pattern to the deployment directory of the application and not giving the correct path.
<virtual-directory-mapping>
<local-path>/home/wlsadm/images</local-path>
<url-pattern>help/specimens/*</url-pattern>
<url-pattern>*.xml</url-pattern>
</virtual-directory-mapping>

I've done a fair amount of research on this, reading vendor documentation, reading blogs, forums, etc. As the OP indicated, JMX use to be an approach to get this information, but this is no longer an option in current Weblogic versions.
The only solution I think you're left with is to create a utility that reads the information from the weblogic.xml file on the classpath. Something like an application listener that reads it on application startup and makes it available as a servlet attribute, etc.
Would love to hear how you solved it, though.

Where to store preferences in a Java application?

I need just a solution to retrieve a path for storing desktop application settings (e.g. a sqlite database) that meets following needs:
cross platform
works from jar and from "normal" invocation
I've spent a lot of time googling and experimenting with getting the codebase path via X.class.getProtectionDomain().getCodeSource().getLocation() and java.util.pref.Preferences
class, but return values gave sometimes different results, returned null or just "/" as path.
"Cross Platform" is kind of hard to define. A solution called "best practice for each platform" won't be easy to achieve. Making a difference between user-specific and shared data would be sensible.

java.util.prefs.Preferences is the proper way to do it. It works perfectly fine (I've used it in a desktop application without any problems). It is cross-platform and is available without any extra jars. It also differentiates between user-specific and global data. Perhaps shed some light on your particular problems with it (or ask another question)
Of course, you can use java.util.Properties as well, and store files in System.getProperty("user.dir").

System.getProperty("user.dir") returns a path to the user directory for most modern systems.

Where/how to store persistent data with tomcat?

Where should I store persistent files in a Tomcat web app ?
javax.servlet.context.tempdir is not feasible, it's erased when the app is redeployed/removed
Don't want to use an absolute path in e.g. servlet init parameters
Storing the files in a database is not an option

Our team does this a lot. A general rule we follow is outside the web app and outside Tomcat.
Our sysadmin set up a directory on our server that the tomcat user has rw permissions to (e.g. /var/tomcat/persist). We have a built a directory structure under this that tomcat uses to store files, read app-specific init files, etc.
If you don't want to use an absolute path in your init-params for your servlet, consider setting a system property when tomcat is started up. The good thing about that is every application running under tomcat will have access to it. The bad thing about that is every application running under tomcat will have access to it. You could set a property named base.persist.dir and build subdirectories for each application underneath it. We set system properties in the setenv.sh script in the bin/ directory under the CATALINA_OPTS environment variable.

Answering the title of the question, what about using a database, a DataSource and JDNI? Even in a web only context, writing to files using java.io is not really recommended because of concurrency, threading, security, clustering, portability issues. Some of these problems can be "workarounded" but still, this is not really a best practice. The standard approach is to use a database and I'd suggest to reconsider this option, throwing "file-based" lightweight database like HSQLBD or JavaDB into the mix.
(EDIT: For an unknown reason, database is not an option. Using JNDI or context parameters or init parameters to pass an absolute path - which are the less worse options IMHO - is excluded too. For a relative path, maybe look at user.home or user.dir then - or any other system property that you could pass on the command line. I don't like it, I wouldn't do it, and this doesn't solve the issues previously mentioned, but it's your choice after all.)

Storing the files in a webapp directory under the home directory of the user running Tomcat is a good and convenient option. It is outside of Tomcat, which means it will survive redeployment, and it is usually a writable directory (because it is created under the users' home dir).
But it is always a good idea to allow overriding the location of such directory via system property.

Generally, this would go to the database. But since the OP insists on not using a database, I'd try a different approach:
Filesystem path which is known: ${user.home}/.myapp. Applications sometimes use this for e.g. search indices which can be recalculated based on data in the database. Might be okay for your use case to use the user's home.
Store the configurable filesystem path in a configuration repository such as the database or perhaps Java Preferences (if you don't like to use servlet init params). Commercial applications such as Atlassian JIRA use a configurable (but absolute) filesystem path where they store issue attachments. If they don't know a better way, i don't know who does :)

I generally would suggest to use a database to store persistent data and expose it via a DataSource.
If you don't want to do that, I guess you could consider using the "user.home" system property (I have seen this used in a few circumstances). But... there are no guarantees that your servlet will be run with permission to write access unless you configure that yourself.