I like :).
On Monday, February 25, 2013, Danny Coward wrote:
> OK, well several of you have voiced a desire for this need to control
> creation of instances, I think our ServerEndpointConfigurator could be
> extended to play the role and provide the hook.
>
> If all of you that want this are ok with just using the CDI:
> javax.annotation.PostConstruct annotation, then please speak up and we are
> done ! But I strongly suspect not, so otherwise, please read on:-
>
> The 'EndpointFactory' proposal would be to add what was the old (from
> v008!) EndpointFactory.create() method for endpoint instances to todays
> ServerEndpointConfigurator.
>
> The developer can already provide a customized ServerEndpointConfigurator
> by subtyping it, overriding any of its methods and either setting it in the
> ServerEndpointConfigurationBuilder, or by using the configuration()
> attribute in @ServerEndpoint.
>
> So if we add the factory method there, the developer can provide his own
> implementation of the method. The specification would require that this
> method be used if overridden. The container default
> ServerEndpointConfigurator would use its existing mechanisms to instantiate
> the endpoint instances (i.e. using CDI in the EE case, public no-arg
> constructor else).
>
> Specifically, add to ServerEndpointConfigurator
>
> /** (something like) This method is called by the container when it needs
> a new
> ** instance of the endpoint this configurator configures. Developers
> ** may override this method to control instantiation of
> ** endpoint instances in order to customize the initialization
> ** of the endpoint instance, or manage them in some other way.
> ** If the developer overrides this method, services like
> ** dependency injection that are otherwise supported
> ** may not be available.
> */
> public Object createEndpoint() throws InstantiationException;
>
> Works equally well for programmatic endpoints and annotated endpoints, and
> fits with the existing configuration scheme.
>
> - Danny
>
>
>
>
>
> On 2/25/13 9:09 AM, Scott Ferguson wrote:
>
> 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<javascript:_e({}, 'cvml', '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
>>
>
>
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>