Re: [jetty-users] [jsr356-experts] Re: [jsr356-users] Re: More more prog

[Joakim Erdfelt <joakim@xxxxxxxxxxx>]

Couldn't you have a dual meaning for ServerEndpointConfiguration.getPath() instead?

For servlet container deployed, this becomes relative to the webapp's context path.

For non-servlet containers (simple websocket servers) this becomes the relative to the that server's root.

--

Joakim Erdfelt <joakim@xxxxxxxxxxx>

webtide.com

Developer advice, services and support
from the Jetty & CometD experts

eclipse.org/jetty - cometd.org

On Wed, Feb 27, 2013 at 10:27 AM, Danny Coward <danny.coward@xxxxxxxxxx> wrote:

On 2/27/13 9:16 AM, Mark Thomas wrote:

I've been aligning the Tomcat code with this proposal and there are a couple of things that need discussion.

I am working on the assumption that the following would be added to the javax.websocket.server package:

public abstract class ServerContainer implements WebSocketContainer {

    public static ServerContainer getContainer() {
        // Implementation TBD
        return null;
    }

    public abstract void deploy(Class<?> pojo)
            throws DeploymentException;

    public abstract void deploy(ServerEndpointConfiguration sec)
            throws DeploymentException;
}


The first question is does getContainer() use the ServiceLoader API to load the implementation? For consistency with ContainerProvider, I think it should.

Yes I think so too.

>>> ... we are currently trying to restrict there to be one

ServerContainer instance per websocket application. Do you have enough
context under the ServerContainerProvider*.getServerContainer(); call to
do that ?

Yes. Currently I use the current context classloader (which is the web
application class loader in a servlet container) to ID the right
ServerContainer / determine I need to create a new one.

OK thanks Mark. Then I think this works too.

The second point is related to the above.

There is enough information if I make use of container internal API but I'd like to avoid that if at all possible.

Therefore I'd like to add one more method to the above API:

public abstract void setRoot(Object root);

Let me think about this. If I understand it, this is essentially an SPI on the implementation, and there's no reason for application developers to call it ?

- Danny

This method provides a mechanism for the implementation to identify the root URI for endpoints deployed through the ServerContainer. For a Servlet container the ServletContext would be passed in. For other containers an appropriate object (or possibly null) would be passed in. It would be necessary to call this method before calling either of the deploy() methods.

Mark

--

Danny Coward Java EE Oracle Corporation