persistence.xml和类装载

部署时报这个错误:

java.lang.IllegalStateException: PersistenceProvider [oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider@1927691] did not return an EntityManagerFactory for name ‘mypu’

通常这样的问题是由于没有找到META-INF/persistence.xml或者是名字写错了。但是这里的配置并没有错,而且使用本地eclipse环境同样适用oc4j也是可以部署成功的。尝试把persistence.xml放到war把下的meta-inf目录,不成功。(原本这个文件是放到web-inf/lib下的一个jar里)
后来发现将war打包到ear再去发布就成功了。由此发现了oc4j对于war和ear不同的类装载策略。
关于jee的类装载层次可以看这篇文章

-还有一种可能是toplink-essential的版本问题,这个是好使的:2.0-b41-beta2 (03/30/2007)

—-这个问题解决了.原因是使用的应用服务器oc4j在部署是会记住上一次部署时的war文件名(它会根据这个文件名创建一个临时文件夹),而在下次部署时,如果war的文件名变掉,则会还去找原来的那个文件夹!!所以部署前要把oc4j缓存清除并重启!

编程真的是艺术吗?

最近的问题特别多。近几天再看得一本书《梦断代码,徐兴问我这是一本关于什么的书,我告诉他是一本寓言,一本关于软件开发,产品开发,软件工程,软件管理的启示。

其中有一个比较启发的地方,编程到底是不是艺术。很多非计算机人士经常会看到莫名其妙的符号和无与伦比的抽象后折服于程序员的惊人技艺。但这些真的是艺术吗?我从一开始就在怀疑这个。我们看到音乐,绘画这些艺术,无不是先从研究先人的杰作开始,但是很多时候我们在开始编程时是从研究他人杰出的代码和开发经历开始的吗?很多时候都不是。

当然上面这个不足以挑战“编程是艺术“这个结论。书中举了一例,如果所有的作家都有自己的“公司“,只有海明威的公司的人才能读到老人与海,你能想象还能接出什么丰盛的文学成果么?

计算机,或者编程的教育方式没有鼓励过类似“推敲“这样的行为。而这些是其他艺术必须也是最为重视的东西。除非编程真的不是艺术,或者说是另一种艺术,廉价的艺术。

编程到底是不是艺术?程序员到底是艺术家还是工程师?我现在还看不出来。

摘一些关于线程和进程

线程和进程
一个程序至少有一个进程,一个进程至少有一个线程

进程在执行过程中拥有独立的内存单元,而多个线程共享内存

每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行,必须依存在应用程序中,由应用程序提供多个线程执行控制。

从逻辑角度来看,多线程的意义在于一个应用程序中,有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用,来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。

进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位.线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位.线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源.

一个线程可以创建和撤销另一个线程;同一个进程中的多个线程之间可以并发执行.

进程有独立的地址空间,一个进程崩溃后,在保护模式下不会对其它进程产生影响,而线程只是一个进程中的不同执行路径。

线程有自己的堆栈和局部变量,但线程之间没有单独的地址空间,一个线程死掉就等于整个进程死掉,所以多进程的程序要比多线程的程序健壮,但在进程切换时,耗费资源较大,效率要差一些。
==
从用户角度来看,进程是应用程序的一个执行过程。从操作系统核心角度来看,进程代表的是操作系统分配的内存、CPU时间片等资源的基本单位,是为正在运行的程序提供的运行环境。

httpUnit无法获取select框的选项值(options)

今天用httpunit写一个测试时候发现无法设置select框,报错是:
com.meterware.httpunit.IllegalParameterValueException: May not set parameter ‘userInfo.processingUnit’ to ‘BOM’. Value must be one of: { }
at com.meterware.httpunit.SelectionFormControl$Options.reportNoMatches(FormControl.java:1186)
at com.meterware.httpunit.SelectionFormControl$SingleSelectOptions.claimUniqueValues(FormControl.java:1360)
at com.meterware.httpunit.SelectionFormControl$Options.claimUniqueValues(FormControl.java:1178)
at com.meterware.httpunit.SelectionFormControl.claimUniqueValue(FormControl.java:1059)

跟进发现,webform无法通过getOptions来获取选择项.google后发现有人建议把页面中的

<html xmlns=”http://www.w3.org/1999/xhtml”>
改成
<html>

果然管用. 为什么会影响到httpunit? 指定上述的命名空间的意思是说这个html文档是遵守xhtml规范.通过下面的方法打开httpunit的解析详情 – httpunit会在得到html内容后告诉你这个文档是否遵守了你所指定的规范.(这里是xhtml).

HttpUnitOptions.setParserWarningsEnabled(true);

结果会得到这样的信息:
At line 121, column 1: Element <BODY> not closed properly.
At line 121, column 1: Element <HTML> not closed properly.
At line 1249, column 1: Element <BODY> not closed properly.
At line 1249, column 1: Element <HTML> not closed properly.
At line 1477, column 1: Element <BODY> not closed properly.
At line 1477, column 1: Element <HTML> not closed properly.

也就是输出的页面已经不是严格遵守xhtml的了.(推测是sitemesh的使用问题,没有很好的组织页面之间的关系依赖.),然后HttpUnit使用他的html解析器去查找select框的options时就出问题了. 为什么httpunit的作者不把具体原因给出来呢?