解决jquery版本冲突的有效方法
投稿：shichen2014
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了解决jquery版本冲突的有效方法,对于web设计的兼容性调试很有借鉴价值,需要的朋友可以参考下
用过jQuery的朋友都知道jQuery不同版本会引发冲突，本文就此问题提出有效的解决方案如下：
案例：解决jQuery1.3.2和1.4.2的冲突。（本例已测试通过！）
第一步：在1.4.2的源代码的最后加上一句 ：
var $j4 = jQuery.noConflict(true);
之所以在源码这里加，而不是像大多数文章提的在要用到的时候加，这是因为很多基于1.4.2的插件都要加，在这里加可以避免过多插件加这句代码导致重复。这一句是将1.4.2的jQuery和$的引用权限全部放弃。也就是基于1.4.2的插件不能再用jQuery和$了。同时给予$j4的新的命名空间，注意它是window的属性。看1.4.2的源代码会发现它其实也就执行了这两句：
window.$=_$;
window.jQuery=_jQ
道理同window.$=_temp$（返还命名空间）只是命名不同而已。
第二步：在基于1.4.2的框架的所有插件的头部加上以下代码：
var _temp$ = window.$,_tempjQuery = window.jQ
将jQuery1.3.2的$和jQuery放到临时的变量空间上：
window.$ = $j4;
这句和下面的那句都是为了给中间的代码能够正确使用jQuery和$用的。后面的$j4是赋予他们正确的引用。
window.jQuery = $j4;
之所以要先放临时变量存储，有三点必须这样做的理由：
①.我们不希望改动大量的jQuery插件源代码，最好是不动，即使改的话，尽量改的少。而在头部尾部加改动代码，中间的原始代码不动也是不错的一种方式。
②.因为1.4.2的已经放弃了jQuery和$的控制权，但是已有的插件代码又用了他们来做引用，因为插件不可能预知冲突，即使有冲突他人开发的插件也一定要用$或者jQuery引用，除非它不是jQuery下的插件。
③.为了防止插件里面直接用window.$和window.jQuery进行引用从而导致引用到1.3.2的jQuery和$，虽然这种情况比较少，但是以防万一。
中间的原始代码不动，尾部加以下代码：
window.$ = _temp$;//将$的引用权限返还给jQuery1.3.
window.jQuery = _tempjQ//将jQuery的引用权限返还给jQuery1.3.
第三步：以后要用基于jQuery1.4.2的选取函数就只能用$j4(element)了。
总结：到目前为止可行方案：jQuery1.4.2完全放弃$和jQuery的控制权限。1.3.2放弃$的控制权限但不放弃jQuery的权限，其实jQuery也可放弃，只不过要给个别名$j3。prototype最好放在jQuery1.3.2后面，它获得$的控制权限。只是以后要用jQuery1.4.2就必须用$j4来引用了。但这样即使有再多的jQuery框架版本冲突问题，也全部解决掉了。假如来了个1.2的jQuery怎么办，参照（2）的执行步骤，只不过第一步改为：
var $j2 = jQuery.noConflict(true);
第三步用$j2(element)罢了。道理都是相同的。
相信本文所述对大家的jQuery程序设计有一定的借鉴价值。
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具一次完整的jar包冲突解决过程 - Java二把刀 - ITeye博客
博客分类：
作为Java程序员，会经常碰到jar包冲突，特别是涉及到的外部依赖越多，冲突概率就会越大。由于我们的应用代码都是使用maven来管理的，所以依赖的解决相对比较容易。不过最近碰到的一个问题，确实经历了好多步才最终定位。
现象：应用启动过程中，spring容器启动失败，错误日志很明确，找不到CollectionUtils.isEmpty()方法，jar冲突的典型症状之一。
首先，确认了这个类是apache的commons-collections中的工具类（在eclipse中ctrl+shift+T或者command+shitf+T寻找CollectionUtils是来自哪个jar中，同时也可以看看是不是含有这个方法），那么执行maven命令分析依赖树mvn dependency:tree -e -Dincludes=*:commons-collections*，看看应用中如何依赖commons-collections，依赖路径以及依赖版本。结果稍微出乎意料，有两个commons-collections依赖，只是groupId不同（这个时候maven是无能为力的，maven会认为这两个依赖是不同的，不会认为是一样的，因为maven对依赖的标识就是坐标，与jar中的内容无关），一个是apache-collections，另外一个是commons-collections，查看第二个中的CollectionUtils是有isEmpty方法的，第一个是没有的，而且第一个jar和第二个jar的包结构是完全相同的，apache-collections是外部系统的类库引入的，感觉好奇葩，于是果断排除之。重新查看依赖树，OK，打包重启，依然相同的错误。
接下来，打开war包，看下WEB-INF/lib下的commons-collections确实是3.2.1，没有问题。说明war包没有问题，最起码war内不会冲突，war包没问题。那就是jboss有问题，由于之前碰到过类似的问题，直接去${jboss_home}/server/default/lib下查看，升级其中的commons-collections到3.2.1即可（应用的jar和容器中的冲突的话，以容器为主，因为容器被优先加载），无需打包，重启jboss。自信满满地以为问题解决了，结果错误还是没变。
继续，查看jboss其他的目录，看不到commons-collections的影子。貌似到此，无路可走了。所以想想，服务器上肯定还有commons-collections-3.1存在，或许是在隐藏目录中（为毛当时没想起来用find名称搜索commons-collections）。没办法，只能通过打日志来看看CollectionUtils是从哪儿加载的了，使用了几行代码：
URL url = getClass().getClassLoader().getResource("org/apache/commons/collections/CollectionUtils.class");
LOG.error("CollectionUtils is loading from {}", url.getPath());
重新打包部署之后，查看日志信息，显示CollectionUtils是用WEB-INF/lib/commons-collections-3.2.1.jar中加载的，真的好意外，一直都在说，jboss中的jar优先加载啊，然后才会加载war的？那为神马会显示是用war中加载的呢？而且war中的是jar包版本是OK的，至此，基本无路可走了。除非？除非那个获取加载路径的代码是有问题的，因为和我的认知确实是冲突的。于是就getResource()方法去问了web容器方面的“神”，给出的解释是这个方法返回的路径不一定是真实的加载路径，和具体的容器实现有关。
最后，貌似打开了思路，但是什么办法可以知道类的真实记载路径呢？jvm启动参数跟踪，-XX：+TraceClassLoading加在jboss其中参数中，重启jboss，查看应用启动之后的jboss日志。好吧，日志文件很大，搜索下CollectionsUtils，确实是从一个隐藏目录加载的commons-collections，问题定位到了，解决办法不用说了。
如果前边真的用find命令搜索解决了问题，那么也不会有后边对认知的颠覆，那样还会一直认为那个api是救命稻草呢，不知道要持续到什么时候呢。另外，用find命令也只能去试探性地搜索commons-collections这个文件，但是不能排除有的类库会把commons-collections的代码内嵌在自己的jar中，这种事儿见到不少。所以走了最长的路，收获一定是最多的:)。
浏览: 14209 次
来自: 杭州
不错，学习了
加载的时候一次性判断虽然不能根据需要动态反射类，但是却能够解决 ...
关键是jar文件的顺序，可以使用其它工程设置不同的jar包顺序 ...
&div class=&quote_title ...
整理得不错，可以转一个不？会保留出处。如何解决java工程中多个版本的包冲突问题 - Tree - ITeye博客
博客分类：
背景
最近工作上需要实现从mysql到hbase的实时数据同步的功能。经过多方了解，整理出解决方案：使用canal作为实时的数据源，然后开发一个client来完成与canal的对接，并将数据写入hbase数据库中。
问题
在开发接近尾声时，发现连接canal时需要使用protobuf-java-2.4.1.jar包，而连接hbase时则需要使用protobuf-java-2.5.0.jar。并且两者jar包无法兼容，使用任何一个jar都无法正常启动程序。
解决思路
为了程序能够正常运行，需要同时加载两个jar包。但是我们都知道，一个class在jvm内存中只有一份。
1.首先想到的是将canal中的protobuf版本升级至2.5.0，即修改canal源码使之使用2.5.0的jar包；
2.其次想到的合并2.4.1和2.5.0得到一个新的包，即比较2.4.1和2.5.0的不同之处，然后合并；
3.修改2.4.1中class的名字（通过修改package名）并重新打jar包，然后修改canal中引用到protobuf的地方并重新打jar包
事实证明第三种方法可行性最高，简单、方面又实用。
翻滚吧--少年
浏览: 9994 次
来自: 杭州
1、累2、坑
mysqldump --opt database | mysq ...
这个代码你最好格式化一下
int j = 1;
boolea ...本帖子已过去太久远了，不再提供回复功能。}