How to access a file from another war, which is in one ear on a Java EE server (JBoss)?

Question

So, the following problem: We have a load balancer with n servers behind it. Each server has a PDF (war) project installed in the ear along with the pdf-builder project in the same earfile (different war). Now I want to read a pdf file from another war.

The problem is this: I do not know the IP address of the server on which I am running, and using the dns search, I can shut down on another server via loadbalancer. In addition, there may be problems with access / security restrictions, since the server itself is not a valid user who has rights to access PDF files of war project files in pdf format.

Is there a way to get something like getResourceAsStream () that works in different modules / military files in the ear?

Answer 1

You can move .PDF to a separate jar (i.e. pdf-builder.jar) and put it in .EAR In your .WAR manifest ( META-INF/MANIFEST.MF ) put this line:

 Class-Path: pdf-builder.jar 

Now you can load .PDF with your class loader. It is compatible with J2EE.

Answer 2

You need to provide an absolute path to the file in order to access a resource that is not in the current class path.

you can call

 serverletContext.getRealpath("/"); 

indicating the path to the node server (context). From there you can go to the file.

Another way: Jboss uses (or sets) several environment variables at boot time. You can use these properties to get the current node (for example, 'default'). After two properties, you will get the absolute path to the current node server.

 System.getProperty("jboss.server.base.dir") + File.separator + System.getProperty("jboss.server.name") ; 

code> (Please use System.getenv('varname') if getProperty does not work). From there you can move around. Here is a complete list of system variables that jboss uses.

Answer 3

Wars are designed to be isolated from each other. They can see “up” in the application class loader (EAR level), but cannot access the peer class loader. Therefore, although there may be a way to make it work on your specific application server, doing this is not recommended. If someone in the group of operations changes the deployment parameters in a row, they may not know that you are relying on this mechanism and would break the application in a (possibly) mysterious form.

Attempting to access the peer class loader is similar to violating Java EE (if not the letter of the specification, at least in its spirit).

If you cannot put static content on a separate server for access, at least put static PDF files in a JAR (as suggested by others) and deploy it in an EAR. When you do this, be sure to add the JAR entry to the WAR declaration manifest file (otherwise it will not load the JAR into the application class loader).

Answer 4

• Change .war to .jar ( .ear ?) If deployment is not too frequent. For example, in the lib server directory if you do a daily restart.

• Do not deploy a war, but upload files to a fixed directory, i.e. using rsync . This is my preference.

• Do as @ Rp-, possibly unzip.

Answer 5

I know that I do not have enough experience to answer such a question, so that everything I can imagine in a very, very rough sketch sets each .war as a different Spring context, and then dynamically loads its aproropiate mapping job in Springs MVC Framework

Dynamic loading of Spring Contexts at runtime

Download Spring Resources as Dependent Banks

Web Resources - Chapter 9 - Spring Link