那天写的邮件发挥了应有的作用，美国的架构师暂时接受了我的方案，因为目前的进度快于他的预期，所以他也就不能说太多，但是项目经理跟我说他还是很不高兴，昨天本来应该有个例行的会议也被他取消了。管不了这么多了，也许是我太冲了，太不给他面子了，但是我实在是无法忍受一遍一遍的做重复的事情，那样的话我宁愿换个工作。今天出去吃饭，大家也说了下目前中国的研发中心和美国那边的关系有点紧张，而且开发的主要工作都在逐步往中国转移，中国这边的BOSS也是公司的SVP，他也希望我们能够掌握主导，不过这个总归是个问题。
那天写的邮件发挥了应有的作用，美国的架构师暂时接受了我的方案，因为目前的进度快于他的预期，所以他也就不能说太多，但是项目经理跟我说他还是很不高兴，昨天本来应该有个例行的会议也被他取消了。管不了这么多了，也许是我太冲了，太不给他面子了，但是我实在是无法忍受一遍一遍的做重复的事情，那样的话我宁愿换个工作。今天出去吃饭，大家也说了下目前中国的研发中心和美国那边的关系有点紧张，而且开发的主要工作都在逐步往中国转移，中国这边的BOSS也是公司的SVP，他也希望我们能够掌握主导，不过这个总归是个问题。
呵呵，今天BOSS回来了，竟然为了我们那个项目的事情到我们的Cube和我们简单了说了下，而另外一个BOSS也和美国那边的架构师以及项目经理开了个电话会议，然后我们的项目经理到我们这里仔细的问了下情况，说美国的架构师很生气，我猜想是因为我没有使用那个架构师的设计，我跟项目经理谈了我为什么要那么修改，他转而支持我，只要BOSS同意，然后又和BOSS谈了下，他只谈及了项目的目标，并不关注实现的细节，而且他说美国的架构师也只是因为担心我们把太多的精力花在搭建Framework上而不能完成原来的目标，而如果不能完成目标，他很可能会失业，而我们不会有影响。不管架构师到底担心什么，我还是写了封信解释我为什么那么做，以及现在取得的成果，而且跟他保证我们在下周就可以完成大部分代码，希望在明天早上的会议上他能够同意我的方案，希望他真的不是因为我们不用他的设计才生气的，否则结果很难讲。
帮别人做apache＋Tomcat的集群，另外只能对外开放SSL端口，所以用OpenSSL做了SSL的配置，然后我想看看他们的Access.log，但是修改配置后无效，后来发现是httpd-ssl.conf中的配置会覆盖httpd.conf中的配置，查了下apache的手册，发现原来虚拟主机的配置会覆盖系统的配置，而SSL的配置就是利用虚拟主机配置的，问题解决。
PS：apache2.2新增了一个很好的特点，就是SetEnvIf，可以设计Access.log中只纪录某些类型的访问，对于我们而言，主要关注的就是动态的内容，静态的内容不仅多，而且我们一般都不太关注，所以这样配置下就可以只纪录.do的请求：
SetEnvIf Request_URI "\.do" is_action
CustomLog logs/access.log common env=is_action
呵呵，不是我应聘而是面试应聘我们公司这个职位的人，已经面了不少人了，没有一个觉得还可以的，最开始是一个留美的女博士，数据库DBA的经验太少，而且她倾向于做交流方面的工作，而不是侧重于技术，好发挥她的英语口语的优势，后来面试的几个要么基本上就是做一些 数据库维护，没有系统的数据库设计的经验，要么基本上就没有接触过SQL Server服务器，也不倾向于做SQL Server的DBA相关的工作，呵呵，难啊。
被调到新的项目组，理论上算个Team Leader，没有真正的转正，老大最开始跟我说这边的事情我可以做主，但是美国那边有个架构师开始搭了个架子，意思是在这个架子的基础上做，试了下，发现很繁琐，为了增加一个方法，得修改好多个类。这个阶段其实是个过渡阶段，以后我们会使用Web Service，所以我们哟定义Web Service的接口，然后因为是过渡阶段，所以提供了EJB2的过渡方案和原来的系统整合，所以还得改Remote接口，Local接口可以直接从Service接口extends一下就行了，然后得修改Service的实现类，加上原先的架子里面，设计的是Service里面的每个public方法对应一个Operation类，这些类设计成Command模式，方便以后可以更好的进行负载的Dispatch，就这样，给Service增加一个接口，要完全实现得至少修改3个类，增加一个类，而且前两天也提过这个项目使用的Annotation的一个好处，但是这样一来，我要实现那个接口，也得在Finder里面增加方法。最终，我得修改4个类，增加一个类来增加一个Service接口。天啊，这个是我最讨厌的。
下周打算修改这个架子，取消EJB2的临时方案，使用Dynamic Proxy实现Service，同时可以引人Transaction（这个方案原来也用了，但是架构师以Transaction的问题否决了，那个时候还没有想到怎么解决Transaction的问题，前天突然想起来我的EJB单元测试框架就是用的自定义Transaction的），同时也抛弃Finder的那个方案，因为其实我的BaseOperation已经提供了进行Hibernate的查询的方便的基础功能。最重要的是Finder中定义的Query如果有问题的话修改后不能Hot Deploy，如果在Operation的方法体里面的修改就可以Hot Deploy。这样修改后，增加一个接口只需要修改Service然后增加一个Operation类实现就行了，只要改两个地方。
前几天包包里面带的酸奶破了，结果搞得一塌糊涂，最重要的是把手机也泡了，手机不能用了，今天去维修中心修，检测了下，说清理下然后换个直流放大管试试，修得好的话220，修不好不要钱，等了一个多小时，可以点亮了，但是开始的时候经常自动重启，然后他们又拿进去问了下，说是主板有问题，不好修，这次维修就不要钱了，窃喜，拉着老婆赶紧走了。其实自动重启的问题上个月就有了，因为不是什么大问题，一直保持开机状态就行了，没想到这次因为这个小问题省了220块钱，呵呵。
Apache2.2新增加了几个module，和tomcat集成更加的简单了：
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so
ProxyRequests Off
ProxyPass / balancer://myCluster/
<Proxy balancer://myCluster/>
BalancerMember ajp://localhost:10009 route=tomcat1
BalancerMember ajp://localhost:20009 route=tomcat2
</Proxy>
加入另外一个项目获得的最大的好处就是这个了，他们定义了一些Annotation，然后定义一些Finder接口，接口里面只定义方法，但是不用实现，使用Dynamic Proxy实现接口实现方法参数和Query中的参数自动绑定，赞一个。这样写Hibernate的Query就很简单了，只需要定义基本的东西就行了。
本来感觉是很理所当然的事情，那就是Bean要实现Remote或者Local借口，但是EJB规范里面并没有这个要求，只要Bean里面实现了Remote和Local里面定义的方法，方法签名完全一致，我所经历的所有的项目都是这样的。现在为另外一个项目做东西，在检查一些代码调用的时候发现跟踪不到，结果发现就是因为Bean没有实现接口，开始还笑话他们，后来google了下，发现原来是自己错了。不过实现接口也有好处，可以进行编译期检查约束。
这个东东其实以前就想到要找的，但是那个时候使用了比较重量级的解决方案：JBoss的Embedded container，主要用于单元测试，我们的代码难于单元测试，原因就是对JNDI的严重依赖，以及JNDI Server必须启动，而JNDI服务是JBoss提供的。
现在找到的这个东东就是轻量级的JNDI Server，而且提供In Memory的工作方式，单元测试代码可以修改name对应的返回对象是什么，这样单元测试代码就可以很容易测试了。
网址：
http://osjava.org/simple-jndi/
© 2025 解惑
本主题由Anders Noren提供 — 向上 ↑