jQuery, window.jQuery, window.$ or simply $ can be used interchangeably 2. window.onload 和 $(document).ready(function()） // Override the onload event window.onload = function(){ // the page finished loading, do something here... } This code actually overrides the onload event of the HTML tag. All this means to us is that our code will be executed soon as the page is finished loading. It makes sense because sometimes pages take time to load, or the downloading process is segmented by the browser architecture. The jQuery internal architecture also utilizes the window.onload event, but before it does so, it checks whether the entire DOM (document object model) has been loaded because it is very important. It is not enough for jQuery to know that the page has been loaded, we must ensure that the DOM has been fully constructed. To provide us with this functionality, jQuery gives us a new method called ready that we can call on the main jQuery object itself.
XMLAccess 是一个小型的独立应用程序程序，它使用 HTTP 连接与服务器进行连接。因此，可以访问和远程配置门户网站。）一般在portal 安装目录\bin 下面 xmlaccess.bat。 1. 导出portal page xmlaccess.bat -in d:***\ExportPage.xml -user ***-pwd *-url http://host/wps/config -out d:*\result_exportPage.xml ExportPage.xml 文件格式可以参考 Portal安装目录\doc\xml-samples 例如： <!-- sample for exporting a page --> <portal action="locate"> <content-node action="export" uniquename="ibm.portal.Documents.Welcome" /> </portal> 其他还有导入导出portlet, page 等。
编译器在当前的classloader的classpath上找到类.方法（名字相同的即可，不需要签名相同），并在其中挑选（可能有重载）一个。如果没有找到签名相同的并不会到别的class library中或者上一级classloader中去寻找，而是直接报错。除非当前类中根本就没有这个名字的方法。 sorry, 上面的理解是错误的。真实的原因是“方法遮蔽”造成的。比如内部类中方法会遮蔽同名（可以不考虑参数）的外部类中的方法。－－－－Thread.sleep()
有三种方式处理事务的模式 1. Client Own Transaction 应用场景： 服务端Service 组件不允许修改，且都是细粒度的服务，一次调用不能满足一个ACID的业务请求 由于客户端transaction context需要传播propagation到Server端，需要RMI协议支持。好像Spring中不支持。 通过RMI，EJB这种方式的话要求客户端用programmatic 事务处理，服务端需要用declarative 事务处理。这是因为transaction context不能在programmatic事务处理中传播。 缺点： 多次远程服务调用影响性能 方式： 统一由客户端发起，提交，rollback事务。 Server端组件事务读操作声明成support, 其他写操作需声明成Mandatory 2. Domain Service Own Transaction 应用场景： 服务端提供了粗粒度的服务封装 客户端不能管理事务，如Web Service Client(服务端封装成了Web Service) 减轻客户端的复杂度 方式： 事务只在这一层处理发起，提交，rollback Server端组件事务读操作声明成support, 其他写操作需声明成Required 3. Service Delegate Own Transaction 以上1和2的折中，相当于在Client和Server之间加入了一个Business Delegate层。 事务统一在这一层处理。 好处： 后端的Server层可以剥离Transaction相关的API，用POJO写 缺点： 客户端的逻辑（如一次请求多个服务端的调用）需要移到这一层，可能依赖于UI层的框架API，如HttpServletRequest之类的 方式： 该层方法事务读操作声明成support, 其他写操作需声明成Required
override 覆写 用于实例方法，签名相同，动态分派 a) 子类方法限定要大于等于父类。即限定变大了。 b) Never add exception types to the throws clause of a method overridden in a subclass 也即不能添加更多的异常到子类签名中。可以是父类异常的子类异常，甚至不加异常。所以异常应该是变小了。这主要是为了遵守Liskov OOP 替换原则。子类必须能替换父类，如果子类里有新加的异常，Try/Catch起码要引起变动。相反，子类没有异常并不影响现有的代码。 2. Hide 隐藏 子类属性隐藏父类的，也即父类属性不能继承到子类中（相同名字的话，可以是不同类型）。当然可以通过把子类转型到父类访问父类的属性。这是与覆写不同的地方。 a) private 属性根据dynamic type决定 frendly,pretected,public 属性根据static type 决定 静态属性根据类名决定，与类实例无关(即使是static final 类型的子类亦可Hide) 3. overload 重载 父类frendly / pretected / public 方法会继承到子类中，这时父类和子类中相同的方法签名也是overload(重载）。并不是只有定义在一个类中的方法才构成重载。 注意重载哪个方法是在编译时选择的，这与Override非常不同。 4. shadow 遮蔽 变量，方法或类型都有可能 常见的是临时变量遮蔽了类变量或者全局变量。对象方法遮蔽了static import进来的方法。 外围类（enclosing class）包含一个内部类（inner class），内部类（比如继承Thread类）继承的成员方法（比如sleep)遮蔽了外围累（enclosing class)的方法。 5. obscure 遮掩 变量可以遮掩类型，类型可以遮掩包。也即优先级不一样 比如声明一个变量名字为System（非正规的命名），该变量System会obscure Java系统类型System
实现多线程： 1. extends Thread 2. implement Runnable interface 线程应该用start 方法来启动。直接运行Run 方法并没有启动多线程，还是在主线程中执行run方法，跟普通方法调用一样。 3. 一般倾向于用new Thread(Runnable)这种方式而不是继承Thread，理由有二： 1. 用Runnable接口可以留下多继承的余地 2. 不会因为Thread类继承下来的锁或者方法相互干扰 sleep() join()，相当与thread实例.wait,会释放thread实例对应的锁。对于锁应该声明一个私有的对象锁，这样不会暴露到外面去引起误用。 private final Object lock = new Object(); 误用的例子如下： 比如创建一个新的Thread实例，系统都会获取Thread类上的锁。以下代码会阻止新线程的创建。 synchronized(Thread.class){ Thread.sleep(Long.MAX_VALUE); } 4. Synchronized 方法的锁是针对不同线程的，不同线程只能顺序执行该同步方法。但是同一个线程可以重复地获得某个相同的锁。也即可以调用别的Synchronized 方法，只要用的是同一把锁。
2. Spring Framework 支持的事务属性 1） PROPAGATION_REQUIRED --支持当前的事务，如果不存在就创建一个新的。这是最常用的选择。 2） PROPAGATION_SUPPORTS --支持当前的事务，如果不存在就不使用事务。 3） PROPAGATION_MANDATORY --支持当前的事务，如果不存在就抛出异常。 4）PROPAGATION_REQUIRES_NEW --创建一个新的事务，并暂停当前的事务（如果存在）。 5） PROPAGATION_NOT_SUPPORTED --不使用事务，并暂停当前的事务（如果存在）。 6） PROPAGATION_NEVER --不使用事务，如果当前存在事务就抛出异常。 7） PROPAGATION_NESTED --如果当前存在事务就作为嵌入事务执行，否则与PROPAGATION_REQUIRED类似。 3. 注意事项 1）PROPAGATION_REQUIRES_NEW 与 PROPAGATION_NESTED PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行. 另一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交. Savepoint需要最新的JDBC规范来支持。JDBC3? 由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 嵌套事务也会被 commit, 这个规则同样适用于 roll back. 2）Required和mandatory事务属性 一般写操作配置成这两种事务。 两种都支持transaction context. 区别在如果调用时没有transaction context, Required的会发起一个新的事务。而mandatory的会抛出异常。 深层次的区别基于下面的规则： With the exception of the stateful session bean, the method that starts a transaction must be the same method that terminates the transaction. 因为Required不能确认事务是否是在此方法中启动的还是从外面传进来的，因此不知道是否该做rollback这种处理当出现异常时。而Mandatory确认事务都是从外面传入的，因此知道自己不需要处理这种逻辑。 也就是说，如果事务不是在该层发起(客户端发起传入的），那么该层写操作就配置成Mandatory属性，要求调用方必须传入Transaction context；反之事务发起的层写操作应该设成required, 因为它可以控制事务的发起，回滚，提交等。
Programmatic Transaction Model应用的场景有： 1. 客户端bean发起一个事务,并把事务传播到调用的EJB中去，这些EJB用Declarative Transaction. 该方法解决了transation context不能在编程事务管理bean中传播的问题 2. 考虑到性能问题，有时我们只需要在关键的Case中需要用到事务，比如转账。其他周边Case不进行事务控制。这是可以考虑用编程事务。有时也称为Localized JTA Transations。声明式的事务可能没有编程式的灵活。个人理解，瞎猜的，没有用过。 3. 长事务， 放在一个stateful sessionBean中。虽然是一种Poor Design， 但还只有编程事务好处理。因为声明事务不好去划分事务的边界（propagation 和 isolation level). 个人理解，瞎猜的，没有用过。