jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: Post PFD fixes

From: Justin Lee <jlee_at_antwerkz.com>
Date: Tue, 12 Mar 2013 13:06:33 -0400

Isn't that required for certification, though? Although, the bigger
"problem" is that it creates an implicit dependency on CDI either way.
 Which I'm mostly OK with as I'm an injection nut but it does increase the
scope kinda late in the game.


On Tue, Mar 12, 2013 at 8:38 AM, Mark Thomas <mark_at_homeinbox.net> wrote:

> On 12/03/2013 12:33, Justin Lee wrote:
> > Why not have the servlet container inject the container provider? let
> the
> > servlet container worry about resolving the correct provider. then the
> > developer just needs to use what's handed to him. isn't CDI required by
> > the web profile anyway? might as well leverage it.
>
> Not all Servlet containers implement the web profile.
>
> Mark
>
>
> > On Tue, Mar 12, 2013 at 5:07 AM, Mark Thomas <mark_at_homeinbox.net> wrote:
> >
> >> On 11/03/2013 23:48, Danny Coward wrote:
> >>> A) Implementation Issue with ServerContainerProvider
> >>
> >> <snip/>
> >>
> >>>
> >>> Fortunately, this instance of the ServletContext is readily available
> in
> >>> any ServletContexListener the developer may need to make the bootstrap
> >>> call from. There are various options for reworking the API,
> >>>
> >>> ServerContainerProvider.getServerContainer(String contextRoot)
> >> Won't work in a virtual hosting environment where there may be multiple
> >> web applications with the same context path.
> >>
> >>> ServerContainerProvider.getServerContainer(ServletContext
> servletContext)
> >> That needs to be an object to prevent a dependency
> >>
> >>> or ServerContainer.setContext(Object context)
> >> Either of these would be find by me.
> >>
> >>> though after some thought, I think the simplest approach is to remove
> >>> the ServerContainerProvider class altogether and require that, for
> >>> websocket implementations in the web container, the ServletContext
> >>> instance have a named attribute that is the websocket ServerContainer.
> >>> Its one less API class, in exchange for a named attribute.
> >>
> >> While I like the simplicity that won't work for a WebSocket
> >> implementation that is independent of the container because:
> >> - the container has no way of knowing it needs to add the
> >> ServerContainer (because of the 100% programmatic requirement there is
> >> no SCI to do this for us)
> >> - the implementation has no way of identifying the ServletContext
> >>
> >> Another option would be to have a standard ServletContextListener but
> >> that adds a hard dependency on the Servlet API.
> >>
> >> I think we are back to
> >> ServerContainerProvider.getServerContainer(Object servletContext)
> >> or ServerContainer.setContext(Object context)
> >>
> >> At this point, I'd be happy with either.
> >>
> >> Mark
> >>
> >
> >
> >
>
>


-- 
You can find me on the net at:
http://antwerkz.com             http://antwerkz.com/+
http://antwerkz.com/twitter   http://antwerkz.com/github