Flexible? I'd say editing an xml file was easier than recoding, compiling and deploying a Servlet. Although I guess even in the xml, you'd still have to redeploy.

I think the whole idea of security constraints in deployment descriptors is to minimize the amount of security code you'd have to put in a Servlet. It's best if a Servlet acts as a business controller, as opposed to a security guard.

Nevertheless, there are things you can do in code that you can't do in the deployment descriptor. Still, I go for xml based.

Flexible? I'd say editing an xml file was easier than recoding, compiling and deploying a Servlet. Although I guess even in the xml, you'd still have to redeploy.

I think the whole idea of security constraints in deployment descriptors is to minimize the amount of security code you'd have to put in a Servlet. It's best if a Servlet acts as a business controller, as opposed to a security guard.

Nevertheless, there are things you can do in code that you can't do in the deployment descriptor. Still, I go for xml based.

Generally, when one chooses programmatic security over declaritive security in a Java EE app, it is because the user information is (or is going to be) stored in the application's core database (in other words, the user security is part of the app's data). In this case, it's easier to have the security become part of the app, as opposed to a server configuration setting.

If, in your situation, it makes more sense to decouple the user security from the mechanics of the app itself then declarative security might make more sense.

We have some upload tools and file manager type apps that don't otherwise need a relational database. For these it is much more convenient to use the declarative security mechanism provided by the container.