Java EE EAR - Shared Location of Read / Write Resources in a Cluster Environment

In Java EE (happens to be WAS 6.1, but can be any application server) I need to put an XML file, which is a configuration file, so that I can read and write to it.

This should be available in a clustered environment, so I am considering using a class path to upload a file.

I think I can store this file in the root of the EAR, reference it in the manifest, and then load and save it.

I tried this approach by installing my file in the JAR and making it accessible via MANIFES, and I can load the configuration file from the class path without problems using the following.

this.getClass().getClassLoader().getResourceAsStream("configFileName"); 

This uploads a file that is in a JAR, which is fantastic. But if I want to edit this file programmatically, I can’t access the JAR file (the root of the EAR), it returns me the interpreted path as follows:

  /usr/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/localhostNode01Cell/MyApp.ear/MyApp.war/TB_config.jar 

This is the wrong JAR location, the correct location is in MyApp.ear.

So the question is: how can I access and update (copy content, create new, save, delete old) JAR with my configuration file. Or should I put the configuration file in another place?

What is the standard Java EE for creating files that require read / write access, available for WAR in a cluster?

+4
source share
4 answers

Ok, I built a solution for this. It is more based on WebSphere (our platform), but it is J2EE, and I am surprised that it was not mentioned. I mainly used JMX to synchronize nodes. Files are stored and saved in the deployment manager, then the nodes are then re-synchronized using JMX calls, and then the application engines are restarted by calling servlets in the applications.

This is a dream

So, @stacker manages the nodes and the manager distributes the files among the nodes.

+2
source

The problem you are facing is not unique. Many Java EE programmers may struggle to provide a “custom” property file with cluster administrators. And the solution you have chosen has its limitations.

The problem with embedding the configuration file inside the JAR is the absolute path or the physical path to the file if you need to update it. If your container will not explode your EAR and WAR files, placing the configuration file next to the code is a bad idea - the administrator will have to deploy a newer version of EAR / WAR / JAR. That is, unless, of course, you can configure the container to explode artifacts - the WebLogic server does this, I'm not sure about WAS.

There are several ways to solve this problem:

  • Save the configuration file to the SAN, accessible to all nodes in the cluster via the "canonical" path. Thus, you can find the file from any node in the cluster and update it. Remind yourself to restrict access to this directory. Although this sounds simple, it’s not necessary - Java objects can be “reset” by nodes after updating the configuration file. In addition, you may need a script in which property files can be edited outside the application.
  • Use a database. It is much simpler and almost without problems, except that Java objects may have to be cleaned up again.
  • Use an MBean. Like the database, except that I did not know that many people vouch for MBean support in WAS. Also, I'm not sure if in this case the state objects can move through the cluster.
+2
source

You cannot write to the ear file, you must put the XML file in the database as a text lob (large object).

+1
source

In fact, since I'm using WebSphere, it looks like I can use the dynamic cache provided by the WebSphere deployment manager. The final chapter in the link below discusses the use of a dynamic cache that provides a shared object in a cluster. The configuration file is XML, which is parsed as the engine (in the Document object) of the application, as well as a Java object, so it can be placed in DistributedMap.

Looks like a clean solution. Thanks to everyone for reading and your answers.

http://www.ibm.com/developerworks/websphere/library/techarticles/0606_zhou/0606_zhou.html

0
source

Source: https://habr.com/ru/post/1316182/


All Articles