On 2/25/13 6:27 AM, Joe Walnes wrote:
> 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.
I basically agree.
Another alternative is the older "launch websockets from a normal
servlet" style, which has a side benefit of allowing encapsulation of
anything available to a normal servlet. In Resin's early websocket
design, we used something similar to the client publish:
@Inject
private WebSocketServletContainer container; ... [obtained somehow if
CDI isn't available]
public void service(ServletRequest req, ServletResponse res)
{
Endpoint myEndpoint = ...;
wsSession = container.startWebSocketEndpoint(req, res, myEndpoint);
}
Possible benefits:
1. "myEndpoint" can be instantiated however the application wants,
including a singleton
2. it can encapsulate anything available to a servlet (including the
session or auth/login/user info)
3. allows for dynamic launching (i.e. not fixed URLs)
-- Scott
>
> cheers
> -Joe
>
>
> On Thu, Feb 21, 2013 at 5:58 PM, Danny Coward <danny.coward_at_oracle.com
> <mailto: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
>
>