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.

Create Project Java Web without maven and Ide

I am trying to create an application for creating java web projects in a personalized, automated way, without maven, without IDE, but so far I have not seen anything on the internet that would suit me. Could someone guide me or tell me how I can do it?

I consider your question differently that you want to create an application which when run can automatically create web projects !! If that is correct you need to write set of programs which would make files necessary for your web project like generate java files, Jsp files, XML, properties etc depending on complexity of your web projects, also if customized with parameters it can make different kinds of projects. Then you will need to make war file which is going to be the final deploy-able component with these files. This is all that you would do manually through IDE and maven would be the jar files you would need if any. Let me know if you need any more help.
Please accept and like if you appreciate my gesture to help with my ideas n experience.

What are the criteria(in the programming point of view) that one should keep in mind while creating a java jar(as library) file for android

I know how to create a jar file using Eclipse.
I was trying to create a share library so that I can avoid redundant source code. I have figured out that a jar should be :-
independent
should not make call to external class attributes(properties)/methods except the standard library imports.
The resources should be given as a parameter to jar file to perform a action.
Should work as a independent entity.
I tried to well organised my code in different packages also added MANIFEST.MF file.
This is first time I'm trying for data abstraction.
I would like to request suggestions/instructions as per the programmer point of view, what are the criteria that jar code should have ?
Is it good idea that my jar is or depend on another jar (viz java mail api jar) ?
Thanks in advance.

As you've tagged this with Android, I assume that Android is the intended use case.
The easiest way to share your code between several projects is probably to create a library project, this way you can keep the source code at hand too (less convenient to attach source to the jar every time you use it).

A "Resource bundle" for persisting other then localization data

I need system similar to ResourceBundles except that I will not use it for localization. Basically, I need to store several versions of settings. One version of that settings is String-to-String map, that can be represented by Properties file. These settings versions must be easily persisted to file system inside application .jar (alike PropertyResourceBundle).
The idea is to have different versions of application settings (settings profiles), represented by key-value pairs of type string, that can be chosen from at application start up based of user decision. Again these are not language versions so ResourceBundle (according to its javadoc) is not the right way to implement it.
Any easy way how to do that without implementing the whole think myself? Please do not suggest third-party it should only use Java SE classes.
Edit: I forgot to mention one important detail. It would be hard for me to get stream like this: Thread.currentThread().getContextClassLoader().getResourceAsStream("/your/resource/here");. That is because the project that would contain properties file is compiled by Ant and used as a dynamically loaded library in different GUI projects that actually run. I might have all properties files in fixed project folder but since Thread.currentThread().getContextClassLoader() returns context of GUI project and I do not know where in that project was the .jar with property file placed by Ant I do not know what to use as "/your/resource/here".

I might have misunderstood the question however seems to me you can easily do something like this:
InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("/your/resource/here");
Properties prop = new Properties();
prop.load(inputStream);
This will be safe in a Java EE environment as well and you can call you anytime you need if you want settings to change.
Update: as long as the resource is on the classpath you should be able to find it without knowing the full path of the resource as well.

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.