I'll just pipe up and say that I'm still a big supporter of the
EndpointFactory approach ;).
On the hybrid thing, I don't see it as too complicated: All Endpoints
always get constructed through an EndpointFactory, and we include some
standard implementations for the default mechanism. Most users will
probably just leave the default in place, but for those who need their own
control of construction (could be manual, could be through a 3rd party DI
library), the hook is there for them without adding too much complexity.
It also folds into the other issue... we could defer the singleton question
until .next, but users who want it now can do it themselves with a custom
EndpointFactory implementation.
cheers
-Joe
On Thu, Feb 21, 2013 at 5:58 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> 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
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>