插件管理技巧

　　提示：新下载的插件PlugIn一定不要都放在原始的Eclipse目录下去。

1. 前提是你已经安装好了Eclipse工具了，比如安装在E:\OpenSource\Eclipse\目录下，以下这个目录以%ECLIPSE_HOME%来进行表示；
2. 此时默认的插件是在%ECLIPSE_HOME%\plugins目录中的；
3. 在%ECLIPSE_HOME%下建立一个PlugInsNew的目录；
   比如：E:\OpenSource\Eclipse\PlugInsNew\
4. 你下载了个新的插件，比如叫做：XYZ
   　那么就在%ECLIPSE_HOME%\PlugInsNew\目录下建立XYZ目录，目录里面是eclipse目录，eclipse目录包含有features与plugins两个子目录；结构如下图所示：
   
   　　
   
5. 把下载的新插件的文件放在以下相应目录中
   %ECLIPSE_HOME%\PlugInsNew\XYZ\eclipse\features
   %ECLIPSE_HOME%\PlugInsNew\ XYZ\eclipse\plugins
   
6. 建立相关的.link的文件
   然后在%ECLIPSE_HOME%\links目录里建立一个XYZ.link的文件
   内容如是：path=E:/OpenSource/Eclipse/PlugInsNew/XYZ就一行这样的路径指示而已。
   当然，采用相对路径来表示可能更直观一些，方便进行文件整体移动和小组全部成员的共享命名用，省得移动后要改动Link文件里的绝对路径而费心费力。直接拷贝过去就可以使用。
   即XYZ.link文件的内容如是：path=../PlugInsNew/XYZ
   这样，如果你下载了多个插件就可以如法炮制建立多个Link文件，想加载哪个插件就把哪个插件的Link文件放到%ECLIPSE_HOME%\links的目录中即可，使用与管理都很方便，建议千万不要放在默认的安装目录中；
   如果你的%ECLIPSE_HOME%与此不同，请修改XYZ.link文件里的路径
   
7. 删除，关闭Eclipse
   删除%ECLIPSE_HOME%\links\XYZ.link文件即可
   删除%ECLIPSE_HOME%\PlugInsNew\XYZ整个目录及文件
   
8. 重新启动Eclipse即可

　　使用

　　重新启动Eclipse后，在Help => About Eclipse SDK => Plug-in Details你可以看到由“FindBugs Project”提供的“FindBugs Plug-in”版本0.0.17插件，如下图所示：

　　

　　FindBugs的使用方法

　　FindBugs是一个可以在Java程序中发现Bugs的程序。

　　它是专门用来寻找处于“Bug Patterns”列表中的代码的。

　　Bug Patterns指很有可能是错误的代码的实例。

　　目前FindBugs最高版本0.9.4，不过更新速度很快的，你应当经常上去看看是否有新版本发布。Eclipse plugin for FindBugs最高版本0.0.17。

　　系统要求

　　使用FindBugs至少需要JDK1.4.0以上版本，FindBugs是平台独立的，可以运行于GNU/Linux、Windows、MacOS X　等平台上。

　　运行FindBugs至少需要有256 MB内存，如果你要分析一个很大的项目，那就需要更加多的内存了。

　　FindBugs独立运行和与Ant结合的详细操作就不介绍了，可以看官方的文档http://findbugs.sourceforge.net/manual/

　　独立运行的效果图如下：

　　

　　本文主要介绍在Eclipse中使用的情况

　　打开Bug Details视图

　　Windows => Show View => Other… => FindBugs => BugDetails

　　

　　在Package Explorer或Navigator视图中，选中你的Java项目，右键，可以看到“Find Bugs”菜单项，子菜单项里有“Find Bugs”和“Clear Bug Markers”两项内容，如下图所示：

　　

　　我们建立一个简单的测试文件Test.java 内容如下：

public class Test { private String[] name; public String[] getName() { return name; } public void setName(String[] name) { this.name = name; } } 

　　我们点中“Find Bugs”，运行时会出现如下进度框：

　　运行结束后可以在Problems中看到增加了如下的警告信息内容

　　FindBugs运行后的警告信息内容不仅在Problems视图中显示，而且将标记在源代码标记框中，在源代码编辑器中我们可以看到警告标识，如下图：

　　当光标指向你的警告信息的代码上面时，就会有相应的错误提示信息，与Eclipse本身的错误或警告信息提示类似。

　　选中Problems视图里出现的相应问题，就会在代码编辑器里切换到相应的代码上去，方便根据相应的提示信息进行代码的修改。

　　

　　在Problems视图里，选中相应的问题条目，右键，在弹出的菜单中，可以看到“Show Bug Details”，如下图所示：

　　

　　点中它，会切换到Bug Details视图上去，显示更加详细的提示信息。

　　当然，在代码编辑窗口中，点击带有警告提示信息的图标时，也会自动切换到Bud Details窗口去，查看详细的警告信息，如下图所示。

　　

　　根据这里详细的信息，你可以得到FindBugs为什么会对你的代码报警告信息，及相应的处理办法，根据它的提示，你可以快速方便地进行代码修改。

　　

　　根据提示，我们将代码修改成如下，再运行就不会报有警告信息了。

public class Test { private String[] name; public String[] getName() {     String[] temp = name; return temp; } public void setName(String[] name) {     String[] temp = name; this.name = temp; } } 

　　配置FindBugs

　　选择你的项目，右键 => Properties => FindBugs =>

　　

　　可以配置的信息包括如上图所示的四个选项的相关设置：

1. Run FindBugs Automatically开关
   
   当此项选中后，FindBugs将会在你修改Java类时自动运行，如你设置了Eclipse自动编译开关后，当你修改完Java文件保存，FindBugs就会运行，并将相应的信息显示出来。
   
   当此项没有选中，你只能每次在需要的时候自己去运行FindBugs来检查你的代码。
   
   
2. Minimum priority to report选择项
   
   这个选择项是让你选择哪个级别的信息进行显示，有Low、Medium、High三个选择项可以选择，很类似于Log4J的级别设置啦。 比如：
   
   你选择了High选择项，那么只有是High级别的提示信息才会被显示。
   
   你选择了Medium选择项，那么只有是Medium和High级别的提示信息才会被显示。
   
   你选择了Low选择项，那么所有级别的提示信息都会被显示。
   
   
3. Enable bug categories选择项
   
   在这里是一些显示Bug分类的选择：
   
   Correctness关于代码正确性相关方面的
   
   Performance关于代码性能相关方面的
   
   Internationalization关于代码国际化相关方面的
   
   Multithreaded correctness关于代码多线程正确性相关方面的
   
   Style关于代码样式相关方面的
   
   Malicious code vulnerability关于恶意破坏代码相关方面的
   
   比如：如果你把Style的检查框去掉不选择中它，那么与Style分类相关的警告信息就不会显示了。其它的类似。
   
   
4. Select bug patterns to check for选择项
   
   在这里你可以选择所要进行检查的相关的Bug Pattern条目
   
   可以从Bug codes、Detector name、Detector description中看到相应的是要检查哪些方面的内容，你可以根据需要选择或去掉相应的 检查条件。

　　总结

　　此插件的功能很不错，可以帮助我们提升Java代码的编写能力，写出更加安全可靠的代码。建议使用或加在Ant里进行持续构建。

　　现在，你可以马上拿出你已经开发的一个项目，检查一下你的代码有没有问题了

在第二种模型中，我们可以清楚的把这4个类分为三层：

1、实体类层，即Item，带有domain logic的domain object
2、DAO层，即ItemDao和ItemDaoHibernateImpl，抽象持久化操作的接口和实现类
3、业务逻辑层，即ItemManager，接受容器事务控制，向Web层提供统一的服务调用

在这三层中我们大家可以看到，domain object和DAO都是非常稳定的层，其实原因也很简单，因为domain object是映射数据库字段的，数据库字段不会频繁变动，所以domain object也相对稳定，而面向数据库持久化编程的DAO层也不过就是CRUD而已，不会有更多的花样，所以也很稳定。

问题就在于这个充当business workflow facade的业务逻辑对象，它的变动是相当频繁的。业务逻辑对象通常都是无状态的、受事务控制的、Singleton类，我们可以考察一下业务逻辑对象都有哪几类业务逻辑方法：

第一类：DAO接口方法的代理，就是上面例子中的loadItemById方法和findAll方法。

ItemManager之所以要代理这种类，目的有两个：向Web层提供统一的服务调用入口点和给持久化方法增加事务控制功能。这两点都很容易理解，你不能既给Web层程序员提供xxxManager，也给他提供xxxDao，所以你需要用xxxManager封装xxxDao，在这里，充当了一个简单代理功能；而事务控制也是持久化方法必须的，事务可能需要跨越多个DAO方法调用，所以必须放在业务逻辑层，而不能放在DAO层。

但是必须看到，对于一个典型的web应用来说，绝大多数的业务逻辑都是简单的CRUD逻辑，所以这种情况下，针对每个DAO方法，xxxManager都需要提供一个对应的封装方法，这不但是非常枯燥的，也是令人感觉非常不好的。

第二类：domain logic的方法代理。就是上面例子中placeBid方法。虽然Item已经有了placeBid方法，但是ItemManager仍然需要封装一下Item的placeBid，然后再提供一个简单封装之后的代理方法。

这和第一种情况类似，其原因也一样，也是为了给Web层提供一个统一的服务调用入口点和给隐式的持久化动作提供事务控制。

同样，和第一种情况一样，针对每个domain logic方法，xxxManager都需要提供一个对应的封装方法，同样是枯燥的，令人不爽的。

第三类：需要多个domain object和DAO参与协作的business workflow。这种情况是业务逻辑对象真正应该完成的职责。

在这个简单的例子中，没有涉及到这种情况，不过大家都可以想像的出来这种应用场景，因此不必举例说明了。

通过上面的分析可以看出，只有第三类业务逻辑方法才是业务逻辑对象真正应该承担的职责，而前两类业务逻辑方法都是“无奈之举”，不得不为之的事情，不但枯燥，而且令人沮丧。

分析完了业务逻辑对象，我们再回头看一下domain object，我们要仔细考察一下domain logic的话，会发现domain logic也分为两类：

第一类：需要持久层框架隐式的实现透明持久化的domain logic，例如Item的placeBid方法中的这一句：

						this
						.
						getBids
						().
						add
						(
						newBid
						);
				

对于这一类domain logic，业务逻辑对象必须提供相应的封装方法，以实现事务控制。

第二类：完全不依赖持久化的domain logic，例如readonly例子中的Topic，如下：

class Topic{
booleanisAllowReply(){
CalendardueDate=Calendar.getInstance();
dueDate.setTime(lastUpdatedTime);
dueDate.add(Calendar.DATE,forum.timeToLive);

Datenow=newDate();
returnnow.after(dueDate.getTime());
}
}

注意这个isAllowReply方法，他和持久化完全不发生一丁点关系。在实际的开发中，我们同样会遇到很多这种不需要持久化的业务逻辑(主要发生在日期运算、数值运算和枚举运算方面)，这种domain logic不管脱离不脱离所在的框架，它的行为都是一致的。对于这种domain logic，业务逻辑层并不需要提供封装方法，它可以适用于任何场合。

第一种模型：只有getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称TransactionScript)，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。下面用举一个具体的代码来说明，代码来自Hibernate的caveatemptor，但经过我的改写：

一个实体类叫做Item，指的是一个拍卖项目
一个DAO接口类叫做ItemDao
一个DAO接口实现类叫做ItemDaoHibernateImpl
一个业务逻辑类叫做ItemManager(或者叫做ItemService)

						public
						class 
						Item
						implements
						Serializable
						{
						

						private
						Long
						id
						=
						null
						;
						

						private
						int
						version
						;
						

						private
						String
						name
						;
						

						private
						User
						seller
						;
						

						private
						String
						description
						;
						

						private
						MonetaryAmount
						initialPrice
						;
						

						private
						MonetaryAmount
						reservePrice
						;
						

						private
						Date
						startDate
						;
						

						private
						Date
						endDate
						;
						

						private
						Set
						categorizedItems
						=
						new
						HashSet
						();
						

						private
						Collection
						bids
						=
						new
						ArrayList
						();
						

						private
						Bid
						successfulBid
						;
						

						private
						ItemState
						state
						;
						

						private
						User
						approvedBy
						;
						

						private
						Date
						approvalDatetime
						;
						

						private
						Date
						created
						=
						new
						Date
						();
						

						/
						
						
						/
						getter
						/
						setter方法省略不写，避免篇幅太长
						

						}
				

						public
						interface
						ItemDao
						{
						

						public
						Item
						getItemById
						(
						Long
						id
						);
						

						public
						Collection
						findAll
						();
						

						public
						void
						updateItem
						(
						Item
						item
						);
						

						}
				

ItemDao定义持久化操作的接口，用于隔离持久化代码。

						public
						class 
						ItemDaoHibernateImpl
						implements
						ItemDao
						extends
						HibernateDaoSupport
						{
						

						public
						Item
						getItemById
						(
						Long
						id
						)
						{
						

						return
						(
						Item
						)
						getHibernateTemplate
						().
						load
						(
						Item
						.
						class
						,
						id
						);
						

						}
						

						public
						Collection
						findAll
						()
						{
						

						return
						(
						List
						)
						getHibernateTemplate
						().
						find
						("
						from Item
						");
						

						}
						

						public
						void
						updateItem
						(
						Item
						item
						)
						{
						

						getHibernateTemplate
						().
						update
						(
						item
						);
						

						}
						

						}
				

publicclass ItemManager{
privateItemDaoitemDao;
publicvoidsetItemDao(ItemDaoitemDao){this.itemDao=itemDao;}
publicBidloadItemById(Longid){
itemDao.loadItemById(id);
}
publicCollectionlistAllItems(){
returnitemDao.findAll();
}
publicBidplaceBid(Itemitem,Userbidder,MonetaryAmountbidAmount,
BidcurrentMaxBid,BidcurrentMinBid)throwsBusinessException{
if(currentMaxBid!=null&&currentMaxBid.getAmount().compareTo(bidAmount)>0){
thrownewBusinessException("Bid too low.");
}

//Auctionisactive
if(!state.equals(ItemState.ACTIVE))
thrownewBusinessException("Auction is not active yet.");

//Auctionstillvalid
if(item.getEndDate().before(newDate()))
thrownewBusinessException("Can't place new bid, auction already ended.");

//CreatenewBid
BidnewBid=newBid(bidAmount,item,bidder);

//PlacebidforthisItem
item.getBids().add(newBid);
itemDao.update(item);//  调用DAO完成持久化操作
returnnewBid;
}
}

事务的管理是在ItemManger这一层完成的，ItemManager实现具体的业务逻辑。除了常见的和CRUD有关的简单逻辑之外，这里还有一个placeBid的逻辑，即项目的竞标。

以上是一个完整的第一种模型的示例代码。在这个示例中，placeBid，loadItemById，findAll等等业务逻辑统统放在ItemManager中实现，而Item只有getter/setter方法。

第二种模型，也就是Martin Fowler指的rich domain object是下面这样子的：

一个带有业务逻辑的实体类，即domain object是Item
一个DAO接口ItemDao
一个DAO实现ItemDaoHibernateImpl
一个业务逻辑对象ItemManager

publicclass ItemimplementsSerializable{
//  所有的属性和getter/setter方法同上，省略
publicBidplaceBid(Userbidder,MonetaryAmountbidAmount,
BidcurrentMaxBid,BidcurrentMinBid)
throwsBusinessException{

//Checkhighestbid(canalsobeadifferentStrategy(pattern))
if(currentMaxBid!=null&&currentMaxBid.getAmount().compareTo(bidAmount)>0){
thrownewBusinessException("Bid too low.");
}

//Auctionisactive
if(!state.equals(ItemState.ACTIVE))
thrownewBusinessException("Auction is not active yet.");

//Auctionstillvalid
if(this.getEndDate().before(newDate()))
thrownewBusinessException("Can't place new bid, auction already ended.");

//CreatenewBid
BidnewBid=newBid(bidAmount,this,bidder);

//PlacebidforthisItem
this.getBids.add(newBid);// 请注意这一句，透明的进行了持久化，但是不能在这里调用ItemDao，Item不能对ItemDao产生依赖！

returnnewBid;
}
}

竞标这个业务逻辑被放入到Item中来。请注意this.getBids.add(newBid); 如果没有Hibernate或者JDO这种O/R Mapping的支持，我们是无法实现这种透明的持久化行为的。但是请注意，Item里面不能去调用ItemDAO，对ItemDAO产生依赖！

ItemDao和ItemDaoHibernateImpl的代码同上，省略。

publicclass ItemManager{
privateItemDaoitemDao;
publicvoidsetItemDao(ItemDaoitemDao){this.itemDao=itemDao;}
publicBidloadItemById(Longid){
itemDao.loadItemById(id);
}
publicCollectionlistAllItems(){
returnitemDao.findAll();
}
publicBidplaceBid(Itemitem,Userbidder,MonetaryAmountbidAmount,
BidcurrentMaxBid,BidcurrentMinBid)throwsBusinessException{
item.placeBid(bidder,bidAmount,currentMaxBid,currentMinBid);
itemDao.update(item);// 必须显式的调用DAO，保持持久化
}
}

在第二种模型中，placeBid业务逻辑是放在Item中实现的，而loadItemById和findAll业务逻辑是放在ItemManager中实现的。不过值得注意的是，即使placeBid业务逻辑放在Item中，你仍然需要在ItemManager中简单的封装一层，以保证对placeBid业务逻辑进行事务的管理和持久化的触发。

这种模型是Martin Fowler所指的真正的domain model。在这种模型中，有三个业务逻辑方法：placeBid，loadItemById和findAll，现在的问题是哪个逻辑应该放在Item中，哪个逻辑应该放在ItemManager中。在我们这个例子中，placeBid放在Item中(但是ItemManager也需要对它进行简单的封装)，loadItemById和findAll是放在ItemManager中的。

切分的原则是什么呢？ Rod Johnson提出原则是“case by case”，可重用度高的，和domain object状态密切关联的放在Item中，可重用度低的，和domain object状态没有密切关联的放在ItemManager中。

我提出的原则是：看业务方法是否显式的依赖持久化。

Item的placeBid这个业务逻辑方法没有显式的对持久化ItemDao接口产生依赖，所以要放在Item中。请注意，如果脱离了Hibernate这个持久化框架，Item这个domain object是可以进行单元测试的，他不依赖于Hibernate的持久化机制。它是一个独立的，可移植的，完整的，自包含的域对象。

而loadItemById和findAll这两个业务逻辑方法是必须显式的对持久化ItemDao接口产生依赖，否则这个业务逻辑就无法完成。如果你要把这两个方法放在Item中，那么Item就无法脱离Hibernate框架，无法在Hibernate框架之外独立存在。

第三种模型印象中好像是firebody或者是Archie提出的(也有可能不是，记不清楚了)，简单的来说，这种模型就是把第二种模型的domain object和business object合二为一了。所以ItemManager就不需要了，在这种模型下面，只有三个类，他们分别是：

Item：包含了实体类信息，也包含了所有的业务逻辑
ItemDao：持久化DAO接口类
ItemDaoHibernateImpl：DAO接口的实现类

由于ItemDao和ItemDaoHibernateImpl和上面完全相同，就省略了。

publicclass ItemimplementsSerializable{
//  所有的属性和getter/setter方法都省略
privatestaticItemDaoitemDao;
publicvoidsetItemDao(ItemDaoitemDao){this.itemDao=itemDao;}

publicstaticItemloadItemById(Longid){
return(Item)itemDao.loadItemById(id);
}
publicstaticCollectionfindAll(){
return(List)itemDao.findAll();
}
publicBidplaceBid(Userbidder,MonetaryAmountbidAmount,
BidcurrentMaxBid,BidcurrentMinBid)
throwsBusinessException{

//Checkhighestbid(canalsobeadifferentStrategy(pattern))
if(currentMaxBid!=null&&currentMaxBid.getAmount().compareTo(bidAmount)>0){
thrownewBusinessException("Bid too low.");
}

//Auctionisactive
if(!state.equals(ItemState.ACTIVE))
thrownewBusinessException("Auction is not active yet.");

//Auctionstillvalid
if(this.getEndDate().before(newDate()))
thrownewBusinessException("Can't place new bid, auction already ended.");

//CreatenewBid
BidnewBid=newBid(bidAmount,this,bidder);

//PlacebidforthisItem
this.addBid(newBid);
itemDao.update(this);//  调用DAO进行显式持久化
returnnewBid;
}
}

在这种模型中，所有的业务逻辑全部都在Item中，事务管理也在Item中实现。

(转载）

html在线编辑器对于我们作新闻产品之类的程序是很重要的，在网上找录了好了好一段时间，发现FCKeditor,跨平台的，正在进行的jsp项目正需要这款html在线编辑器。试用了一下FCKeditor,根据网上的文章小结一下：

1.下载
FCKeditor.java 2.3 (FCKeditot for java)
FCKeditor 2.2 (FCKeditor基本文件)
以下是下载地址：
http://www.fckeditor.net/download/default.html

2.建立项目:
建立项目tomcat/webapps/TestFCKeditor.

3.将FCKeditor2.2解压缩
将FCKeditor2.2解压缩,将整个目录FCKeditor复制到项目的根目录下，
目录结构为：tomcat/webapps/TestFCKeditor/FCKeditor
然后将FCKeditor-2.3.zip（java）压缩包中\web\WEB-INF\lib\目录下的两个jar文件拷到项目的\WEB-INF\lib\目录下。把其中的src目录下的FCKeditor.tld文件copy到TestFCKedit/FCKeitor/WEB-INF/下

4.合并web.xml:
将FCKeditor-2.3.zip压缩包中\web\WEB-INF\目录下的web.xml文件合并到项目的\WEB-INF\目录下的web.xml文件中。


5. 修改合并后的web.xml文件
修改合并后的web.xml文件，将名为SimpleUploader的Servlet的enabled参数值改为true，
以允许上传功能，Connector Servlet的baseDir参数值用于设置上传文件存放的位置。
添加标签定义:
<taglib>
<taglib-uri>/TestFCKeditor</taglib-uri>
<taglib-location>/WEB-INF/FCKeditor.tld</taglib-location>
</taglib>

运行图：