Recently I have tried to run Cejug-Classifieds on GlassFish - my first try was frustrated because the application didn't open even the first page. And the server console didn't reflect anything about the problem. Very strange, but very didactic also, as I will explain in this blog entry.

Cejug-Classifieds assume Tomcat as its target server and it also was tested on Geronimo and Websphere. Due to these successful tests, I got confused about such a difficulty to run it on GlassFish. After few inspections and with a very helpful support from the GlassFish forum, I figured out the problem: security-manager issues. Glassfish comes with the security-manager enabled by default and it avoided my application to include security restrictions on demand - my original algorithm. The Cejug-Classifieds has a security module based on a JassFilter designed to authenticate user requests. During the JaasFilter instantiation, the system adds a set of file names into the system properties.

fishing.gif

On the code below copied from the login module, the method init(FilterConfig) of the filter tries to set the name of the JAAS* properties files as System properties, but it is not allowed when the security-manager is enabled:

     public void init(FilterConfig arg0) throws ServletException { ServletContext context = arg0.getServletContext(); System.setProperty("java.security.manager", ""); System.setProperty("java.security.policy", context .getRealPath(

"WEB-INF/jaas/default.policy"

)); System.setProperty("java.security.auth.policy", context .getRealPath(

"WEB-INF/jaas/app.policy"

)); System.setProperty("java.security.auth.login.config", context .getRealPath(

"WEB-INF/jaas/jaas.config"

)); }  

* JAAS is a subject to a further blog entry - for now, I will focus on the security-manager.

The work around this problem and the discussions about security revealed a curiosity: the most popular web-servers come with the security-manager disabled. Why? The server vendors argue about the facility of disabling security-manager during the development phase and also argue about the need of a experienced technician in order to configure the correct details during the deployment into a production server. Well, I agree in part with such policy but I perceive the damage on the culture of the developers. How many times did you, developer, think about the security-manager and its functionality? If you answer almost never or if you even don't know what this thing means, don't worry - you are part of the majority of Java community that never has time or interest to learn about that.

Another interesting detail is about the Java TM 2 Platform Enterprise Edition Specification, v1.4 which claims that the Security Manager is not optional; it must be enabled in the Application Server. Glassfish just follows the specification - and why the other servers don