jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: [jsr356-users] Excluding programmatically deployed endpoints from the container scan

From: Rossen Stoyanchev <rstoyanchev_at_vmware.com>
Date: Fri, 22 Mar 2013 17:43:41 -0700 (PDT)

Hi Danny, see my response inline ..

----- 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 4:44:44 PM
> Subject: Re: [jsr356-experts] Re: [jsr356-users] Excluding
> programmatically deployed endpoints from the container scan

> Hi Rossen,

> Thanks that's helpful. See inline

> On 3/22/13 12:48 PM, Rossen Stoyanchev wrote:

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

> I see. Let me double check how this would work:-

> a) the container will scan the WAR for annotated endpoints and
> ServletApplicationConfigs to create the set to deploy
> 'unprogrammatically', but not deploy them yet.
> b) then the container waits until all the ServletContextListeners
> have been called, each of which may call the programmatic deployment
> API to deploy endpoints.
> c) then it deploys the set from a) silently ignoring any endpoints in
> the set that have already been programmatically deployed.

That sounds correct although b) should be more broadly considered to be any time during Servlet container initialization. In other words there is no reason to exclude ServletContainerInitializer or even Servlet.init(ServletConfig) in addition to ServletContextListener.

> And this is similar to the philosophy of the servlet spec. Right ?

I believe so.

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

> I'm not sure how much you tracked the rejig of the config apis, but
> now the scan is for Endpoint subclasses and @ServerEndpoint and
> ServerApplicationConfig only.

You're right. I see now this is explained here:
http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-03/message/14

> But, in any event, I don't think we ever intended non-public Endpoint
> classes to be endpoints, so I can clarify that in the spec, only
> public classes. I already have a note about scanning which I can
> augment to point out that any non-public classes will need to be
> thrown away.
> Will that work ?
Yes, that works!

Rossen