Hi Danny ,
Yes, the SCI scan takes place first detecting @ServerEndpoint and ServerEndpointConfig by type, which may be filtered through a ServletApplicationConfig. Then a ServletContextListener registers ServerEndpointConfig instances whose types were also detected by the scan. What happens then is undefined but it seems that the container should use the programmatically registered instances and ignore the scanned types of those instances (matches the approach of the Servlet container).
A second, related issue is that the scan discovers and attempts to instantiate even non-public ServerEndpointConfig types. It should ignore non-public types for consistency with @ServerEndpoint and also to avoid the strange case where I register a package private (or anonymous) ServerEndpointConfig programmatically but it it's also detected by the SCI scan. With programmatic deployment I could have a proper constructor with arguments, but if the SCI scan also detected it, it would fail to instantiate it.
Rossen
----- Original Message -----
> From: "Danny Coward" <danny.coward_at_oracle.com>
> To: jsr356-experts_at_websocket-spec.java.net
> Cc: "Rossen Stoyanchev" <rstoyanchev_at_vmware.com>
> Sent: Friday, March 22, 2013 2:48:41 PM
> Subject: Re: [jsr356-users] [jsr356-experts] Excluding
> programmatically deployed endpoints from the container scan
> Hi Rossen,
> I hadn't thought enough about mixing programmatic deployment and
> scanning.
> Endpoints that are deployed programmatically are deployed from
> ServletContextListeners. Aren't they going to be called after the
> ServerApplicationConfigs have already been called ?
> - Danny
> On 3/22/13 10:17 AM, Rossen Stoyanchev wrote:
> > 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
>
> --
> Danny Coward
> Java EE
> Oracle Corporation