其实我们很早就想搞培训了，去年也筹备过一次，后来不了了之了。这次在David的努力下总算是有些眉目了，只要报名的人数足够，近期就可以开始了。我也会讲一部分内容，第五天的那些杂乱的内容，期望能够讲好。以前没有搞过，不知道能不能讲好，但是只要准备充分，应该问题不大吧。
希望David能够尽快招到人，顺便也在这里做个广告。
解惑
解己之惑，解人之惑
日：2006年12月1日
我从来没有考虑过这个问题，不过昨天遇到的问题其中有一个就是这个。
代码中调用了无状态Session Bean的remove方法，按照在TSS上的一个讨论的内容看，这个remove方法就是告诉服务器可以把那个Bean重新放到Bean的池子里面，但是其实没有必要，因为一般你的调用结束后服务器自然知道并把那个Bean放回池子。
原文如下：
The app server doesnt have to know anything from the client from the remove() operation, because after each and every method call, the bean is decoupled from the client. We had this discussion with SUN during the branding process and they confirmed that the remove() operation is a no-op on a stateless bean. Can you even fathom for me what remove() might do? According to the lifecycle, the bean goes in the pool immediately after it finishes running, so by the time you call remove() as per the spec, the bean must already be in the pool.
Trust me it does nothing. Read the generated stub source for your app server. Youll see.
最近在做公司的单元测试框架，本来感觉已经初具规模，可以开始正常的使用了，因为我写了40多个各种类型的测试用例都可以正常工作，另外一个组的同事开始写了一个，他说还是挑的一个最简单的，结果报了一堆的异常，呵呵，其实他是测试Message Driven Bean，代码里面要调用很多其它的东西，出了几个问题，一个是他要使用的一个Entity Bean的finder是我写的表达式不支持的，我只能把那个finder实现掉，然后就是代码中使用了一个Topic，而且不是我们的Server端代码使用的，没有对应的Message Driven Bean处理（框架只能自动发布有对应的Message Driven Bean的Queue或者Topic），这个问题忽略不计了，因为那个Message本来就不需要处理，然后就是另外一个finder方法，我的表达式是支持的，但是死活找不到，结果发现是那个Entity Bean的xdoclet的配置比较特殊，一般的Home接口都是Remote接口的名字加Home，结果那个Bean是加BeanHome，而Aspect的匹配表达式是默认的格式，没有办法，修改我的表达式了，谁让那个Home接口的名字是可配置的呢。
另外两个问题还没有搞定，一个是Stateless Session Bean的remove方法，不知道要做什么，我现在处理了Entity Bean的remove，调用那个的时候会从数据库中删除对应的记录，但是Stateless Session Bean的remove应该做什么呢？
一个是获得Topic，我们的那个Locator接口里面定义了获得各种Bean以及Queue的接口方法，但是没有定义获得Topic的方法，所以代码中都是使用：
Context jndiContext = new InitialContext();
topic = (Topic) jndiContext.lookup(serverDataSendTopicName);
这个lookup的过程框架拦截不到。
© 2025 解惑
本主题由Anders Noren提供 — 向上 ↑