I'm not sure I read the spec the way you do. I do not see where the spec would imply that an Application subclass that is not annotated with @ApplicationPath is going to be deployed automatically. In contrast, the spec says:
If the Application subclass is not annotated with @ApplicationPath then the application MUST be packaged with a web.xml that specifies a servlet mapping for the added servlet.
Which IMO implies that an un-annotated Application subclasses are not auto-discovered. Note that the sentence
If an Application subclass is present that is not being handled by an existing servlet then the servlet added by the ContainerInitializer MUST be named with the fully qualified name of the Application subclass.
does not imply auto-discovery either. It just defines behavior for naming the servlet IF the runtime decides to create one.
Marek
On Mar 4, 2013, at 5:45 PM, Bill Burke <bburke_at_redhat.com> wrote:
> myself and users have come across a situation where we want to include an *optional*, non-annotated Application instance in our third-party library distributions. The problem is section 2.3.2 states that all Application classes have a servlet defined and added for them whether they are annotated with @ApplicationPath or not. Those not annotated that don't have a servlet mapping will cause a deployment exception.
>
> IMO, this wording should be changed. If there is no servlet-mapping for the automatically added servlet, then this should result in not deploying the Application.
>
> I dont think this is a backward compatibility issue. Existing applications will still run if the wording is changed.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com