I believe Joe had all the right arguments regarding EndpointFactory in his earlier email. EndpointFactory vs passing in an EndpointConfiguration may be functionally equivalent but they have completely opposite effects on design, essentially dependency lookup vs dependency injection. That said, with the API having evolved so much, without a concrete proposal, it's difficult to provide much more constructive feedback.
As for the deployment of endpoints by instance, there have been more than one requests on the user list, with one use case pointed out just this past weekend. It's also interesting to observe that the RI's own two main samples, Auction and Chat, have been written with singleton semantics, i.e. they maintain static fields with all auctions or all chat sessions respectively. I should also note that the default mechanism (i.e. SCI scan) to register endpoints by type would remain in place, therefore registration by instance can only be done using more advanced deployment options, i.e. it will have to be done very consciously and should not lead to surprises, following the principle of least surprise.
Regards,
Rossen
----- Original Message -----
> From: "Danny Coward" <danny.coward_at_oracle.com>
> To: jsr356-experts_at_websocket-spec.java.net
> Sent: Thursday, February 21, 2013 6:58:28 PM
> Subject: [jsr356-users] [jsr356-experts] Two last outstanding issues
> from JIRA
> Hi folks,
> Two last issues from the JIRA that we have not yet covered: bringing
> back the EndpointFactory, and deploying server endpoints so that
> only one instance per path is used, rather than a new instance per
> client.
> 1) Bringing back the EndpointFactory
> Joe posted about the EndpointFactory in detail (
> http://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2013-01/message/2
> ), and we didn't have much discussion about it at the time, but I
> did log it. Essentially, the EndpointFactory idea allows developer
> provided code to be run to produce the endpoint instance. So any
> endpoint instance configuration can happen there. In the
> *Configuration model we have now, such configuration code has to be
> located in a developer provided *Configurator class.
> My own take is that the world of injection frameworks really requires
> us to allow the containers to instantiate these endpoints, their use
> is more and more common. While we could absolutely have a hybrid
> model where if you are not in a DI environment you could supply a
> factory, and if you are in a DI world you use something like a
> configurator, I think two models would be just too complicated.
> We would also still need something like the Configurator if we had
> EndpointFactory. And we would need the Configuation classes. So, the
> EndpointFactory approach leads us to a bigger API :(
> I think functionally, the approaches are equivalent, even if one is
> the 'inside out' version of the other Factory.create() versus
> endpoint.onOpen().
> I think the new configuration apis do address some of the concerns
> forced by the public no-arg constructor on Endpoint: we have a
> property bag on the EndpointConfiguration interface for easier
> sharing of data across instances without having to subtype. We have
> also de-coupled the Endpoint and the EndpointConfiguration in the
> newer API: now the same Endpoint class can be deployed in multiple
> configurations (say, URIs) because the deployment of an Endpoint is
> done with an EndpointConfiguration instance instead of class.
> So, not a perfect answer at all for our custom configuration example,
> but I think a simpler solution overall not to try to bring back the
> EndpointFactory.
> Are there any big supporters of the endpoint factory approach ?
> 2) Allow deployment of server endpoint singletons.
> The Endpoint API certainly allows for this kind of case where the
> developer wants a single instance to handle all connections, instead
> of today's (simpler) model where a new instance is created per
> connection. You'll probably remember that at first the spec defined
> endpoint to be singletons, then we decided to opt for the easier
> single threaded 'one per client' endpoint model because we thought
> that would make for an easier development model for the more common
> use cases.
> Now, all the lifecycle methods take the Session, so the connections
> can all be disambiguated. Such 'singleton' endpoints would be
> different from today's 'one per client' endpoints. They would need
> to be programmed for concurrent incoming events/messages from
> different clients. The 'singleton' endpoints operate in the context
> of multiple session objects, the 'one per client' endpoints operate
> in the context of just one. So, it seems to me, except in the most
> trivial cases, they are likely to be programmed quite differently,
> even if they both fit into the Endpoint model.
> All of which makes me think that we should be distinguishing these
> two types of server endpoint more formally. Perhaps extended API,
> perhaps more meta data in the annotations.
> Which makes me think we should play it safe, stick with the 'one
> instance per client' model we have, and look at singletons in more
> detail in .next.
> Are there any big supporters of the singleton approach ?
> Thanks,
> - Danny
> --
> Danny Coward
> Java EE
> Oracle Corporation