13周JAVAWEB考试重点_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
喜欢此文档的还喜欢
13周JAVAWEB考试重点
河​工​大3​周​J​A​V​A​W​E​B​考​试​重​点
阅读已结束，如果下载本文需要使用
想免费下载本文？
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
你可能喜欢后使用快捷导航没有帐号？
只需一步，快速开始
查看: 1072|回复: 2
UID91551帖子阅读权限20精华贴数技术排名143 专家积分54 社区排名1532 技术积分14127 社区积分1266 注册时间
精华贴数专家积分54 技术积分14127 社区积分1266 注册时间
论坛徽章:18
& & 在SSH框假中spring充当了管理容器的角色。我们都知道Hibernate用来做持久层，因为它将JDBC做了一个良好的封装，程序员在与数据库进行交互时可以不用书写大量的SQL语句。Struts是用来做应用层的，他它负责调用业务逻辑serivce层。所以SSH框架的流程大致是：Jsp页面----Struts------Service（业务逻辑处理类）---Hibernate（左到右）
&&struts负责控制Service（业务逻辑处理类），从而控制了Service的生命周期，这样层与层之间的依赖很强，属于耦合。这时，使用spring框架就起到了控制Action对象（Strus中的）和Service类的作用，两者之间的关系就松散了，Spring的Ioc机制（控制反转和依赖注入）正是用在此处。
& &&&Spring的Ioc（控制反转和依赖注入）
& &&&控制反转：就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直接操控&&
& &&&依赖注入：组件之间的依赖关系由容器在运行期决定 ，由容器动态的将某种依赖关系注入到组件之中 。
& &从上面我们不难看出：从头到尾Action仅仅是充当了Service的控制工具，这些具体的业务方法是怎样实现的，他根本就不会管，也不会问，他只要知道这些业务实现类所提供的方法接口就可以了。而在以往单独使用Struts框架的时候，所有的业务方法类的生命周期，甚至是一些业务流程都是由Action来控制的。层与层之间耦合性太紧密了，既降低了数据访问的效率又使业务逻辑看起来很复杂，代码量也很多。，Spring容器控制所有Action对象和业务逻辑类的生命周期，由于上层不再控制下层的生命周期，层与层之间实现了完全脱耦，使程序运行起来效率更高，维护起来也方便。
&&使用Spring的第二个好处（AOP应用）：
& & 事务的处理：
& &在以往的JDBCTemplate中事务提交成功，异常处理都是通过Try/Catch 来完成，而在Spring中。Spring容器集成了TransactionTemplate，她封装了所有对事务处理的功能，包括异常时事务回滚，操作成功时数据提交等复杂业务功能。这都是由Spring容器来管理，大大减少了程序员的代码量，也对事务有了很好的管理控制。Hibernate中也有对事务的管理，hibernate中事务管理是通过SessionFactory创建和维护Session来完成。而Spring对SessionFactory配置也进行了整合，不需要在通过hibernate.cfg.xml来对SessionaFactory进行设定。这样的话就可以很好的利用Sping对事务管理强大功能。避免了每次对数据操作都要现获得Session实例来启动事务/提交/回滚事务还有繁琐的Try/Catch操作。这些也就是Spring中的AOP（面向切面编程）机制很好的应用。一方面使开发业务逻辑更清晰、专业分工更加容易进行。另一方面就是应用Spirng&&AOP隔离降低了程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
使用Spring有什么好处 21:36:36 来源：WEB开发网 (0)& &
核心提示：Spring Framework(简称Spring)是根据Rod Johnson著名的《Expert One-on-One J2EE Design and Development》而开发的J2EE应用程序框架。
1.什么是Spring Framework？
　　Spring Framework(简称Spring)是根据Rod Johnson著名的《Expert One-on-One J2EE Design and Development》而开发的J2EE应用程序框架。目前主要根据Rod Johnson和Juergen Hoeller而进行开发的，目前发布的最新版为1.1.4。 Spring是J2EE应用程序框架，不过，更严格地讲它是针对Bean的生命周期进行管理的轻量级容器(Lightweight container)，可以单独利用Spring构筑应用程序，也可以和Struts，Webwork，Tapestry等众多Web应用程序框架组合使用，并且可以与Swing等桌面应用程序API组合。所以Spring并不仅仅只能应用在J2EE中，也可以应用在桌面应用及小应用程序中。针对Spring开发的组件不需要任何外部库。
2.使用Spring有什么好处？
(1)Spring能有效地组织你的中间层对象。
(2)Spring能消除在许多工程中常见的对Singleton的过多使用。
(3)Spring能消除各种各样自定义格式的属性文件的需要，使配置信息一元化。
(4)Spring能够帮助我们真正意义上实现针对接口编程。
(5)在Spring应用中的大多数业务对象没有依赖于Spring。
(6)使用Spring构建的应用程序易于单元测试。
(7)Spring支持JDBC和O/R Mapping产品(Hibernate)
(8)MVC Web框架，提供一种清晰，无侵略性的MVC实现方式。
(9)JNDI抽象层，便于改变实现细节，可以方便地在远程服务和本地服务间切换。
(10)简化访问数据库时的例外处理。
(11)Spring能使用AOP提供声明性事务管理，可以不直接操作JTA也能够对事务进行管理。
(12)提供了JavaMail或其他邮件系统的支持。
3.什么是轻量(Lightweight)级容器？
Spring的开发者可以避免使用重量级容器开发EJB时的缺点：
(1)带有侵略性的API。(代码依赖于EJB)
(2)对容器的依赖。(代码不能在EJB容器之外工作)
(3)提供固定的一组机能，不具有配置能力。
(4)不同的产品，部署过程不同，不易通用。
(5)启动时间长。
　　针对以上问题，Spring采用了IoC使代码对Spring的依赖减少，根据Web应用，小应用程序，桌面应用程的不同，对容器的依赖程度也不同。Spring将管理的Bean作为POJO(Plain Old Java Object)进行控制，通过AOP Interceptor能够增加其它的功能。
除了Spring以外的轻量级容器还有PicoContainer，(不是轻量级容器)对Bean的生命周期进行管理的还有Apache Avalon Project的Avalon等。
　　总结：Spring的核心思想便是IoC和AOP，Spring本身是一个轻量级容器，和EJB容器不同，Spring的组件就是普通的Java Bean，这使得单元测试可以不再依赖容器，编写更加容易。Spring负责管理所有的Java Bean组件，同样支持声明式的事务管理。我们只需要编写好Java Bean组件，然后将它们&装配&起来就可以了，组件的初始化和管理均由Spring完成，只需在配置文件中声明即可。这种方式最大的优点是各组件的耦合极为松散，并且无需我们自己实现Singleton模式。
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp
UID91551帖子阅读权限20精华贴数技术排名143 专家积分54 社区排名1532 技术积分14127 社区积分1266 注册时间
精华贴数专家积分54 技术积分14127 社区积分1266 注册时间
论坛徽章:18
虽然说没有系统的学习过Spring MVC框架, 但是工作这么长时间, 基本上在WEB层使用的都是Spring MVC, 自己觉得Struts2也是一个不错的WEB层框架, 这两种框架至今自己还未有比较, 今天闲着没事干, 从网上找了一些资料, 再加上平时使用Spring MVC的感触来总结一下。
Spring MVC PK Struts2
我们用struts2时采用的传统的配置文件的方式，并没有使用传说中的0配置。spring3 mvc可以认为已经100%零配置了（除了配置spring mvc-servlet.xml外）。
Spring MVC和Struts2的区别：
1. 机制：spring mvc的入口是servlet，而struts2是filter（这里要指出，filter和servlet是不同的。以前认为filter是servlet的一种特殊），这样就导致了二者的机制不同，这里就牵涉到servlet和filter的区别了。
2. 性能：spring会稍微比struts快。spring mvc是基于方法的设计，而sturts是基于类，每次发一次请求都会实例一个action，每个action都会被注入属性，而spring基于方法，粒度更细，但要小心把握像在servlet控制数据一样。spring3 mvc是方法级别的拦截，拦截到方法后根据参数上的注解，把request数据注入进去，在spring3 mvc中，一个方法对应一个request上下文。而struts2框架是类级别的拦截，每次来了请求就创建一个Action，然后调用setter getter方法把request中的数据注入；struts2实际上是通过setter getter方法与request打交道的；struts2中，一个Action对象对应一个request上下文。
3. 参数传递：struts是在接受参数的时候，可以用属性来接受参数，这就说明参数是让多个方法共享的。
4. 设计思想上：struts更加符合oop的编程思想， spring就比较谨慎，在servlet上扩展。
5. intercepter的实现机制：struts有以自己的interceptor机制，spring mvc用的是独立的AOP方式。这样导致struts的配置文件量还是比spring mvc大，虽然struts的配置能继承，所以我觉得论使用上来讲，spring mvc使用更加简洁，开发效率Spring MVC确实比struts2高。spring mvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应，所以说从架构本身上spring3 mvc就容易实现restful url。struts2是类级别的拦截，一个类对应一个request上下文；实现restful url要费劲，因为struts2 action的一个方法可以对应一个url；而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。spring3 mvc的方法之间基本上独立的，独享request response数据，请求数据通过参数获取，处理结果通过ModelMap交回给框架方法之间不共享变量，而struts2搞的就比较乱，虽然方法之间也是独立的，但其所有Action变量是共享的，这不会影响程序运行，却给我们编码，读程序时带来麻烦。
6. 另外，spring3 mvc的验证也是一个亮点，支持JSR303，处理ajax的请求更是方便，只需一个注解@ResponseBody ，然后直接返回响应文本即可。送上一段代码：
@RequestMapping(value=&/whitelists&)
public String index(ModelMap map) {
Account account = accountManager.getByDigitId(SecurityContextHolder.get().getDigitId());
List&Group& groupList = groupManager.findAllGroup(account.getId());
map.put(&account&, account);
map.put(&groupList&, groupList);
return &/group/group-index&;
// @ResponseBody ajax响应，处理Ajax请求也很方便
@RequestMapping(value=&/whitelist/{whiteListId}/del&)
@ResponseBody
public String delete(@PathVariable Integer whiteListId) {
whiteListManager.deleteWhiteList(whiteListId);
return &success&;
UID71047帖子阅读权限100精华贴数技术排名1 专家积分837 社区排名4 技术积分260193 社区积分121666 注册时间
天王盖地虎
精华贴数专家积分837 技术积分260193 社区积分121666 注册时间
论坛徽章:335
OLD啊！老技术
-----孰能浊以静之徐清&&孰能安以动之徐生-----&&
－－－－－－－－－－－－－－－－
Karaf+Aries+blueprint 研究中...
Open Stack/Docker 研究中...
OpenDayLight/NFV 研究中...
OPENCL + Spark+ Hadoop 研究中...
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：　广播电视节目制作经营许可证：编号（京）字第1149号关于java和web项目中的相对路径问题 - yethyeth的专栏
- 博客频道 - CSDN.NET
11065人阅读
http://blog.csdn.net/swlxm/archive//1587185.aspx
在JSP的HTML部分中的相对路径
在JSP的JAVA部分中的相对路径&
在FORM的ACTION属性中的Servlet引用&
在Servlet中forward到另一JSP文件
对 于第一种情况，可以在HEAD中定义BASE标签，指定改页面的基准路径，一旦定义后，改页面中的相对路径都是基于改基准路径的，如BASE中定义 HREF=&http://localhost:8080/XXHP/&，那么如果A中定义HREF=&welcome.jsp&，就相当于HREF= &http://localhost:8080/XXHP/welcome.jsp&。
对于第二种情况，由于需要得到服务器端 的路径，BASE标签就无法满足需要了。在JSP中预定义了application对象，通过它可以得到Web应用在服务器端的根目录： application.getRealPath(&&)，返回的是&F:/jakarta-tomcat-5.0.28/webapps/XXHP（最 后没有/），既然如此，只要在根目录的基础上加上文件的相对路径就可以了：new File(application.getRealPath(&&) + &//xxx.xml&)。
对于第二种情况，可以在&servlet-mapping&中设置。&url-pattern&中的&/&代表Web应用的跟目录&http://localhost:8080/XXHP&（最后没有&/&）。比如有个JSP文件：， 其中的action属性指定为&MyServlet&（&servlet-name&），当提交表单时，服务器先匹配&servlet -name&，找到后其&url-pattern&定义为&/MyServlet&，于是服务器会尝试匹配跟目录＋ url_pattern：。
&http://blog.csdn.net/shendl/archive//1427475.aspx& Java路径问题最终解决方案
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&& &可定位所有资源的相对路径寻址
Java的路径问题，非常难搞。最近的工作涉及到创建和读取文件的工作，这里我就给大家彻底得解决Java路径问题。
我 编写了一个方法，比ClassLoader.getResource(String 相对路径)方法的能力更强。它可以接受&../&这样的参数，允许我们用相对路径来定位classpath外面的资源。这样，我们就可以使用相对于 classpath的路径，定位所有位置的资源！
Java中使用的路径，分为两种：绝对路径和相对路径。具体而言，又分为四种：
一、URI形式的绝对资源路径
如：file:/D:/java/eclipse32/workspace/jbpmtest3/bin/aaa.b
URL是URI的特例。URL的前缀/协议，必须是Java认识的。URL可以打开资源，而URI则不行。
URL和URI对象可以互相转换，使用各自的toURI(),toURL()方法即可！
二、本地系统的绝对路径
D:/java/eclipse32/workspace/jbpmtest3/bin/aaa.b
Java.io包中的类，需要使用这种形式的参数。
但是，它们一般也提供了URI类型的参数，而URI类型的参数，接受的是URI样式的String。因此，通过URI转换，还是可以把URI样式的绝对路径用在java.io包中的类中。
三、相对于classpath的相对路径
如：相对于
file:/D:/java/eclipse32/workspace/jbpmtest3/bin/这个路径的相对路径。其中，bin是本项目的classpath。所有的Java源文件编译后的.class文件复制到这个目录中。
四、相对于当前用户目录的相对路径
就是相对于System.getProperty(&user.dir&)返回的路径。
对于一般项目，这是项目的根路径。对于JavaEE服务器，这可能是服务器的某个路径。这个并没有统一的规范！
所以，绝对不要使用&相对于当前用户目录的相对路径&。然而：
默认情况下，java.io 包中的类总是根据当前用户目录来分析相对路径名。此目录由系统属性 user.dir 指定，通常是 Java 虚拟机的调用目录。
这就是说，在使用java.io包中的类时，最好不要使用相对路径。否则，虽然在J2SE应用程序中可能还算正常，但是到了J2EE程序中，一定会出问题！而且这个路径，在不同的服务器中都是不同的！
相对路径最佳实践
推荐使用相对于当前classpath的相对路径
因此，我们在使用相对路径时，应当使用相对于当前classpath的相对路径。
ClassLoader类的getResource(String name),getResourceAsStream(String name)等方法，使用相对于当前项目的classpath的相对路径来查找资源。
读取属性文件常用到的ResourceBundle类的getBundle(String path)也是如此。
通 过查看ClassLoader类及其相关类的源代码，我发现，它实际上还是使用了URI形式的绝对路径。通过得到当前classpath的URI形式的绝 对路径，构建了相对路径的URI形式的绝对路径。（这个实际上是猜想，因为JDK内部调用了SUN的源代码，而这些代码不属于JDK，不是开源的。）
相对路径本质上还是绝对路径
因此，归根结底，Java本质上只能使用绝对路径来寻找资源。所有的相对路径寻找资源的方法，都不过是一些便利方法。不过是API在底层帮助我们构建了绝对路径，从而找到资源的！
得到classpath和当前类的绝对路径的一些方法
&&& 下面是一些得到classpath和当前类的绝对路径的一些方法。你可能需要使用其中的一些方法来得到你需要的资源的绝对路径。
1，FileTest.class.getResource(&&)
得到的是当前类FileTest.class文件的URI目录。不包括自己！
如：file:/D:/java/eclipse32/workspace/jbpmtest3/bin/com/test/
2，FileTest.class.getResource(&/&)
得到的是当前的classpath的绝对URI路径。
如：file:/D:/java/eclipse32/workspace/jbpmtest3/bin/
3，Thread.currentThread().getContextClassLoader().getResource(&&)
得到的也是当前ClassPath的绝对URI路径。
如：file:/D:/java/eclipse32/workspace/jbpmtest3/bin/
4，FileTest.class.getClassLoader().getResource(&&)
得到的也是当前ClassPath的绝对URI路径。
如：file:/D:/java/eclipse32/workspace/jbpmtest3/bin/
5，ClassLoader.getSystemResource(&&)
得到的也是当前ClassPath的绝对URI路径。
如：file:/D:/java/eclipse32/workspace/jbpmtest3/bin/
我推荐使用Thread.currentThread().getContextClassLoader().getResource(&&)来得到当前的classpath的绝对路径的URI表示法。
Web应用程序中资源的寻址
&&& 上文中说过，当前用户目录，即相对于System.getProperty(&user.dir&)返回的路径。
对于JavaEE服务器，这可能是服务器的某个路径，这个并没有统一的规范！
而不是我们发布的Web应用程序的根目录！
这样，在Web应用程序中，我们绝对不能使用相对于当前用户目录的相对路径。
在Web应用程序中，我们一般通过ServletContext.getRealPath(&/&)方法得到Web应用程序的根目录的绝对路径。
这样，我们只需要提供相对于Web应用程序根目录的路径，就可以构建出定位资源的绝对路径。
这是我们开发Web应用程序时一般所采取的策略。
通用的相对路径解决办法
Java中各种相对路径非常多，不容易使用，非常容易出错。因此，我编写了一个便利方法，帮助更容易的解决相对路径问题。
Web应用程序中使用JavaSE运行的资源寻址问题
在JavaSE程序中，我们一般使用classpath来作为存放资源的目的地。但是，在Web应用程序中，我们一般使用classpath外面的WEB-INF及其子目录作为资源文件的存放地。
在Web应用程序中，我们一般通过ServletContext.getRealPath(&/&)方法得到Web应用程序的根目录的绝对路径。这样，我们只需要提供相对于Web应用程序根目录的路径，就可以构建出定位资源的绝对路径。
Web应用程序，可以作为Web应用程序进行发布和运行。但是，我们也常常会以JavaSE的方式来运行Web应用程序的某个类的main方法。或者，使用JUnit测试。这都需要使用JavaSE的方式来运行。
这样，我们就无法使用ServletContext.getRealPath(&/&)方法得到Web应用程序的根目录的绝对路径。
而JDK提供的ClassLoader类，
它的getResource(String name),getResourceAsStream(String name)等方法，使用相对于当前项目的classpath的相对路径来查找资源。
读取属性文件常用到的ResourceBundle类的getBundle(String path)也是如此。
它们都只能使用相对路径来读取classpath下的资源，无法定位到classpath外面的资源。
Classpath外配置文件读取问题
如，我们使用测试驱动开发的方法，开发Spring、Hibernate、iBatis等使用配置文件的Web应用程序，就会遇到问题。
尽管Spring自己提供了FileSystem（也就是相对于user,dir目录）来读取Web配置文件的方法，但是终究不是很方便。而且与Web程序中的代码使用方式不一致！
至于Hibernate，iBatis就更麻烦了！只有把配置文件移到classpath下，否则根本不可能使用测试驱动开发！
&&& 这怎么办？
通用的相对路径解决办法
面对这个问题，我决定编写一个助手类ClassLoaderUtil，提供一个便利方法[public static URL getExtendResource(String relativePath)]。在Web应用程序等一切Java程序中，需要定位classpath外的资源时，都使用这个助手类的便利方法，而不使用 Web应用程序特有的ServletContext.getRealPath(&/&)方法来定位资源。
利用classpath的绝对路径，定位所有资源
这个便利方法的实现原理，就是&利用classpath的绝对路径，定位所有资源&。
ClassLoader类的getResource(&&)方法能够得到当前classpath的绝对路径，这是所有Java程序都拥有的能力，具有最大的适应性！
而目前的JDK提供的ClassLoader类的getResource(String 相对路径)方法，只能接受一般的相对路径。这样，使用ClassLoader类的getResource(String 相对路径)方法就只能定位到classpath下的资源。
如果，它能够接受&../&这样的参数，允许我们用相对路径来定位classpath外面的资源，那么我们就可以定位位置的资源！
当然，我无法修改ClassLoader类的这个方法，于是，我编写了一个助手类ClassLoaderUtil类，提供了[public static URL getExtendResource(String relativePath)]这个方法。它能够接受带有&../&符号的相对路径，实现了自由寻找资源的功能。
通过相对classpath路径实现自由寻找资源的助手类的源代码：
import java.io.IOE
import java.io.InputS
import java.net.MalformedURLE
import java.net.URL;
import java.util.P
import mons.logging.L
import mons.logging.LogF
&*@author沈东良shendl_
&*Nov29,2006&10:34:34AM
&*用来加载类，ｃｌａｓｓｐａｔｈ下的资源文件，属性文件等。
&*getExtendResource(StringrelativePath)方法，可以使用../符号来加载classpath外部的资源。
publicclass ClassLoaderUtil {
&&& privatestatic Log log=LogFactory.getLog(ClassLoaderUtil.class);
&&& &*Thread.currentThread().getContextClassLoader().getResource(&&)
&&& &*加载Java类。&使用全限定类名
&&& &*@paramclassName
&&& &*@return
&&& publicstatic Class loadClass(String className) {
&&& &&& try {
&&& &&&&& return getClassLoader().loadClass(className);
&&& &&& } catch (ClassNotFoundException e) {
&&& &&&&& thrownew RuntimeException(&class not found '&+className+&'&, e);
&&& && *得到类加载器
&&& && *@return
&&& &publicstatic ClassLoader getClassLoader() {
&&& &&& return ClassLoaderUtil.class.getClassLoader();
&&& && *提供相对于classpath的资源路径，返回文件的输入流
&&& && *@paramrelativePath必须传递资源的相对路径。是相对于classpath的路径。如果需要查找classpath外部的资源，需要使用../来查找
&&& && *@return&文件输入流
&&& &*@throwsIOException
&&& &*@throwsMalformedURLException
&&& &publicstatic InputStream getStream(String relativePath) throws MalformedURLException, IOException {
&&&&&&& &if(!relativePath.contains(&../&)){
&&&&&&&&&&& &return getClassLoader().getResourceAsStream(relativePath);
&&&&&&&&&&& &
&&&&&&& &}else{
&&&&&&&&&&& &return ClassLoaderUtil.getStreamByExtendResource(relativePath);
&&&&&&& &}
&&& && *@paramurl
&&& && *@return
&&& && *@throwsIOException
&&& &publicstatic InputStream getStream(URL url) throws IOException{
&&&&&&& &if(url!=null){
&&&&&&&&&&& &
&&&&&&&&&&&&&&& return url.openStream();
&&&&&&&&&&&
&&&&&&&&&&& &
&&&&&&& &}else{
&&&&&&&&&&& &returnnull;
&&&&&&& &}
&&& && *@paramrelativePath必须传递资源的相对路径。是相对于classpath的路径。如果需要查找classpath外部的资源，需要使用../来查找
&&& && *@return
&&& && *@throwsMalformedURLException
&&& && *@throwsIOException
&&& &publicstatic InputStream getStreamByExtendResource(String relativePath) throws MalformedURLException, IOException{
&&&&&&& return ClassLoaderUtil.getStream(ClassLoaderUtil.getExtendResource(relativePath));
&&&&&& *提供相对于classpath的资源路径，返回属性对象，它是一个散列表
&&&&&& *@paramresource
&&&&&& *@return
&&& &publicstatic Properties getProperties(String resource) {
&&& &&& Properties properties = new Properties();
&&& &&& try {
&&& &&&&& properties.load(getStream(resource));
&&& &&& } catch (IOException e) {
&&& &&&&& thrownew RuntimeException(&couldn't load properties file '&+resource+&'&, e);
&&& &&& return
&&& && *得到本Class所在的ClassLoader的Classpat的绝对路径。
&&& && *URL形式的
&&& && *@return
&&& &publicstatic String getAbsolutePathOfClassLoaderClassPath(){
&&&&&&& &ClassLoaderUtil.log.info(ClassLoaderUtil.getClassLoader().getResource(&&).toString());
&&&&&&& &return ClassLoaderUtil.getClassLoader().getResource(&&).toString();
&&& && *@paramrelativePath&必须传递资源的相对路径。是相对于classpath的路径。如果需要查找classpath外部的资源，需要使用../来查找
&&& && *@return资源的绝对URL
&&& &*@throwsMalformedURLException
&&& &publicstatic URL getExtendResource(String relativePath) throws MalformedURLException{
&&&&&&& &ClassLoaderUtil.log.info(&传入的相对路径：&+relativePath) ;
&&&&&&& &//(Integer.valueOf(relativePath.indexOf(&../&))) ;
&&&&&&& &if(!relativePath.contains(&../&)){
&&&&&&&&&&& &return ClassLoaderUtil.getResource(relativePath);
&&&&&&&&&&& &
&&&&&&& &}
&&&&&&& &String classPathAbsolutePath=ClassLoaderUtil.getAbsolutePathOfClassLoaderClassPath();
&&&&&&& &if(relativePath.substring(0, 1).equals(&/&)){
&&&&&&&&&&& &relativePath=relativePath.substring(1);
&&&&&&& &}
&&&&&&& &ClassLoaderUtil.log.info(Integer.valueOf(relativePath.lastIndexOf(&../&))) ;
&&&&&&& &String wildcardString=relativePath.substring(0,relativePath.lastIndexOf(&../&)+3);
&&&&&&& relativePath=relativePath.substring(relativePath.lastIndexOf(&../&)+3);
&&&&&&& &int containSum=ClassLoaderUtil.containSum(wildcardString, &../&);
&&&&&&& &classPathAbsolutePath= ClassLoaderUtil.cutLastString(classPathAbsolutePath, &/&, containSum);
&&&&&&& &String resourceAbsolutePath=classPathAbsolutePath+relativeP
&&&&&&& &ClassLoaderUtil.log.info(&绝对路径：&+resourceAbsolutePath) ;
&&&&&&& &URL resourceAbsoluteURL=new URL(resourceAbsolutePath);
&&&&&&& &return resourceAbsoluteURL;
&&& && *@paramsource
&&& && *@paramdest
&&& && *@return
&&& &privatestaticint containSum(String source,String dest){
&&&&&&& &int containSum=0;
&&&&&&& &int destLength=dest.length();
&&&&&&& &while(source.contains(dest)){
&&&&&&&&&&& &containSum=containSum+1;
&&&&&&&&&&& &source=source.substring(destLength);
&&&&&&&&&&& &
&&&&&&& &}
&&&&&&& &return containS
&&& && *@paramsource
&&& && *@paramdest
&&& && *@paramnum
&&& && *@return
&&& &privatestatic String cutLastString(String source,String dest,int num){
&&&&&&& &// String cutSource=
&&&&&&& &for(int i=0;i&i++){
&&&&&&&&&&& &source=source.substring(0, source.lastIndexOf(dest, source.length()-2)+1);
&&&&&&&&&&& &
&&&&&&&&&&& &
&&&&&&& &}
&&&&&&& &return
&&& && *@paramresource
&&& && *@return
&&&&& publicstatic URL getResource(String resource){
&&& &&ClassLoaderUtil.log.info(&传入的相对于classpath的路径：&+resource) ;
&&&&&&& &return ClassLoaderUtil.getClassLoader().getResource(resource);
&&& &*@paramargs
&&& &*@throwsMalformedURLException
&&& publicstaticvoid main(String[] args) throws MalformedURLException {
&&&&&&&&&&& //ClassLoaderUtil.getExtendResource(&../spring/dao.xml&);
&&&&&&& //ClassLoaderUtil.getExtendResource(&../../../src/log4j.properties&);
&&&&&&& ClassLoaderUtil.getExtendResource(&log4j.properties&);
&&&&&&& System.out.println(ClassLoaderUtil.getClassLoader().getResource(&log4j.properties&).toString());
ClassLoaderUtil类的public static URL getExtendResource(String relativePath)，虽然很简单，但是确实可以解决大问题。
不过这个方法还是比较简陋的。我还想在未来有空时，进一步增强它的能力。比如，增加Ant风格的匹配符。用**代表多个目录，*代表多个字符，？代表一个字符。达到Spring那样的能力，一次返回多个资源的URL，进一步方便大家开发。
1，尽量不要使用相对于System.getProperty(&user.dir&)当前用户目录的相对路径。这是一颗定时炸弹，随时可能要你的命。
2，尽量使用URI形式的绝对路径资源。它可以很容易的转变为URI,URL，File对象。
3， 尽量使用相对classpath的相对路径。不要使用绝对路径。使用上面ClassLoaderUtil类的public static URL getExtendResource(String relativePath)方法已经能够使用相对于classpath的相对路径定位所有位置的资源。
4，绝对不要使用硬编码的绝对路径。因为，我们完全可以使用ClassLoader类的getResource(&&)方法得到当前classpath的绝对路径。
使用硬编码的绝对路径是完全没有必要的！它一定会让你死的很难看！程序将无法移植！
如果你一定要指定一个绝对路径，那么使用配置文件，也比硬编码要好得多！
当然，我还是推荐你使用程序得到classpath的绝对路径来拼资源的绝对路径！
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：623484次
积分：9185
积分：9185
排名：第720名
原创：248篇
转载：162篇
评论：72条
(1)(2)(5)(1)(1)(4)(2)(1)(6)(28)(21)(7)(8)(16)(19)(39)(33)(22)(16)(32)(25)(8)(12)(11)(5)(12)(7)(13)(4)(8)(13)(10)(4)(17)