OK, so I have clarified in the section on deployment that any endpoints
for which there could be an attempt to deploy the exact same endpoint
twice because it showed up in a scan and also a programmatic deploy will
only be deployed once.
Fortunately, this can only happen for annotated endpoints where there is
no ambiguity about what 'same endpoint' means because it is the same
class whoever tries to deploy it.
- Danny
On 3/22/13 5:43 PM, Rossen Stoyanchev wrote:
> Hi Danny, see my response inline..
>
> ------------------------------------------------------------------------
>
> *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
>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation