"Java Concurrency in Practice", written by Brian Goetz et al., is not brand new, but certainly one of the best Java books I had pleasure to read. But first two other books should be mentioned. Few months ago I took two classic Java readings: "Refactoring: Improving the Design of Existing Code" by Martin Fowler and "Java Puzzlers: Traps, Pitfalls, and Corner Cases" by Joshua Bloch and Neal Gafter. And I didn’t enjoy both of them.
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 or advices like "rename your method so that its name better explains what it does" is wasting time of any reasonable developer. Fowler does a great job of emphasizing the role of refactoring and unit testing, but short article with a table of major Java IDEs refactoring shortcuts is enough for today.
The latter book is a set of short Java code snippets, mostly followed by well known "what will the program print?" question. But the real question is "why even bother?" Do we really need to know that backslash still escapes characters in comments? Is knowledge of every detail of Java Language Specification is really necessary to call ourselves so-called "professional developers"? Although I have found many surprising and interesting examples in this book, it reminded me SCJP exam too much. And it is not a compliment.
Now it’s time for the winner, "Java Concurrency in Practice". Great thing about this reading is that it covers the subject of concurrency from all points of view. Starting from Amdahl's law, which should be known by every software engineer taking advantage of multitasking, through the details of JVM and CPU architecture to explaining new concurrency API. All of that in less than 400 pages.
I can’t remember when was the last time I heard how many CPU cycles does particular Java operation take – thanks to Brian Goetz I am not feeling disgusted by such a nasty technical details. Also the author introduces many charts and does some research to discover which implementation is actually fastest for some example problem. Besides, new Java concurrency API (thread pools, atomic primitives, collections) is introduced and discussed, also from implementation side. For example, look at the source code of Sun’s implementation of AtomicInteger, which is thread safe. I felt pretty amazed when I discovered that synchronized keyword or any other synchronization mechanism has not been used in this class. How is it possible while still preserving thread-safety? This book answers many more questions.
"Java Concurrency in Practice" will not introduce you another framework, simple servlet example is probably all what you get. But I am sure that the quality and performance of my code has improved after reading this great book. Learn how to use threads effectively – and how to avoid them.
For something more up-to-date, I am finishing "Programming Groovy: Dynamic Productivity for the Java Developer", so expect few blog entries inspired by this book. But I am in a hurry, because I can’t wait to start "Modular Java: Creating Flexible Applications with OSGi and Spring". So please expect OSGi soon.
August 31, 2009
August 16, 2009
Spring AOP riddle
Spring support for aspect oriented programming is very wide, but sometimes you may shoot yourself in the foot if you are not careful enough. Consider the following service interface:
...and its implementation:
To keep things simple, assume that foo() throws exception if not run in context of active transaction. Since main() is so old-school, we’re going to test both methods through test case:
Assuming testFoo() succeeded, will testBar() succeed as well? The trick part is transaction propagation...
...
The problem with bar() method is that it is not marked as transactional, but since it calls transactional method foo(), you may expect that foo() is called within a transaction... but it’s not! And since foo() called from bar() isn’t wrapped in a transaction, foo() will throw a exception and the test will fail.
To explain this odd behavior, you must first understand how aspects (including declarative transactions) are applied to Spring beans. When we mark any of beans’ methods with @Transactional annotation, Spring automatically wraps the bean in Java dynamic proxy*. This proxy intercepts all method calls from other beans and if it encounters method marked as transactional, it performs special, transaction related routines (linking to existing or creating new transaction, rolling back on exception, etc.) Of course, the advice calls original method of wrapped object during its execution (like foo()). So as long as you are running foo(), Spring handles transactions transparently and smoothly.
But think what happens when you call bar() method. Method is not marked as transactional, so even though transactional proxy will intercept the call, it will soon discover that method does not require transaction and simply delegate to original method bar(). Then the method invokes foo(). This is the place, where we expect the transaction to be started, but wait! – we are invoking foo() method on this reference, which points directly to the bean, not transactional aspect proxy. Spring does not know anything about this call, since you are calling method on Java object (POJO), not on a proxy instance wrapping this object. Declarative transaction management won’t be applied and foo() will throw unexpected exception.
The answer is pretty obvious if you understand the mechanics of Spring AOP, because the same problem will occur in any code using aspects, not only transactions and not only via annotations. In fact, also the same problem has been solved in EJB by using SessionContext.getBusinessObject() method – passing this is forbidden by the specification. In Spring, the easiest way to avoid this particular bug in our code is to simply annotate bar() method as well.
* If our bean does not implement any business interface, CGLIB will be used instead. Also, you must use <tx:annotation-driven /> to make this magic happen.
UPDATE:
public interface FoobarService {
void foo();
void bar();
}...and its implementation:
public class DefaultFoobarService implements FoobarService {
@Override
@Transactional
public void foo() {
//some code requiring active transaction
}
@Override
public void bar() {
foo();
}
}To keep things simple, assume that foo() throws exception if not run in context of active transaction. Since main() is so old-school, we’re going to test both methods through test case:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class DefaultFoobarServiceTest {
@Autowired
private FoobarService foobarService;
@Test
public void testFoo() {
foobarService.foo();
}
@Test
public void testBar() {
foobarService.bar();
}
}
Assuming testFoo() succeeded, will testBar() succeed as well? The trick part is transaction propagation...
...
The problem with bar() method is that it is not marked as transactional, but since it calls transactional method foo(), you may expect that foo() is called within a transaction... but it’s not! And since foo() called from bar() isn’t wrapped in a transaction, foo() will throw a exception and the test will fail.
To explain this odd behavior, you must first understand how aspects (including declarative transactions) are applied to Spring beans. When we mark any of beans’ methods with @Transactional annotation, Spring automatically wraps the bean in Java dynamic proxy*. This proxy intercepts all method calls from other beans and if it encounters method marked as transactional, it performs special, transaction related routines (linking to existing or creating new transaction, rolling back on exception, etc.) Of course, the advice calls original method of wrapped object during its execution (like foo()). So as long as you are running foo(), Spring handles transactions transparently and smoothly.
But think what happens when you call bar() method. Method is not marked as transactional, so even though transactional proxy will intercept the call, it will soon discover that method does not require transaction and simply delegate to original method bar(). Then the method invokes foo(). This is the place, where we expect the transaction to be started, but wait! – we are invoking foo() method on this reference, which points directly to the bean, not transactional aspect proxy. Spring does not know anything about this call, since you are calling method on Java object (POJO), not on a proxy instance wrapping this object. Declarative transaction management won’t be applied and foo() will throw unexpected exception.
The answer is pretty obvious if you understand the mechanics of Spring AOP, because the same problem will occur in any code using aspects, not only transactions and not only via annotations. In fact, also the same problem has been solved in EJB by using SessionContext.getBusinessObject() method – passing this is forbidden by the specification. In Spring, the easiest way to avoid this particular bug in our code is to simply annotate bar() method as well.
* If our bean does not implement any business interface, CGLIB will be used instead. Also, you must use <tx:annotation-driven /> to make this magic happen.
UPDATE:
- More details: Spring AOP riddle demystified
August 11, 2009
10 reasons why I don’t like EJB3
...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 clients waiting)? Spring beans are mostly singletons and they are used by concurrent clients with no problems. We are enterprise developers, we know what concurrency and synchronization is – and how to avoid it, by writing thread-safe code. What does the overhead of pool-management give us in return?
The other part are stateful session beans. First, think about applications having web tier. They already give you the set of tools you need: HTTP session. Why can’t it be used instead of session beans? Most web containers can replicate sessions, servlet specification defines notification API for passivation and activation events. But still, HTTP session is not "enterprise" enough. In fact, you still need to use it, at least to store the reference to SFSB (sic!) But what about Java SE and other clients? If you actually need server-side, short-living state, why not to use persistence? In some cases you won’t even touch the database, as everything will happen in cache. Or maybe other mechanism; do we really need stateful session beans as such a strong part of the specification? In Spring I have my singleton beans and session-scoped beans, they do the job well.
2. Poor dependency injection. You are only allowed to inject certain set of objects to session beans, message driven beans and interceptors. Would you like to inject EntityManager to EntityListener (think of the new possibilities) or completely constructed collection to some bean? Or maybe inject some non-EJB object, which is created via the factory? Those, and many other scenarios can’t be achieved in EJB3. Yes, but you can inject integer located in JNDI to int field, amazing!
3. Aspect oriented programming. During the past ten years, AOP is becoming more and more widely used. But certainly not in EJB, where the concept of interceptors is a total misunderstanding. First of all, you can match the interceptor to single method, all methods in a single bean or to all beans. Do we miss something? Thinking about matching all the methods in "*Dao" named beans? Or maybe all methods matching "send*" pattern, no matter in which bean? No can do, all or (almost) nothing. Secondly, the whole point of aspect oriented programming is to decouple production code from aspects. In EJB3 you can use ejb-jar.xml or @Interceptors annotation. Yes, you put the information about which interceptors should be invoked directly in the target bean. This is completely the opposite of what I expect and how it is done for instance in AspectJ. Production code is polluted with interceptors meta-information.
If I look at the Spring support for aspect oriented programming, EJB3 interceptors look more like a joke to me. By the way did I mention that specification only allows for around advices? I know, this is the smallest problem.
4. Support for third-party technologies. EJB3 has great support for JPA, allowing you to inject EntityManager directly to session and message driven beans. And that’s all... Try to send JMS message with proper resource management and error handling, same with JDBC. Try to integrate iBATIS to your app, use any web framework, try to use almost anything – and you’ll end up with writing tons of code by hand. EJB3 is a specification and does not provide any support for many major technologies. This makes writing serious applications very time-consuming and error-prone, as lots of code should be either written or copy-pasted multiple times. Surely, you can use Spring utilities in your EJB3 project (like JmsTemplate), but wouldn’t it be simpler just to use one tightly integrated framework?
5. Scheduling asynchronous jobs. Quartz is known for many years, Unix cron is older than me. And what is "brand new" JSR 220 offering? You cannot even simply start a job at specific hour of day, because if you use 24h interval, it will work properly only for half of the year (hint: DST). Not to mention such a fancy expressions like "run it on every last Friday of the month between April and October each fifteen minutes during the night". TimerService is deadly simple: specify direct date or delay, nothing more. But the funniest thing about scheduling jobs is that... you can’t do it! New job may be scheduled only within SLSB or message driven bean’s business method. Forget about starting new job when application starts up, it can’t be done (see point 9). You must call some EJB, which will explicitly start the timer. This sounds like a job for JMS: you run some business method and it schedules other activity to be run asynchronously in other thread – but it’s not. To make matters worse, the specification even suggests to use scheduled jobs for some recovery and cleanup tasks (e.g. because method annotated with @PreDestroy is NOT called on system exception, don’t ask me why). OK, this is typical task for asynchronous jobs but hey, you cannot start them automatically. And even if you manage to hack you application, you must first check, whether the job isn’t already started because jobs survive server crash... and you might start the job once again. Odd...
6. Lack of portability. Some configuration parameters are just dying to be portable across different application server. For example number of instances of enterprise beans. But even though there is a specification, simplest activities like invoking remote secured EJBs is not portable. Not to mention JNDI names. This means porting your application to different AS is going to be configuration nightmare, as you have to map hundreds of server-specific options, which are mostly the same, but for instance, have different names.
7. Distributed configuration. I like Spring applications because all they produce is a single, portable WAR file, depending only on containers’ servlet specification. If you use EJB3, you have external data sources, JMS queues, security configuration, etc. You are bound to AS and EAR file is just one piece of many, which must be deployed. Sun recommends dividing your team to many roles, each having access to different parts of the app (Bean Provider, Assembler, Deployer, etc.) I don’t buy it, as a developer I can choose JDBC connection pool provider, JMS provider – I do not depend on anybody, I have full control over my application.
8. No Open Entity Manager In View support. In Spring there is a concept of OpenSessionInView or OpenEntityManagerInView. If you have ever written any web application, you are probably familiar with this pattern, sometimes prefixed with anti-. In short, Spring manages filter which keeps Hibernates Session or JPAs EntityManager open all the time the HTTP request is being processed. It means you can use lazy loading of persistent attributes whenever you like, especially in view and controller (not only in model layer). In EJB3, when your entity leaves bean with transaction scoped EntityManager, it is detached from persistence context and you may no longer rely on lazy loading (in fact, JPA specification does not specify the behavior in such situation, probably some vendor dependent exception will be thrown...) Of course, you may use EntityManager with extended persistence context, holding the transaction and persistence context as long as you want. But this feature is only available for SFSB, while DAO classes are typical examples of stateless services, since they only dispatch calls to the persistence layer. Additionally, having dedicated DAO bean instance for each client seems to be a big overkill.
9. No startup/shutdown application callbacks. I mentioned about that in point 5. It is obvious that you might want to call some code when your application starts up. Obtain resources, read configuration, schedule job, or just log something interesting. But EJB3 has no mechanism for that. You might consider @PostConstruct annotated methods, but they are actually called whenever new instance of some bean is created. And this typically happens when the first client accesses the bean and will eventually happen again for each new instance. In Spring I have a singleton service and using the same @PostConstruct annotation the goal is achieved. I can also subclass ContextLoaderListener and capture the very beginning of my app. There are valid and elegant possibilities.
10. Unit testing. In Spring I typically run micro-integration test of my bean and all other beans which are necessary to run the test. I can also run almost whole application, mocking only the most low-level beans, like data sources. I can also unit test single bean and inject mocks manually. In EJB3 matters get complicated. There is Ejb3unit, which only emulates the JEE environment. On the other hand there are some embedded containers, but would you really on them, especially if you are not embedding the same server as the production one? Not to mention the time that is needed to run such a tool. In most cases, it is faster for me to run mvn jetty:run (which is a complete environment for most of Spring apps) than to run unit test using embedded container...
I found Spring and EJB3 being direct rivals, covering pretty much the same area of use-cases. I know 3.1 specification changes a lot (singletons, better scheduling), but JSR-220 is three years old and 3.1 still didn’t came out. And I don’t want to start new holy war, especially because I also find many attractive features in Enterprise Java Beans. The most valuable thing is absolutely zero-configuration principle. Just add @WebService and @Stateless annotation to your class, compile, deploy and voilà, Java code is exposed as a web service, WSDL is generated, everything runs in stable application server environment. Dependency injection (despite its limitations) is as simple as it could, JPA integration is great. But after so many years of Spring framework development, it simply became more mature and flexible solution, in my humble opinion, of course.
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 clients waiting)? Spring beans are mostly singletons and they are used by concurrent clients with no problems. We are enterprise developers, we know what concurrency and synchronization is – and how to avoid it, by writing thread-safe code. What does the overhead of pool-management give us in return?
The other part are stateful session beans. First, think about applications having web tier. They already give you the set of tools you need: HTTP session. Why can’t it be used instead of session beans? Most web containers can replicate sessions, servlet specification defines notification API for passivation and activation events. But still, HTTP session is not "enterprise" enough. In fact, you still need to use it, at least to store the reference to SFSB (sic!) But what about Java SE and other clients? If you actually need server-side, short-living state, why not to use persistence? In some cases you won’t even touch the database, as everything will happen in cache. Or maybe other mechanism; do we really need stateful session beans as such a strong part of the specification? In Spring I have my singleton beans and session-scoped beans, they do the job well.
2. Poor dependency injection. You are only allowed to inject certain set of objects to session beans, message driven beans and interceptors. Would you like to inject EntityManager to EntityListener (think of the new possibilities) or completely constructed collection to some bean? Or maybe inject some non-EJB object, which is created via the factory? Those, and many other scenarios can’t be achieved in EJB3. Yes, but you can inject integer located in JNDI to int field, amazing!
3. Aspect oriented programming. During the past ten years, AOP is becoming more and more widely used. But certainly not in EJB, where the concept of interceptors is a total misunderstanding. First of all, you can match the interceptor to single method, all methods in a single bean or to all beans. Do we miss something? Thinking about matching all the methods in "*Dao" named beans? Or maybe all methods matching "send*" pattern, no matter in which bean? No can do, all or (almost) nothing. Secondly, the whole point of aspect oriented programming is to decouple production code from aspects. In EJB3 you can use ejb-jar.xml or @Interceptors annotation. Yes, you put the information about which interceptors should be invoked directly in the target bean. This is completely the opposite of what I expect and how it is done for instance in AspectJ. Production code is polluted with interceptors meta-information.
If I look at the Spring support for aspect oriented programming, EJB3 interceptors look more like a joke to me. By the way did I mention that specification only allows for around advices? I know, this is the smallest problem.
4. Support for third-party technologies. EJB3 has great support for JPA, allowing you to inject EntityManager directly to session and message driven beans. And that’s all... Try to send JMS message with proper resource management and error handling, same with JDBC. Try to integrate iBATIS to your app, use any web framework, try to use almost anything – and you’ll end up with writing tons of code by hand. EJB3 is a specification and does not provide any support for many major technologies. This makes writing serious applications very time-consuming and error-prone, as lots of code should be either written or copy-pasted multiple times. Surely, you can use Spring utilities in your EJB3 project (like JmsTemplate), but wouldn’t it be simpler just to use one tightly integrated framework?
5. Scheduling asynchronous jobs. Quartz is known for many years, Unix cron is older than me. And what is "brand new" JSR 220 offering? You cannot even simply start a job at specific hour of day, because if you use 24h interval, it will work properly only for half of the year (hint: DST). Not to mention such a fancy expressions like "run it on every last Friday of the month between April and October each fifteen minutes during the night". TimerService is deadly simple: specify direct date or delay, nothing more. But the funniest thing about scheduling jobs is that... you can’t do it! New job may be scheduled only within SLSB or message driven bean’s business method. Forget about starting new job when application starts up, it can’t be done (see point 9). You must call some EJB, which will explicitly start the timer. This sounds like a job for JMS: you run some business method and it schedules other activity to be run asynchronously in other thread – but it’s not. To make matters worse, the specification even suggests to use scheduled jobs for some recovery and cleanup tasks (e.g. because method annotated with @PreDestroy is NOT called on system exception, don’t ask me why). OK, this is typical task for asynchronous jobs but hey, you cannot start them automatically. And even if you manage to hack you application, you must first check, whether the job isn’t already started because jobs survive server crash... and you might start the job once again. Odd...
6. Lack of portability. Some configuration parameters are just dying to be portable across different application server. For example number of instances of enterprise beans. But even though there is a specification, simplest activities like invoking remote secured EJBs is not portable. Not to mention JNDI names. This means porting your application to different AS is going to be configuration nightmare, as you have to map hundreds of server-specific options, which are mostly the same, but for instance, have different names.
7. Distributed configuration. I like Spring applications because all they produce is a single, portable WAR file, depending only on containers’ servlet specification. If you use EJB3, you have external data sources, JMS queues, security configuration, etc. You are bound to AS and EAR file is just one piece of many, which must be deployed. Sun recommends dividing your team to many roles, each having access to different parts of the app (Bean Provider, Assembler, Deployer, etc.) I don’t buy it, as a developer I can choose JDBC connection pool provider, JMS provider – I do not depend on anybody, I have full control over my application.
8. No Open Entity Manager In View support. In Spring there is a concept of OpenSessionInView or OpenEntityManagerInView. If you have ever written any web application, you are probably familiar with this pattern, sometimes prefixed with anti-. In short, Spring manages filter which keeps Hibernates Session or JPAs EntityManager open all the time the HTTP request is being processed. It means you can use lazy loading of persistent attributes whenever you like, especially in view and controller (not only in model layer). In EJB3, when your entity leaves bean with transaction scoped EntityManager, it is detached from persistence context and you may no longer rely on lazy loading (in fact, JPA specification does not specify the behavior in such situation, probably some vendor dependent exception will be thrown...) Of course, you may use EntityManager with extended persistence context, holding the transaction and persistence context as long as you want. But this feature is only available for SFSB, while DAO classes are typical examples of stateless services, since they only dispatch calls to the persistence layer. Additionally, having dedicated DAO bean instance for each client seems to be a big overkill.
9. No startup/shutdown application callbacks. I mentioned about that in point 5. It is obvious that you might want to call some code when your application starts up. Obtain resources, read configuration, schedule job, or just log something interesting. But EJB3 has no mechanism for that. You might consider @PostConstruct annotated methods, but they are actually called whenever new instance of some bean is created. And this typically happens when the first client accesses the bean and will eventually happen again for each new instance. In Spring I have a singleton service and using the same @PostConstruct annotation the goal is achieved. I can also subclass ContextLoaderListener and capture the very beginning of my app. There are valid and elegant possibilities.
10. Unit testing. In Spring I typically run micro-integration test of my bean and all other beans which are necessary to run the test. I can also run almost whole application, mocking only the most low-level beans, like data sources. I can also unit test single bean and inject mocks manually. In EJB3 matters get complicated. There is Ejb3unit, which only emulates the JEE environment. On the other hand there are some embedded containers, but would you really on them, especially if you are not embedding the same server as the production one? Not to mention the time that is needed to run such a tool. In most cases, it is faster for me to run mvn jetty:run (which is a complete environment for most of Spring apps) than to run unit test using embedded container...
I found Spring and EJB3 being direct rivals, covering pretty much the same area of use-cases. I know 3.1 specification changes a lot (singletons, better scheduling), but JSR-220 is three years old and 3.1 still didn’t came out. And I don’t want to start new holy war, especially because I also find many attractive features in Enterprise Java Beans. The most valuable thing is absolutely zero-configuration principle. Just add @WebService and @Stateless annotation to your class, compile, deploy and voilà, Java code is exposed as a web service, WSDL is generated, everything runs in stable application server environment. Dependency injection (despite its limitations) is as simple as it could, JPA integration is great. But after so many years of Spring framework development, it simply became more mature and flexible solution, in my humble opinion, of course.
August 3, 2009
Invoking secured remote EJB in JBoss 5
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:
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 programmatic security, next to @RolesAllowed. This does not look well – not only this annotation needs to be repeated in every session bean (and what happens if you forget? – nothing, security is then ignored…), but it brings compile-time dependency on JBoss specific class! Fortunately, good-old-XML can be used:
This short snippet in jboss.xml, which must be included in ejb-jar file, specifies the security domain name (dateserver) to be used by whole application. The same name should be referenced in login-config.xml file, located in JBoss distribution (typically server/default/conf directory):
Just put this by the end of login-config.xml file and restart JBoss. Does describing dateserver-users.properties and dateserver-roles.properties is necessary? First consists of username=password items and second: username=role1, role2, role3 mappings. Now we have successfully secured our remote EJBs, which quick test from Java SE client proves:
javax.ejb.EJBAccessException: Caller unauthorized
at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[...]
Needless to say, the journey begins here... After few frustrating tries, I still couldn’t manage to log on application server and call secured method, using all varieties of standard lookup code:
JBoss totally ignores authentication data provided to the InitialContext, repeatedly returning "Caller unauthorized". Finally, I found out that this server since 5.0 version has its own, non-standard API for managing user authentication:
This is totally awful! – not only JBoss forces me to use container specific classes (org.jboss.security.client.SecurityClient), the API itself isn’t very well designed. Please note, that although SecurityClient instance is created, it is never passed to the InitialContext or propagated by any other way. This smells like nasty ThreadLocal and will behave unexpectedly if you forget to logout and reuse the thread (e.g. when pooling in client).
JBoss finally catches up usernames and validates them against password, discovers user roles and applies security to EJBs. But, IMHO, the price is very high. I could stand JBoss client libraries on my CLASSPATH, I somehow avoided vendor specific annotations. But all in all, some strange client class must be used. What’s the point of this whole standardization, JSRs and tons of specifications, if even the simplest use case cannot be implemented without making my hands dirty?
P.S.: I'm starting to blog in English. Comments are welcome, but please be gentle ;-).
@Stateless
@RolesAllowed("ROLE_ADMIN")
@PermitAll
public 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 programmatic security, next to @RolesAllowed. This does not look well – not only this annotation needs to be repeated in every session bean (and what happens if you forget? – nothing, security is then ignored…), but it brings compile-time dependency on JBoss specific class! Fortunately, good-old-XML can be used:
<jboss>
<security-domain>dateserver</security-domain>
</jboss>
This short snippet in jboss.xml, which must be included in ejb-jar file, specifies the security domain name (dateserver) to be used by whole application. The same name should be referenced in login-config.xml file, located in JBoss distribution (typically server/default/conf directory):
<application-policy name="dateserver">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
<module-option name="usersProperties">props/dateserver-users.properties</module-option>
<module-option name="rolesProperties">props/dateserver-roles.properties</module-option>
</login-module>
</authentication>
Just put this by the end of login-config.xml file and restart JBoss. Does describing dateserver-users.properties and dateserver-roles.properties is necessary? First consists of username=password items and second: username=role1, role2, role3 mappings. Now we have successfully secured our remote EJBs, which quick test from Java SE client proves:
javax.ejb.EJBAccessException: Caller unauthorized
at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2.invoke(RoleBasedAuthorizationInterceptorv2.java:199)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
[...]
Needless to say, the journey begins here... After few frustrating tries, I still couldn’t manage to log on application server and call secured method, using all varieties of standard lookup code:
Hashtable<String, String> properties = new Hashtable<String, String>();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.NamingContextFactory");
properties.put(Context.PROVIDER_URL, "jnp://localhost:1099");
properties.put(Context.URL_PKG_PREFIXES, "org.jnp.interfaces");
properties.put(Context.SECURITY_PRINCIPAL, "user");
properties.put(Context.SECURITY_CREDENTIALS, "password");
Context context = new InitialContext(properties);
DateServiceRemote dateService = (DateServiceRemote) context.lookup("DateServiceBean/remote");
JBoss totally ignores authentication data provided to the InitialContext, repeatedly returning "Caller unauthorized". Finally, I found out that this server since 5.0 version has its own, non-standard API for managing user authentication:
SecurityClient securityClient = SecurityClientFactory.getSecurityClient();
try {
securityClient.setSimple("username", "password");
securityClient.login();
//perform JNDI lookup and call business method as usual WITHOUT authentication
} finally {
securityClient.logout();
}
This is totally awful! – not only JBoss forces me to use container specific classes (org.jboss.security.client.SecurityClient), the API itself isn’t very well designed. Please note, that although SecurityClient instance is created, it is never passed to the InitialContext or propagated by any other way. This smells like nasty ThreadLocal and will behave unexpectedly if you forget to logout and reuse the thread (e.g. when pooling in client).
JBoss finally catches up usernames and validates them against password, discovers user roles and applies security to EJBs. But, IMHO, the price is very high. I could stand JBoss client libraries on my CLASSPATH, I somehow avoided vendor specific annotations. But all in all, some strange client class must be used. What’s the point of this whole standardization, JSRs and tons of specifications, if even the simplest use case cannot be implemented without making my hands dirty?
P.S.: I'm starting to blog in English. Comments are welcome, but please be gentle ;-).
Subscribe to:
Posts (Atom)
