Read the files in the war package and solve the outofmemoryerror in ant usage.

I. Reading files in the war package

During the development of J2EE Web applications, directory deployment is usually used in the development phase, while web applications are often packaged as a single. War file during formal operation for convenient deployment. That is, in your application directory (for example, WebLogic ultwebapp of Weblogic), execute the following command:

1. Jar CF0 mywebapp. War **

In this way, it is very convenient to deploy the file to the official system. You only need to copy the. War file to the WebLogic applications directory or Tomcat webapps directory to automatically deploy the file. Tomcat automatically monitors and unpacks the deployed. War application package, so the following issues will not occur. WebLogic does not automatically unpack. war, so if your application needs to read the configuration file or other resource files in the original application, it will find that the program runs normally during unpacking and deployment, during WebLogic packaging and deployment, an error occurred while running, and the file cannot be found. For example, the following application:
[Pre] | -- defaultwebapp
| -- Index. jsp
| --... JSP
| -- WEB-INF
| -- Web. xml
| -- Log4j. Properties
| -- Classes
... [/PRE]
The log4j configuration file log4j. propertes is stored in the defaultwebapp/WEB-INF directory. Log4j initializes through an automatically loaded servlet. The initialization code is as follows:

1. Servletcontext context = getservletcontext ();
2. Org. Apache. log4j. propertyconfigurator. Configure (context. getrealpath ("/") +
3. "/WEB-INF/log4j. properties ");

The context. getrealpath ("/") to get the real root directory of the current web application. For example, if your WebLogic is installed in D:/BEA, in Windows context. getrealpath ("/") usually returns:
D:/BEA/wlserver6.1/config/mydomain/applications/defaultwebapp
In Unix:
/BEA/wlserver6.1/config/mydomain/applications/defaultwebapp
In this way, after splicing with "/WEB-INF/log4j. properties", we get the real path of the log4j. properties file. log4j reads this configuration file through file IO and completes initialization.
Now everything is normal! After the test is passed, all the files under defaultwebapp are combined into one. when deploying the war package, the system reports cannot find "D:/BEA/wlserver6.1/null/WEB-INF/log4j. properties file! If your application needs to read other files that have been packaged into the war package, it will report that the files cannot be found. In addition, the system does not search in the D:/BEA/wlserver6.1/config/mydomain/applications/defaultwebapp directory, but in the D:/BEA/wlserver6.1/null directory. This is because context. getrealpath ("/") returns NULL. View the API documentation of servletcontext,

Public String getrealpath (string path)
......
The real path returned will be in a form appropriate to the computer and operating system on

Which the servlet container is running, including the proper path separators. This method

Returns NULL if the servlet container cannot translate the virtual path to a real path for any

Reason(Such as when the content is being made available from A. War archive).

Originally, for a packaged application, there is no concept of realpath. Calling getrealpath will simply return null. In fact, it is easy to understand that a file is packaged. war file, there is no directory structure (although the directory structure still exists in the package, this is not the same as the directory structure in the file system ). Therefore, resources in the war package cannot obtain the realpath. In this way, the file IO cannot be read. So how do I read Resources in the war package? The answer is to use the servletcontext. getresourceasstream (string) method.
There are several configuration methods for org. Apache. log4j. propertyconfigurator:

1. Static VoidConfigure (properties Properties );
2. Static VoidConfigure (StringConfigfilename );
3. Static VoidConfigure (URL configurl );

Since the log4j configuration file in the war package cannot be obtained now, you can read the inputstream and construct a properties. The configuration can also be completed through the configure (properties Properties) method. The sample code is as follows:

1. Inputstream is = getservletcontext ().
2. Getresourceasstream ("/WEB-INF/log4j. properties ");
3. Properties props =NewProperties ();
4. Try{
5. Props. Load (is );
6. }Catch(Ioexception e ){
7. System. Err. println ("load log4j configuration failed ");
8. }
9. Propertyconfigurator. Configure (props );

Now, the war application can run successfully. But if you do not deploy the application through war, will the application be deployed directly through the directory structure fail to find the resource again? Please refer to the API documentation of servletcontext. getresourceasstream,

Returns a URL to the resource that is mapped to a specified path. The path must begin

A "/" and is interpreted as relative to the current context root.
This method allows the servlet container to make a resource available to servlets from any

Source.Resources can be located on a local or remote file system, in a database, or in

A. War file. 

You can use getresourceasstream to obtain resources, including local file systems, remote file systems, and war packages. The above issues will not occur.

Conclusion: when developing J2EE Web applications, if you need to read files in this application, use servletcontext. getresourceasstream instead of file I/O.

Ii. Solution to outofmemoryerror in ant usage

When developing large projects, there are usually thousands of class files, and some make tools are required to assist in development. Sometimes there are too many classes to be compiled. When ant is used for compilation, an outofmemoryerror occurs, which interrupts the compilation process. In this case, partial files are removed and compiled in batches. However, it is difficult to determine which files should be removed first and which files should be removed after automatic dependency compilation in Java compilation. Is there a simple way? Yes!
Go to your ant installation directory, find ant. bat in the bin subdirectory, open it in the text editor, modify the allowed command at runant, and add the following parameters:

: Runant
"% _ Javacmd %"-xms128m-xmx512m-classpath ......

If you have installed Jike and use the Jike compiler, You need to modify the Run Command at runantwithjikes, as shown in the preceding figure.

Conclusion: by default, the Java Virtual Machine allocates 64 MB of memory. If your application is large and exceeds 64 MB of memory, the Java Virtual Machine will throw an outofmemoryerror and stop running. No matter what application (web application, application, etc.), you only need to modify the running Java command on your machine and add-XMS (minimum memory usage) to the Java XXX command) and-xmx (maximum memory usage. Of course, the memory capacity here refers to the physical memory and cannot exceed the total physical memory capacity of your machine.