It's worth pointing out how the Servlet spec deals with the same issue (from section 8.1.1):
"If the same servlet class is declared in the deployment
descriptor under a different name, a new instance of the servlet MUST be
instantiated. If the same servlet class is added to the ServletContext via the
programmatic API defined in Section 4.4.1, “Programmatically adding and
configuring Servlets” on page 4-35 the values declared via the @WebServlet
annotation MUST be ignored and a new instance of the servlet with the name
specified MUST be created."
----- Original Message -----
> From: "Rossen Stoyanchev" <rstoyanchev_at_vmware.com>
> To: jsr356-experts_at_websocket-spec.java.net
> Sent: Friday, March 22, 2013 1:17:51 PM
> Subject: [jsr356-experts] Excluding programmatically deployed endpoints from the container scan
>
>
> An endpoint that is deployed programmatically, e.g. by registering a
> ServerEndpointConfig, should be excluded from the Servlet container
> scan. Maybe some containers will do that automatically but since the
> container scan imposes no limitations, it is capable of detecting
> all kinds of classes including package private, private inner
> classes, even anonymous classes. That may make it difficult to
> deploy via ServerEndpointConfig correctly. Essentially, a
> ServerApplicationConfig might need to be used to filter out the
> ServerEndpointConfig types but that's hardly an ideal way and a
> workaround at best.
>
> One simple change that would go a long way is to define a requirement
> for any scanned types to be public. There is such a requirement for
> @ServerEndpoint types, and it makes sense to extend it to all
> scanned types in any case.
>
> Rossen
>
>