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