Dom4j reads xml files from the jar package

During encapsulation, we often need to use xml to define some specifications. Of course, there will be no problem when reading data separately, but these xml files are often placed in the jar package, these things cannot be found. The xml used in this document is defined as follows:

 
 
  
   
    00045050
   
   
    0
   
   
    MOISES MORENO
   
   
    
     T1
    
    
     T2
    
    
     T3
    
    
     T4
    
    
     T5
    
    
     T6
    
    
     T7
    
   
  
 
 
  
   
    00045051
   
   
    0
   
   
    RUTH PENA
   
   
    
     S1
    
    
     S2
    
    
     S3
    
    
     S4
    
    
     S5
    
    
     S6
    
    
     S7
    
   
  
 

Let's look at the code below:

public void read(){    try {    Document doc = new SAXReader().read(new File("src/user.xml"));List
 
   itemList =  doc.selectNodes("/ACCESOS/item/SOCIO");for (Iterator
  
    iter = itemList.iterator(); iter.hasNext();){Element element = iter.next();System.out.println("NUMERO =" + element.elementText("NUMERO"));}} catch (DocumentException e) {e.printStackTrace();}}
  
 

This code is written in Java Project, where user. xml is placed in the src root directory, and the class is under src/com/jianxin/xml. It is clear that the above Code can be run, but if you package the above Code, the directory in this jar package is

Com/jianxin/xml

User. xml

In this method, go to src to find user. xml. Even if src/is removed from the path, the user. xml in jar cannot be located.

This is mainly because the jar package is a separate file rather than a folder and cannot pass "file:/d :... /user. xml "to locate the file, so even the relative path cannot be located in the jar file.

If we break xml into the jar package, no matter which directory the user. xml is located, the classes in the jar package can be found. Is this an illusion?

Of course not. We can use ClassLoader:

1) ClassLoader is an abstract class of the class loader. It dynamically obtains the running information of the loaded class during runtime. In this case, when we call the ReadXML class in xml. jar, the JVM loads it into the ReadXML class and records the ReadXML runtime information (including the root path of the jar package ). The methods in the ClassLoader class can help us dynamically obtain the information:

A. public URL getResource (String): searches for resources with a given name.

B. public InputStream getResourceAsStream (String name), return the specified resource input stream

2) ClassLoader is abstract and cannot be instantiated. When writing code, we use the getResource and getResourceAsStream methods in the Class. These two methods will delegate the getResource and getResourceAsStream methods in the ClassLoader. Rewrite the above method:

public void read(){try {    InputStream is=this.getClass().getResourceAsStream("/user.xml");    Document doc = new SAXReader().read(is);List
 
   itemList =  doc.selectNodes("/ACCESOS/item/SOCIO");for (Iterator
  
    iter = itemList.iterator(); iter.hasNext();){Element element = iter.next();System.out.println("NUMERO =" + element.elementText("NUMERO"));}} catch (DocumentException e) {e.printStackTrace();}}
  
 

In this way, it is okay to run the package before packaging. After packaging, you can still find the data after running the package ~.

Here, I feel that the most important thing is to get the Class and get the jar root directory information, and the ClassLoader will also change. Pay attention to this. What is the change, at present, I just encountered this problem. So I plan to read a relatively low-level book in Java to make myself more comfortable when encapsulating things for others, and stay at the application level. It is also time to get a better understanding of JVM.

Most of the time is being developed recently. It may be later to say that jira is better. During the process, we used dwr to describe it in the next article ~~~