The first mentioned book is completely outdated. The author explain step-by-step how to perform certain refactorings manually, but nowadays any mature IDE will do those refactorings automatically in not more than two mouse clicks. Besides, most of explained approaches are simply trivial and obvious. If I have the same statement at the beginning of if block and else block, I don’t need a book to figure out, that those duplicated statements can be moved before if condition. Also reading how to extract interface from existing class o…

...and prefer Spring. After passing my SCBCD exam lately, I gathered few disadvantages of EJB3 standard, which I found especially irritating and annoying.

1. Whole concept of session beans is unclear to me. Every programmer having even basic knowledge about concurrent programming knows, that single object can be safely accessed by multiple threads as long as concurrent threads do not modify the same variables (in short). But since method arguments and local variables are local to the thread (they exist on stack), the only shared variables are object fields. Logically, if the object has no fields (holds no state), it can be safely accessed by multiple clients at the same time.Stateless session beans are, well... stateless, they should not hold any state and the client should not depend on it. So why, on earth, SLSBs are pooled and each client has its own instance a t atime? Why in order to service N clients concurrently, application server creates N instances (or less, making some clien…

While preparing for SCBCD exam I encountered many difficulties in securing remote EJB 3 stateless session bean, and then calling such a component from remote standalone client. I hope this short introduction will help you… avoiding this problem. First, I simply put security annotations on my bean as follows:

@Stateless@RolesAllowed("ROLE_ADMIN")@PermitAllpublic class DateServiceBean implements DateServiceRemote { //...}Surprisingly such a bean can be easily deployed on JBoss 5.1.0 application server and all its methods are available. Why surprise? Because no ROLE_ADMIN was defined in JBoss nor the client was authorized. As the role was not defined, server silently ignored the security annotation! I learned my lesson – always verify security configuration, especially whether it actually secures anything…

Quick tour over JBoss documentation and I discovered @org.jboss.annotation.security.SecurityDomain annotation, which should mark all the beans using declarative as well as prog…