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.
And this is similar to the philosophy of the servlet spec. Right ?
>
> 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.
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 ?
- Danny
>
> Rossen
>
> ------------------------------------------------------------------------
>
> *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
>
>
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation