CDI vs web.xml configuration

gistfile1.md

CDI vs web.xml configuration

To help decide which approach is best for our users this gist will show how configuring CORS in AeroGear Controller would be like using CDI and via web.xml

CDI

For a CDI version and the specific case of CORS users will probably need to provide their own configuration settings. The proposed solution for this is for a user to provide a CDI Producer, for example:

public class CorsConfigProducer {
    public @Produces CorsConfiguration getConfiguration() {
        return CorsConfig.create()
                .enableCorsSupport(true)
                .allowCookies(true)
                .anyOrigin(true)
                .maxAge(600)
                .validRequestHeaders("X-Header1")
                .validRequestMethods("GET, PUT, POST, DELETE, OPTIONS, HEAD, PATCH")
                .build();
    }
}

There might be areas in AeroGear Controller where an annotation might be more appropriate, but in this case I think it makes more sense, and is simpler, to have a producer of the configuration type. In cases where the users is defining an implementation for a AeroGear Controller specific class it would make sense to have an annotation and the user could simply override the annotation attributes that he/she wants.

Plus

• We stay true to using CDI consistently

Minus

• Requires a rebuild which might make it difficult for users moving form dev/test/production

Web Application Configuration (web.xml)

In this case we would let users add configuration parameters to web.xml in their deployment. For example:

<web-app>      
         <context-param>
            <param-name>aerogear.cors.enableCorsSupport</param-name>
            <param-value>true</param-value>
         </context-param>
         <context-param>
            <param-name>aerogear.cors.anyOrigin</param-name>
            <param-value>true</param-value>
         </context-param>
         <context-param>
            <param-name>aerogear.cors.validRequestHeaders</param-name>
            <param-value>X-Header1</param-value>
         </context-param>        
</web-app>

You might have noticed that these are not filter specific parameter as we use annotations for our filters so we are simply using aerogear.cors as a prefix.

Plus

• Some users might be more familiar with this approach

Minus

• Requires repacking which might make it difficult for users moving form dev/test/production

Questions

• Should we have a different option where a configuration file could be read from an external location to avoid having to rebuild/repackage?