J2EE project development experience

J2EE project development experience

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:

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:

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

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. Here is a simple method for you: Go to your ant installation directory and find ant in the bin subdirectory. bat, 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.

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

This way, and "/WEB-INF/log4j. properties"

After splicing, the real path of the log4j. properties file is obtained. log4j reads the configuration file through file IO to complete 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.

Check the API documentation of servletcontext. Originally, for a packaged application, there is no realpath concept. Calling getrealpath will only 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:

Static void configure (properties Properties); static void configure (string configfilename); static void configure (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:

Inputstream is = getservletcontext (). getresourceasstream ("/WEB-INF/log4j. properties "); properties props = new properties (); try {props. load (is);} catch (ioexception e) {system. err. println ("load log4j configuration failed");} 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 with a "/" and is interpretedas relative to the current context root. this method allows the servlet container to make a resource available to servletsfrom any source. resources can be located on a local or remote file system, in a database, or in. 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.