Ok, then we can ignore unmapped unannotated Application classes. Good.
On 3/5/2013 4:59 AM, Marek Potociar wrote:
> 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
> <mailto: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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com