[jax-rs-spec users] [jsr339-experts] Re: Section 2.3.2 conflicts with third-parties

From: Bill Burke <>
Date: Tue, 05 Mar 2013 07:37:39 -0500

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 <
> <>> 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

Bill Burke
JBoss, a division of Red Hat