Auto-detection of atmosphere handlers fails in specific deployments

[OliverO2]

AtmosphereFramework.autoDetectAtmosphereHandlers uses [ServletContext.getRealPath](http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String\)) whose documentation states:

This method returns null if the servlet container is unable to translate the given virtual path to a real path.

[ServletContext.getResource](http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getResource(java.lang.String\)), which is used as a backup, may also return null and is not guaranteed to work on directories as I understand it.

In cases where both methods return null, auto-detection fails.

For example, if Tomcat/7.0.37 is started via the tomcat7-maven-plugin:run goal in a multi-module Maven project, ServletContext.getRealPath and ServletContext.getResource both return null. No atmosphere handlers are detected.

[jfarcand]

@OliverO2 As a workaround, annotate your Handler with @AtmosphereHandlerService, or define it atmosphere.xml or web.xml (see the wiki for info).

[OliverO2]

@jfarcand Defining the handler in the xml config files worked (that's what I did before). Unfortunately, the @AtmosphereHandlerService did not. See my last comment in issue #1159.

[jfarcand]

Workaround, define in web.xml

        <init-param>
            <param-name>org.atmosphere.cpr.packages</param-name>
            <param-value><<YOUR PACKAGE>></param-value>
        </init-param>

[OliverO2]

Since the @AtmosphereHandlerService annotation seems to work now (see fix for issue #1159), I would consider deprecating auto-configuration of handlers.

Using the annotation is a good way to make the configuration more explicit, and offering too many methods to configure the same thing might confuse users.

[jfarcand]

Fully agree! One thing I can do is output a warning message at deployment time...but I cannot remove the mechanism as too many framework running on top of Atmosphere may get broken :-)

[OliverO2]

IMO it's OK to keep the mechanism for legacy users. A warning at deployment time should probably state that the mechanism does not work in all environments so that users know the risk involved even if it works in their current situation.

What I would consider very valuable is prominently stating the deprecation in the code and in the documentation so that new users don't waste time on solutions for which there are better alternatives. I happen to like Google Guavas philosophy in that respect (see section Iteration here, and you might consider an idea graveyard like this in the docs).

[jfarcand]

I like the Guava idea...I will spend time and see what can be done. Thanks for the link!

[jfarcand]

OK, added an entry in the documentation. Closing.